A bloody case triggered by proguard in Android 4.0

Case reproduction:

Modify the setting in the android 4.0 source code. After adding a function, compile it in Eng mode. Everything works, and then submit the code to the server. The next day, there was a bad news. The newly added functions of setting could not be used, and an error was reported when one click was made.

Case Analysis:

I have compiled and tested the code locally before uploading the code. Why ??!! Take care of it, and run ADB logcat to capture logs for analysis. If you don't know what to do, the error message displayed in the log is classnotfound, that is, the corresponding class is not found, is it possible that I missed it during the upload )? Check the submission record immediately. Check submitted files one by one. All files are submitted! Why does classnotfound appear? What should we do at this time? After analysis, we can know that the local test is usually compiled in the Eng mode, and this error is reported when the server is compiled in the USR mode. Are the results compiled by ENG and usr inconsistent ??!!

Further case analysis:

Select the USR compilation mode locally and compile the code for testing. The error is the same as that of the server, that is, classnotfound.

1. Since the compiled code in Eng mode can run properly, it proves that the Code logic and functions are OK.

2. The classnotfound problem occurs when USR is compiled, which proves that the compilation results are different due to the different compilation modes of USR and ENG.

There is indeed a class missing in the class (which will be replaced by lostclass. Java later ).

Case Investigation: hypothesis 1:

Isn't lostclass. Java compiled in the compilation process?

Verification 1:

Check whether lostclass. Java is compiled during compilation.

1. First check method.

Open the Android. mk file in the settings folder in the source code and we can find the following code:

Local_src_files: = $ (call all-Java-files-under, Src)

Add the following content after the Code:

$ (Warning seventest local_src_files: $ (local_src_files ))

After saving the file, compile the file on the terminal. We can see that the SRC file information is output on the terminal. Copy to the file and find lostclass. java. You can find it, so you can overturn the 4 hypothesis.

2. method 2.

View the APK compilation and packaging process. 1:

Based on the above process, we can find the MK file corresponding to each step. Here we find androidsoucecode/build/CORE/definitons. mk to comment out the following code:

Define compile-Java $ (hide) Rm-F $ @ $ (hide) Rm-RF $ (private_class_intermediates_dir) $ (hide) mkdir-p $ (DIR $ @) $ (hide) mkdir-p $ (private_class_intermediates_dir) $ (call unzip-jar-files, $ (private_static_java_libraries), $ (private_class_intermediates_dir )) $ (call dump-words-to-file, $ (private_java_sources), $ (private_class_intermediates_dir)/Java-source-list) $ (hide) If [-d "$ (private_source_intermediates_dir) "]; then \ find $ (private_source_intermediates_dir)-name '*. java '>>$ (private_class_intermediates_dir)/Java-source-list; \ fi $ (hide) tr ''' \ n' <$ (private_class_intermediates_dir) /Java-source-list \ | sort-u >$ (private_class_intermediates_dir)/Java-source-list-uniq $ (hide) $ (1) -encoding UTF-8 \ $ (Strip $ (private_javac_debug_flags) \ $ (if $ (findstring true, $ (local_warnings_enable), $ (xlint_unchecked),) \ $ (2) \ $ (addprefix-classpath, $ (strip \ $ (call normalize-path-list, $ (private_all_java_libraries) \ $ (if $ (findstring true, $ (local_warnings_enable), $ (xlint_unchecked),) \-extdirs ""-d $ (private_class_intermediates_dir) \ $ (private_javacflags) \\@ $ (callback) /Java-source-list-uniq \ | (RM-RF $ (private_class_intermediates_dir); exit 41) # Seven comment # $ (hide) Rm-F $ (private_class_intermediates_dir) /Java-source-list # $ (hide) Rm-F $ (private_class_intermediates_dir)/Java-source-list-uniq $ (hide) jar $ (if $ (Strip $ (private_jar_manifest),-CFM,-CF) \@ @ $ (private_jar_manifest)-C $ (private_class_intermediates_dir ). endefdefine transform-java-to-classes.jar @ echo "target Java: $ (private_module) ($ (private_class_intermediates_dir)" $ (call compile-Java, $ (target_javac), $ (private_bootclasspath )) # Seven annotation # $ (hide) Rm-RF $ (private_class_intermediates_dir) endef

After executing the compilation command on the terminal, we can find the following two files in the path: androidsourcecode/out/target/common/obj/apps/settings_intermediates/classes:

Java-source-list and Java-source-list-uniq can be found by searching for lostclass. java.

You can see from the above: lostclass. java is compiled. for verification, we can use the jd-GUI tool to view androidsourcecode/out/target/common/obj/apps/settings_intermediates/classes. jar. Check that the JAR file contains the lostclass. java.

Hypothesis 2:

Settings.apk encountered an exception during packaging.

Verification 2:

After comparing the output information compiled in Eng mode and usr mode, we find that the DEX files of the two copies are different. As follows:

USR mode:

Copying: Out/target/common/obj/apps/settings_intermediates/proguard. classes. Dex

Eng mode:

Copying: Out/target/common/obj/apps/settings_intermediates/noproguard. classes. Dex

Through comparison, we can know that proguard. classes. Dex is smaller than noproguard. classes. Dex. The proguard here is obfuscation. Also, we can say that the usrpattern implements the code, And the settings.apk compiled by usrpattern is different from the size compiled by ENG mode. Will proguard the code in USR mode cause problems? I do not know whether Hypothesis 2 is correct or not.

Suppose 3:

An exception occurs when the compilation system performs proguard on the code in USR mode.

Verification 3:

First, let's take a look at the proguard tool;

Proguard introduction:

Proguard is a free Java class File compression, optimization, obfuscator. It detects and deletes unused classes, fields, methods, and attributes. It deletes useless instructions and uses bytecode for maximum optimization. It uses meaningless names to rename classes, fields, and methods.

Role of proguard:

1. Create compact code, fast loading, and smaller memory usage.

2. Increase the difficulty of decompiling libraries used by programs and programs.

3. Delete the code from the source file that is not called.

After learning about the role of proguard, let's look back at lostclass. java. This class is mainly called in settings_heads.xml, but it is not called in other ways. Is this optimized by proguard for unused code?

Open the Android. mk file in the source code settings and you can see the following code:

Local_proguard_flag_files: = proguard. flags

Continue to view proguard. flags in the current path. The Code is as follows:

# Keep all Fragments in this package, which are used by reflection.-keep class com.android.settings.*Fragment-keep class com.android.settings.*Picker-keep class com.android.settings.*Settings-keep class com.android.settings.wifi.*Settings-keep class com.android.settings.deviceinfo.*-keep class com.android.settings.bluetooth.*-keep class com.android.settings.applications.*-keep class com.android.settings.inputmethod.*-keep class com.android.settings.MasterClear-keep class com.android.settings.MasterClearConfirm-keep class com.android.settings.accounts.*-keep class com.android.settings.fuelgauge.*

Check the proguard syntax to find out which classes will not be fully processed by proguard. Add the following code:

-Keep class com. Android. settings. xxxx .*

XXXX indicates the package name of lostclass. java.

Go to the terminal again and switch to USR mode to compile the code. The test is successful, but there are several small functions that still cannot be used normally. The above at least proves that assumption 3 is correct, that is, the problem arising during the proguard process.

These small functions do not have a common feature. When you click a button, an error is reported, indicating that the corresponding method cannot be found. These buttons Add the onclick Method to the XML file, for example:

<Button    android:id="@+id/JumpButton"    android:onClick="JumpFuction"    android:layout_width="0dip"    android:layout_height="wrap_content"    android:layout_weight="1"/>

You can view example -- a complete Android Application on the official proguard website. You also need to add the following code in proguard. Flags:

-keepclassmembers class * extends android.content.Context {   public void *(android.view.View);   public void *(android.view.MenuItem);}

The official website provides the explanation: We're also keeping possible onclick handlers in custom context extensions, since they might be referenced from XML layout files.

That is to say, some onclick events are defined in XML. Therefore, add the above content to the proguard. Flags file to ensure that these onclick trigger methods are not optimized by proguard. Add the above Code, compile, test, and pass !!

Case Review:

The entire case seems confusing, but the entire APK compilation process is hidden behind it. Something seemingly impossible at the beginning (the compilation results of USR and ENG modes are inconsistent). After a step-by-step Trace, I found the "shocking secret" behind it ". Proguard is a free open-source project used to compress, optimize, and confuse code. The Android source code integrates proguard, Which is enabled in USR and usrdebug modes by default, this can be found in androidsoucecode4.0/build/CORE/package. MK:

Ifndef local_proguard_enabled
Ifneq ($ (filter user userdebug, $ (target_build_variant )),)
# Turn On proguard by default for user & userdebug build
Local_proguard_enabled: = full
Endif
Endif

(PS: Qualcomm's source code is similar to Google's native code, while MTK commented out the local_proguard_enabled: = full, that is, the results compiled by USR, usrdebug, and ENG modes are not obfuscated .)

Of course, in addition to proguard, there is also a dexguard that can be used to optimize and protect Android applications, but this product is charged (the cheapest is 350 €... The conversion speed is nearly 3000 faster than RMB... O (random □random) O ).

At last, the truth was revealed in the bright autumn of an adult.