Release build optimization - Part 1

The goal of this article is to remove calls to debug log for release builds. Debug logs, which is done using Log.d(tag, msg) often contains more information that you want exposed to the public. It also takes up valuable CPU cycles.

Remove Log.d calls via Proguard

Proguard is a tool on Android that shrinks, optimize, and obfuscate your code. We want to use this on our release builds. In Gradle, we enable this either in the buildType or product flavor closure. The details can be found in the Android Tools User Guide

Example build.gradle:

	android {
	compileSdkVersion 19
	buildToolsVersion "19.0.1"
	defaultConfig {
	minSdkVersion 10
	targetSdkVersion 19
	versionCode 1
	versionName "1.0"
	}
	buildTypes {
	release {
	runProguard true
	proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.txt'
	}
	}
	}

view raw build.gradle hosted with ❤ by GitHub

Note that there are two default rules files. When you first create a project in Android Studio, you usually get a proguard-android.txt file. In order for us to tell Proguard to remove the debug log, we need it to run the optimization phase, so we need to tell it to use the proguard-android-optimization.txt file instead.

The second thing to notice here is the inclusion of a second txt file, the proguard-rules.txt. This text file is how we tell Proguard to remove calls to Log.d, Log.v, Log.i, and whatever else you think is safe to remove.

Example proguard-rules.txt

	-assumenosideeffects class android.util.Log {
	public static *** d(...);
	public static *** v(...);
	public static *** i(...);
	}

view raw proguard-rules.txt hosted with ❤ by GitHub

The assumenosideaffects flag is an optimization option that tells Proguard to treat the declared method as an empty method and thus is safe to remove. Details can be found in the Proguard Usage Manual.

Please note that if for whatever reason you decide to use the returned integer from Log.d and assign it to a variable, Proguard will think that it maybe a useful method and won't remove it. So make sure that whatever method you decided to use this option with does not return a value that's being used, if your intention is to remove the call.

So now if we compile the release build, we would effectively remove the Log.d. So lets take the following example set of calls

Before Proguard:

	Log.v(TAG, "I'm verbose");
	Log.d(TAG, "I like to debug");
	Log.d(TAG, new UserInfo(mUserId).getDisplayName());
	Log.w(TAG, "warning!");
	Log.e(TAG, "ERROR!");

view raw gistfile1.java hosted with ❤ by GitHub

After Proguard:

	new u(i).g();
	Log.w(t, "warning!");
	Log.e(t, "ERROR!");

view raw gistfile1.txt hosted with ❤ by GitHub

As we can see, it did a decent job of removing the debug logs. But it also left something behind. It created a new class and called some function. This is the obfuscated version of the code. So what we are seeing here is that the UserInfo class is still being created. So while we no longer take up I/O cycles by logging, we are still taking up CPU and memory by creating a class that we otherwise didn't need to create. So how can we change the code such that Proguard can safely remove the creation of the UserInfo class? It turns out that if we wrap it around a final boolean of FALSE, then Proguard will remove the code since there's no way the code can be executed. So we might consider changing our code to something like this:

	if (BuildConfig.DEBUG) {
	Log.v(TAG, "I'm verbose");
	Log.d(TAG, "I like to debug");
	Log.d(TAG, new UserInfo(mUserId).getDisplayName());
	}
	Log.w(TAG, "warning!");
	Log.e(TAG, "ERROR!");

view raw gistfile1.java hosted with ❤ by GitHub

This is a working solution. But because it requires that you add these "if (BuildConfig.DEBUG)" statements everywhere, it may not be acceptable, depending on the size of your project.

to be continued...

Quick & Dirty Tips: How to remove preloaded android apps

You need to have a rooted phone. Rooting of a phone is different for every device model, so it's important to find the right tools and procedure for your particular phone. Once your phone is rooted, connect your computer to your phone via USB and enable debugging via the developer options. You can now use the following set of commands in your computer terminal.

leo-osx:src_folder leo.kwong$ adb shell

shell@d2spr:/ $ su

root@d2spr:/ # mount -o rw,remount /system

root@d2spr:/ # cd system/priv-app/                                             

root@d2spr:/system/priv-app # ls MyTestApp*

MyTestAppForBlog.apk
root@d2spr:rm MyTestAppForBlog.apk
root@d2spr:/system/priv-app # exit

shell@d2spr:/ $ exit

leo-osx:src_folder leo.kwong$ 

What we're doing here is making the system folder read and write-able. Some of the preload apps will be in the system/priv-app and some will be in system/app. Only apks in /system/priv-app can use "system"-level permissions. Prior to Kitkat, all apks on the system partition could use those permissions. Uninstalling the app is just a matter of removing the APK file.

Reference: Android-Shell-Command-Reference