Grab slashes ANRs and cuts startup time by a third using R8 and profile‑guided optimisation

Grab’s performance overhaul – why it matters for Android users

Grab, the dominant “super‑app” in Southeast Asia, recently published a detailed case study on how it tackled three long‑standing pain points in its passenger app: high Application Not Responding (ANR) rates, a ballooning APK size and ever‑slower cold starts. While the story is aimed at developers, the end result – a smoother, faster experience for millions of users – is directly relevant to anyone who installs a large Android app on a UK handset.

The challenge of a ten‑year‑old codebase

The Grab app is a massive monolith, built over a decade and now exceeding 10 million lines of Kotlin/Java code. It pulls in hundreds of third‑party libraries and is compiled with a hybrid Bazel/Gradle pipeline. Over time the app began to show three clear symptoms:

1. ANR spikes after each weekly release – the app would freeze for several seconds while the system read and verified a growing number of DEX files.
2. Increasing download size – each new service added to the super‑app pushed the APK closer to the 150 MB limit, hurting users on limited data plans.
3. Longer cold‑start times – the time from tapping the icon to a usable UI crept up year after year, eroding the instant‑access feel that modern users expect.

A three‑phase strategy centred on R8 and profile‑guided optimisation

Grab’s engineering team broke the problem into three sequential phases, each building on the previous one.

Phase 1 – Switch to R8 in compatibility mode (2025 rollout)

The first step was to replace the legacy ProGuard configuration with the default proguard-android-optimize.txt file, which activates R8’s shrinking, obfuscation and optimisation passes. Because the codebase relied heavily on reflection, the team had to audit keep‑rules carefully. They also shipped the first set of Baseline Profiles and Startup Profiles – small binary files that tell Google Play which methods are critical for launch and should be pre‑compiled to native code.

Results:

• ANR rate fell by roughly 25 %.
• APK size shrank by 16 %.
• Cold‑start latency improved by 27 %.

Phase 2 – Full‑mode R8 with targeted keep‑rules (2026 rollout)

Nine months later Grab moved to R8’s Full Mode, unlocking deeper optimisation. The team focused on the most reflection‑intensive parts of the app, such as JSON parsing with Gson and dynamic proxy generation. Instead of adding blanket -keep statements (which would bloat the binary), they introduced narrowly scoped rules that preserved only the classes actually accessed via reflection.

Results:

• A further 10 % drop in ANR occurrences.
• An additional 14 % reduction in download size.
• Startup time cut by another 10 %.

Phase 3 – Ongoing keep‑rule hygiene and CI guardrails

The final stage is about sustainability. Grab integrated the R8 Configuration Analyzer into its CI pipeline, automatically generating optimisation, shrinking and obfuscation scores for every build. These metrics are now used as quality gates: any new keep‑rule must be justified and reviewed before a merge is allowed.

Current scores:

• Optimisation: 78.2 % (up from 72 %).
• Shrinking: 79.1 % (up from 73 %).
• Obfuscation: 81.7 % (up from 79.6 %).

The incremental refinements are already delivering a further 3.6 % cut in APK size.

Technical hurdles and how they were overcome

Reflection‑heavy legacy code

R8 cannot see runtime‑generated classes, so without explicit keep‑rules it would strip them, causing crashes. Grab’s engineers tackled this by:

• Importing consumer keep‑rules from the latest Gson release.
• Mapping the exact dynamic‑proxy classes used and writing precise -keepclassmembers entries.

Build‑system complexity

Because Grab uses Bazel for debug builds and Gradle for release builds, each R8 experiment could take up to two hours on remote CI. To keep feedback loops short, the team aligned daily QA builds with the production R8 configuration and automated the collection of mapping files (mapping.txt, configuration.txt).

Debugging at scale

When optimisation introduced crashes, de‑obfuscation was essential. Grab automated the upload of mapping files to Firebase Crashlytics and the Play Console, allowing crash reports to be instantly symbolised.

What this means for Android users in the UK

While Grab’s super‑app is not available in the UK, the techniques it showcases are applicable to any large Android application – including the popular banking, ride‑hailing and delivery apps we use daily. A 30 % reduction in download size translates to faster installs on 4G/5G networks and less storage pressure on devices with limited capacity. The 35 % cut in cold‑start time is the kind of invisible improvement that makes an app feel snappy, especially on older phones that many UK consumers still run.

For developers, the case study underscores the value of:

• Baseline Profiles – ship a tiny profile with your app so Google Play can pre‑compile the hot paths.
• R8 Full Mode – don’t settle for compatibility mode; invest time in refining keep‑rules.
• Continuous monitoring – treat optimisation scores as first‑class metrics in CI.

Bottom line

Grab’s systematic use of R8, Baseline Profiles and disciplined keep‑rule management has delivered a 32 % drop in ANRs, a 30 % shrink in APK size and a 35 % faster cold start. The story demonstrates that even a ten‑year‑old, multi‑module codebase can be revitalised with modern Android tooling. For UK Android users, the ripple effect is clear: faster, lighter apps that stay responsive after every update.

The original case study was published by Google’s Android Developers blog on 19 October 2026. All figures and quotes are taken from that source and have been re‑phrased for this article.