Mobile Development 18 min read

Making Android Baseline Profiles Work with Obfuscation, Market Limits, and Hot‑Fixes

This article explains how Baseline Profiles improve Android app start‑up performance, analyzes three major obstacles—unsupported app stores, dex‑crc mismatches caused by code‑obfuscation, and hot‑fix dex incompatibility—and provides concrete solutions including active optimization, dex‑name correction tasks, and profile injection during patch synthesis.

NetEase Cloud Music Tech Team
NetEase Cloud Music Tech Team
NetEase Cloud Music Tech Team
Making Android Baseline Profiles Work with Obfuscation, Market Limits, and Hot‑Fixes

Background

Google introduced Baseline Profiles in 2022 to let app stores perform guided AOT compilation using a profile file bundled in the APK. The profile directs the compiler to pre‑optimize hot code paths, reducing cold‑start latency and improving user retention metrics.

Baseline Profiles Workflow

The process consists of three steps:

Generate a human‑readable profile (HRF) with the Macrobenchmark library and BaselineProfileRule.

During APK build, convert the HRF to a binary file and place it in assets/dexopt (handled by MergeArtProfileTask and CompileArtProfileTask in AGP 7).

When the app is installed, the store extracts the binary profile and runs AOT compilation, or the app uses ProfileInstaller at first launch to write the profile to the system path.

Problems in the Chinese Market

Three issues arise for apps that use third‑party protection and hot‑fix frameworks:

Only a few domestic app stores support guided AOT; users on unsupported stores miss the performance boost.

Code‑obfuscation tools change dex file names and CRC values, causing the profile’s stored checksum to fail verification.

After a hot‑fix, the runtime dex is a synthesized file, so the original profile no longer matches the executed code.

Active Optimization for Unsupported Stores

To compensate for stores that do not apply the profile at install time, the app can trigger dex optimization manually after the first launch. The recommended strategy is to run the optimization 5 seconds after the UI becomes visible and only when the primary dex has not yet been optimized, to avoid UI stalls.

Three system interfaces can be used:

Binder shell command compile -f -m speed-profile ${packageName} Binder shell command bg-dexopt-job ${packageName} (optimizes both primary and secondary dex files)

AIDL call performDexOptMode via IPackageManager.Stub (requires SYSTEM/ROOT/SHELL privileges on Android 12+)

Fixing Dex‑CRC Mismatch After Obfuscation

Because the protection step inserts a new dex (e.g., classes2.dex) and renames the original, the CRC stored in the binary profile no longer matches the dex inside the APK. The solution is to add a Gradle task that runs after the protection step:

Unzip the protected APK.

Use ArtProfile (provided by AGP) to read baseline.prof and baseline.profm, modify the dex name entries to the new names, and write the updated binary profile back.

Re‑zip the APK, preserving each file’s original compression method to avoid size bloat.

Sample code snippets illustrate how ProfileVerifier checks CRC and how a mismatch leads to profile clearing:

public boolean performDexOptMode(String packageName, ...) { enforceSystemOrRootOrShell("performDexOptMode"); ... }
bool VerifyProfileData() { return profile_compilation_info_->VerifyProfileData(...); }

Handling Hot‑Fix Dex Files

After a hot‑fix, the runtime dex is a composition of the original dex and the patch dex, so the original profile is ineffective. To restore profile‑guided optimization:

During patch synthesis, write a new profile for the synthesized dex (path differs by Android version: ${dexPath}.prof on 8.0, ${dexParentPath}/oat/${dexFileName}.cur.prof on 8.1+).

Use the same ArtProfile APIs to generate a binary profile from the HRF, then embed it into the patched APK before the system’s dex‑opt job runs.

Code from the Android framework shows how secondary dex profiles are registered and created.

Summary of Solutions

Active optimization compensates for stores that do not apply Baseline Profiles.

Post‑obfuscation dex‑name correction aligns CRC values so the profile can be verified.

During patch synthesis, generate and inject a profile for the new dex so hot‑fixes also benefit from guided AOT.

After applying these fixes, the referenced app (a music streaming client) observed a 31 % launch‑time improvement on supported stores, a 6 % overall gain, and a 12 % boost after hot‑fixes.

References

Baseline Profiles overview

Creating Baseline Profiles

"Dex Optimization Chronicle" (WeChat article)

Android source code for various versions

PerformanceAndroidObfuscationAOTHotfixBaseline ProfilesDex Optimization
NetEase Cloud Music Tech Team
Written by

NetEase Cloud Music Tech Team

Official account of NetEase Cloud Music Tech Team

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.