Accurately Measure Android App Performance with Profileable Builds

Historically, profiling an Android app required a debug build.

While useful, the debug build is meant to provide more information at the cost of performance. That’s because when debuggable is true, a lot of compiler optimizations are turned off.

To show you the performance difference between the debug and release builds, we recorded an app running on the same device but in these two build variants. To visualize the frame rendering time, we turned on Profile GPU Rendering (or Profile HWUI rendering in some Android versions) in Developer Options when recording the screen. Each vertical bar on the bottom of the screen represents how long each frame takes to render. The shorter these bars are, the smoother the animation is.

The screen recording below shows the same app running on the same device. The left-hand side is on a debug build, the right-hand side a release build. The debug version has more stuttering frames, also known as UI jank. This means when you profile the debug build, you may see timing measurements significantly different from what your users see in the release build, and you may end up optimizing something that is not the problem.

To address that issue, the Android platform introduced a tag called profileable. It enables many profiling tools that measure timing information, without the performance overhead of the debug build. Profileable is available on devices running Android 10 or higher.

AndroidManifest.xml

Let’s look at another screen recording. This time, the left side shows a profileable release app and the right side an unmodified release app. There’s little performance difference between the two.

With profileable, you can now measure the timing information much more accurately than the debug build.

This feature is designed to be used in production where app security is paramount. Therefore we decided to only support profiling features such as Callstack Sampling and System Trace, where timing measurement is critical. The Memory Profiler only supports Native Memory Profiling. The Energy Profiler and Event Timeline are not available. The complete list of disabled features can be found here. All these restrictions are put in place to keep your app's data safe.

Now that you know what the profileable tag does, let me show you how to use it. There are two options: automatically and manually.

This feature is great for simplifying the process of local profiling but it only applies when you profile with Android Studio. Therefore, it can still be beneficial to manually configure your app in case you want to diagnose performance issues in production or if you’re not ready to use the latest version of Android Studio or Android Gradle plugin yet.

Option 2: Manual configuration.

It takes 4 steps to manually enable profileable.

1.    Add this line to your AndroidManifest.xml.

 AndroidManifest.xml

<application>   <profileable android:shell="true" /> </application>

2.    Switch to the release build type (or any build type that’s not debuggable).

3.    Make sure you have a signing key configured. To prevent compromising your release signing key, you can temporarily use your debug signing key, or configure a new key just for profiling.

4.    Build and run the app on a device running Android 10 or higher. You now have a profileable app. You can then attach the Android Studio profiler by launching the Profiler tool window and selecting the app process from the dropdown list.

In fact, many first-party Google apps such as Google Maps ship their app to the Play Store as profileable apps.

Here’s a table that shows which build type should be used:

To learn more about profilable builds, start by reading the documentation and the the user guide.

With these tools provided by the Android team, we hope you can make your app run faster and smoother.