# R8 Published articles for R8. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## AI Can Write My Kotlin. Who's Going to Debug It at 2 AM? DevFeed: [AI Can Write My Kotlin. Who's Going to Debug It at 2 AM?]() Original publisher: [Read original article]() Author: Mayank Kumar Published: 2026-10-30T13:51:50Z Content type: article Language: en Sources: [ProAndroidDev]() Topics: [AI tools for developers](), [human review](), [Code review](), [ai slop pull requests](), [Multi-step AI processes](), [adb](), [Crashlytics]() Tags: [agent](), [ai](), [ai-tools](), [android](), [android-app-development](), [android-bench](), [android-studio](), [androiddev](), [app-quality](), [artificial-intelligence](), [code](), [crashlytics](), [death](), [delivery](), [dora](), [emulator](), [kotlin](), [main-thread](), [models](), [oem](), [process](), [r8](), [recomposition](), [release]() ### AI overview AI tools can write and debug Android code, but passing repository tests does not establish that a change works on a device. Android failures can depend on process death, OEM battery management, release-build R8, recomposition, or low-memory performance; benchmarks and tests cover only what they check. The article recommends making verification routine: test process death by killing and reopening the app, smoke-test critical flows on a minified release build, use a Macrobenchmark for startup or scrolling, keep agent changes small and inspect edited tests, and read Perfetto traces or heap dumps to check causes. Agents can speed up diagnosis, but developers remain responsible for validating fixes and owning releases. It also notes that Android 16's experimental AppFunctions lets apps expose agent-callable functions, whose KDoc descriptions and inputs require careful treatment. ### Source excerpt Image by the author It's 2:07 AM, and Crashlytics has opinions. The crash is in a ViewModel that git blame says you wrote. You didn't. An agent did, and its pull request said "all tests pass." They do. The agent updated the expected values to match its new behaviour. That's a composite, not a confession. But it points at a real shift in Android work. This post covers what AI tools can do on Android today, why "the tests pass" is not the same as "it works" on a phone, and what to get better at. Short answer: AI can now write and fix Android code, but proving it works on a real device is still your job. What can AI tools do on Android today? Quite a lot. Android Studio's May 2026 release includes an agent that plans multi-step work and fixes its own build errors, "Fix with AI" for crashes in App Quality Insights, and an option to hand LeakCanary traces to an agent. Google also runs Android Bench, which gives models real issues from public Android repos and checks each fix with tests. At its March 2026 launch, models solved between 16% and 72% of tasks. So writing Android code is no longer the slow part. Checking it is. Why is "almost right" the expensive part? Because it compiles, looks fine in review, and fails later. In Stack Overflow's 2025 survey, 66% of developers named "AI solutions that are almost right, but not quite" as their top frustration. Google's DORA 2025 report found that AI adoption goes with higher delivery throughput, but it's still linked to less stable delivery. When changes get cheap to produce, teams produce more of them. The limit becomes how much change you can verify. Why is this harder on Android? Because an agent works on the repository, but Android correctness depends on the device at runtime. Image by the author Process death, OEM battery managers, R8 in release builds, unexpected recomposition, and main-thread work on low-memory devices rarely show up in a diff. Most don't show up on a flagship emulator either. Here's what "almost right" ## Grab Reduces ANRs by 32% and improves startup time by 35% with R8 and Profile guided optimization DevFeed: [Grab Reduces ANRs by 32% and improves startup time by 35% with R8 and Profile guided optimization]() Original publisher: [Read original article]() Author: Tracy Agyemang Published: 2026-10-19T00:00:00Z Content type: article Language: en Sources: [Android Developers]() Topics: [R8](), [app startup](), [CI/CD]() Tags: [android](), [anr](), [app-size](), [build-system](), [case-studies](), [ci-cd](), [optimization](), [r8](), [startup]() ### AI overview Grab describes optimizing its Android app with R8, Baseline Profiles, and Startup Profiles to reduce startup time, app size, and user-perceived ANRs. The case study outlines a phased migration, targeted keep-rule changes, and CI guardrails for preserving optimization gains. ### Source excerpt Grab is Southeast Asia's leading superapp, offering deliveries, mobility, and financial services to millions of users across eight countries through a single app. ## R8 code shrinking now works with the Appwrite Android SDK DevFeed: [R8 code shrinking now works with the Appwrite Android SDK]() Original publisher: [Read original article]() Author: Chirag Aggarwal Published: 2026-10-07T00:00:00Z Content type: article Language: en Sources: [Appwrite Blog]() Topics: [Android](), [Appwrite](), [IntelliJ IDEA]() Tags: [android-gradle-plugin](), [android-vitals](), [api](), [bugs](), [build](), [products](), [r8](), [realtime](), [sessions]() ### AI overview Appwrite Android SDK 29.0.0 adds support for R8 full mode, addressing release-build failures in query serialization, Realtime event handling, and saved sessions. The article explains the changes, upgrade requirements, and how to test shrinking in an app, including annotating application models that Gson populates with @Keep. The SDK ships consumer R8 rules and raises the minimum Android SDK version to 24. ### Source excerpt Appwrite Android SDK 29.0.0 works with R8 full mode, fixing queries, Realtime, and saved sessions in release builds ahead of Google Play's 2027 DEX rule. ## Obfuscation Fundamentals: Applying ProGuard and R8 Protections to Android Code DevFeed: [Obfuscation Fundamentals: Applying ProGuard and R8 Protections to Android Code]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2026-09-17T04:13:15.404035Z Content type: tutorial Language: en Sources: [Dustin Summers]() Topics: [obfuscation](), [Android](), [R8](), [Code]() Tags: [android](), [meetup](), [obfuscation](), [proguard](), [r8](), [video]() ### AI overview A presentation introducing obfuscation with ProGuard and R8, focused on applying protections to Android code. It explains how to diagnose the code entering and leaving these build tools. ### Source excerpt This presentation was given at a MeetUp in DC. It corresponds to this series of blog posts, which is the first in a series to teach about Obfuscation/ProGuard/R8, and will primarily be centered around applying protections to Android Code. Tools such as R8 and ProGuard are available, but to many they are a black box that code goes into and stuff comes out. The following will demystify the black box, and teach developers how to properly diagnose the code going into and coming out of these build tools. ## Tinder cuts app cold starts by 47% with new R8 Configuration Analyzer DevFeed: [Tinder cuts app cold starts by 47% with new R8 Configuration Analyzer]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-18T18:00:00Z Content type: article Language: en Sources: [Android Developers]() Topics: [R8](), [Android](), [Optimization](), [configuration](), [Code]() Tags: [agentic](), [android](), [development](), [errors](), [obfuscation](), [optimization](), [r8](), [startup](), [time]() ### AI overview The article describes how Tinder used the R8 Configuration Analyzer to identify and remove keep-rule blockers in its Android application. The effort reduced cold-start time by 47%, app download size by 28.98% to 61.5 MB, and user-perceived ANRs by 28%. ### Source excerpt Posted by Ajesh R Pai, Developer Relations Engineer, Ulises Uriel Verduzco Diaz, Software Engineer, Tinder, and Tracy Agyemang, Product Marketing Manager Tinder is on a mission to power and inspire real connections by making meeting easy and fun for every new generation of singles. However, as their Android application codebase grew in size, so did its complexity. Prior to their latest optimization efforts, approximately 70% of the application was not optimized, carrying 17 dex files,including three dedicated just to startup. Although they had enabled R8, much of its optimization potential was blocked due to keep rules, and the team was unable to identify which specific rules were preventing optimization. To reduce startup time and decrease user-perceived Application Not Responding (ANR) errors, Tinder turned to the new R8 Configuration Analyzer to tackle these challenges. By utilizing the R8 Configuration Analyzer, Tinder successfully identified and removed unintentional optimization blockers. The results were immediate and impactful: Tinder achieved a 47% reduction in app cold starts, shrank their app download size by 28.98% (down to 61.5 MB), and reduced user-perceived ANRs by 28%. Configuration analyzer The R8 Configuration Analyzer shows R8 optimization by tracking shrinking, optimization, and obfuscation scores to show available refinement areas. It shows the broad, redundant, or obsolete keep rules, including those from external libraries so that you can analyse the keep rule impact and refine the keep rules. Key metrics shown in Configuration Analyzer include: Shrinking Score: Code percentage available for R8 shrinking. Optimization Score: Code percentage open to optimization (for example, method inlining, horizontal class merging). Obfuscation Score: Percentage of classes, methods and fields that can be renamed by R8 to decrease size. Use the analyzer to audit keep rules and their impacts: Find broad rules: Narrow the scope of package-wide rules that restri ## Tinder cuts app cold starts by 47% with new R8 Configuration Analyzer DevFeed: [Tinder cuts app cold starts by 47% with new R8 Configuration Analyzer]() Original publisher: [Read original article]() Author: Tracy Agyemang Published: 2026-08-18T00:00:00Z Content type: article Language: en Sources: [Android Developers]() Topics: [IntelliJ IDEA](), [CI/CD]() Tags: [anr](), [app-startup](), [case-studies](), [ci](), [ci-cd](), [code](), [continuous-integration](), [developers](), [development](), [r8]() ### AI overview Tinder used the R8 Configuration Analyzer to identify a broad keep rule that was limiting optimization in its Android app. After refining the rule, the team reported 47% fewer slow cold starts, a 28.98% reduction in download size, and 28% fewer user-perceived ANRs. It also added optimization monitoring to its CI/CD pipeline. ### Source excerpt Tinder is on a mission to power and inspire real connections by making meeting easy and fun for every new generation of singles. ## App Hardening: One Obfuscation Pipeline Across Every Port DevFeed: [App Hardening: One Obfuscation Pipeline Across Every Port]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-08-15T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [obfuscation](), [cross-platform](), [Encryption](), [Security](), [Reverse Engineering](), [App]() Tags: [android](), [app](), [cross-platform](), [encryption](), [hardening](), [ios](), [javascript](), [native](), [obfuscation](), [platform](), [r8](), [reverse-engineering](), [security]() ### AI overview Codename One App Hardening applies one pre-build protection pipeline to a merged cross-platform application before it is split into Android, iOS, JavaScript, Windows, Linux, and desktop builds. It supports renaming, eligible string encryption, selected control-flow transformations, verification, and crash-report retracing, while acknowledging that reverse engineering cannot be made impossible. ### Source excerpt Codename One App Hardening applies class and member renaming, string encryption, and platform-safe control-flow transforms before one application becomes Android, iOS, JavaScript, or native desktop output. ## How R8 made Kotlin Coroutines on Android 2x faster DevFeed: [How R8 made Kotlin Coroutines on Android 2x faster]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-07-27T13:00:00Z Content type: article Language: en Sources: [Android Developers]() Topics: [Coroutines](), [Kotlin](), [R8](), [Android](), [Jetpack Compose](), [Programming]() Tags: [android](), [android-gradle-plugin](), [app-performance](), [atomic](), [compose](), [coroutines](), [kotlin](), [performance](), [programming](), [r8]() ### AI overview This article explains how R8 optimization in AGP 9.2.0 improves Kotlin coroutines performance on Android. By optimizing AtomicFieldUpdater calls, the change makes launching and cancelling coroutines up to twice as fast, addressing coroutine-related bottlenecks in Jetpack Compose and other Android operations. ### Source excerpt Posted by Andrei Shikov, Senior Software Engineer, Android Toolkit and Jonathan Starup, Software Engineer, R8 Team Starting from AGP 9.2.0, R8 optimizes most Atomic*FieldUpdater calls into Unsafe variants that perform 2x to 4x better on common operations. This has a particularly large impact on the kotlinx.atomicfu library that implements atomics for kotlinx.coroutines, making launching and cancelling coroutines up to 2x faster. In order to get the benefits, update your AGP to 9.2.0 or above. With the majority of Android apps adopting Kotlin as their main language of choice, kotlinx.coroutines has become a de-facto standard for asynchronous programming. The library offers a well-designed and structured way of managing concurrent flows that is native to Kotlin. Jetpack Compose was no exception, adopting coroutines for managing pointer events, animations and other interactions. At the time of writing, most concurrent APIs in Compose call suspend functions under the hood and are launching and/or cancelling coroutines to handle updates. As the Compose team started to investigate performance, coroutines were discovered to be a bottleneck for many operations that happen outside of composition. As an example, 80% of the time spent on creating and updating Modifier.clickable was consumed by launching and cancelling internal coroutines that handled InteractionSource updates. Based on those observations, much of early performance work was focused on removing coroutines from the default path and delaying initialization until necessary. The cost of a coroutine The easiest way to analyze a function's internal behavior on Android is to capture an Android Runtime (ART) method trace. An ART method trace is a tool that records the execution flow of an app, showing exactly which methods are called, their order, and how much time is spent in each, allowing developers to identify performance bottlenecks. For an empty LaunchedEffect { } call, it would look something like this: LaunchedE ## My Network Agent Lives in My Pocket Now -- And Nobody Is in the Middle DevFeed: [My Network Agent Lives in My Pocket Now -- And Nobody Is in the Middle]() Original publisher: [Read original article]() Author: John Capobianco Published: 2026-07-26T12:00:00Z Content type: article Language: en Sources: [Automate Your Network]() Topics: [Claude Code](), [Expo](), [Termux](), [android-app-bundle](), [tor]() Tags: [ai](), [android](), [apk](), [article](), [camera](), [cellular](), [claude-code](), [cml](), [dart](), [discord](), [hardware](), [netclaw](), [outage](), [photo](), [post-mortems](), [proguard](), [prompt](), [r8](), [room](), [slack](), [webex]() ### AI overview The article recounts building NetClaw Mobile, a private network automation agent accessed through phones. It describes Claude Code testing an Android app in an emulator, then moving to real-device testing and connecting an iPhone with an Android phone to a CML lab without routing conversations through third-party chat services. ### Source excerpt From an emulator Claude Code drove itself, to a real Android phone in someone else's hands, to an iPhone talking to that Android through my own Border -- voice, photos, and a live CML lab, all over NCFED. No Slack, no Discord, no Webex, no t ## Obfuscation Deep Dive: Enhancing R8 and ProGuard for Robust Android Code Protection DevFeed: [Obfuscation Deep Dive: Enhancing R8 and ProGuard for Robust Android Code Protection]() Original publisher: [Read original article]() Author: Kirill Rozov Published: 2025-05-19T07:40:40Z Content type: article Language: en Sources: [Kirill Rozov]() Topics: [obfuscation](), [proguard](), [R8](), [Android]() Tags: [advanced](), [android](), [app](), [app-size](), [applications](), [approach](), [article](), [aspect](), [builds](), [but](), [code](), [deep](), [deep-dive](), [dive](), [enhancing](), [java](), [obfuscation](), [proguard](), [protection](), [r8](), [robust](), [security]() ### AI overview R8 and ProGuard's default short-letter naming can make obfuscated identifiers predictable across builds, which the excerpt says may aid reverse engineering. It recommends supplying custom class, package, and general obfuscation dictionaries, with a new randomized dictionary for each build to vary names. It also describes Java reserved keywords as bytecode names that can confuse decompilers, though the resulting code will not compile as Java, and warns that Windows-restricted names may cause reverse-engineering errors on Windows. The excerpt advises testing across environments; its final randomization-script description is cut off. ### Source excerpt Obfuscation is a crucial aspect of securing Android applications. While tools like R8 and ProGuard are commonly used, their default configurations primarily aim to reduce app size rather than fortify code against reverse engineering. This article delves into advanced obfuscation techniques to make reverse engineering harder. Understanding Obfuscation Obfuscation transforms readable code into a form that's difficult to interpret. For instance, UserManager might become a, and getUser() could be renamed to b(). R8 and ProGuard perform obfuscation alongside code shrinking and optimization. # R8/ProGuard default dictionary a b c ... z These tools use dictionaries to generate new names, typically starting with single letters (a to z) and progressing to combinations like aa, ab, etc. While this approach minimizes file size, it has drawbacks: Predictable Naming: Limited name variations make it easier to deduce original identifiers. Consistent Builds: Repeated builds produce identical obfuscated names, aiding pattern recognition. Simplified Reverse Engineering: Tools can exploit naming patterns across builds. To counter these issues, customizing the obfuscation dictionary is essential. Implementing Custom Dictionaries R8 and ProGuard allow the use of custom dictionaries via configuration files: # proguard-rules.txt # Add to R8/ProGuard config file -obfuscationdictionary obfuscation-dictionary.tx -classobfuscationdictionary class-dictionary.txt -packageobfuscationdictionary package-dictionary.txt By providing unique dictionaries, you can generate diverse and unpredictable obfuscated names. Advanced Dictionary StrategiesJava Reserved Keywords Using Java's reserved keywords (e.g., if, for, class) as obfuscated names can confuse decompilers, as these are invalid identifiers in source code but acceptable in bytecode. # Java Reserved Keywords dictionary do if for int new ... instanceof synchronized Example of deobfucated Java code with java reserved keywords dictionary package cla ## Optimizing Rectangle-Overlap Tests by Removing Conditional Branches DevFeed: [Optimizing Rectangle-Overlap Tests by Removing Conditional Branches]() Original publisher: [Read original article]() Author: Romain Guy Published: 2024-05-18T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Romain Guy]() Topics: [Optimization](), [Code](), [Kotlin](), [R8](), [Benchmark]() Tags: [android](), [assembly](), [benchmark](), [code](), [developer](), [graphics](), [kotlin](), [optimization](), [performance](), [r8]() ### AI overview This article examines optimizing rectangle-overlap tests in Kotlin. It compares generated assembly, replaces logical operators with bitwise operators to remove conditional branches, and reports a 1.7x speedup in a benchmark on a Google Pixel 6. ### Source excerpt I recently discussed an optimization that I worked on following Leland's successful nerd snipe. That, however, was not the end of it. He also needed to test for intersecting/overlapping rectangles. The most obvious way to achieve this is pretty straightforward: 1// A rectangle is defined by its left (l), top (t), 2// right (r), and bottom (b) coordinates 3data class Rect(val l: Int, val t: Int, val r: Int, val b: Int) { 4 fun overlaps(other: Rect) = 5 l < other.r && other.l < r && t < other.b && other.t < b 6} The source code is nice and tidy, but the generated assembly is less than ideal (as always, the code was optimized with R8 first): ## Crafting Android bytecode analysis tooling using a secret ingredient (Part 1) DevFeed: [Crafting Android bytecode analysis tooling using a secret ingredient (Part 1)]() Original publisher: [Read original article]() Author: Konstantin Zolotov Published: 2024-02-09T11:50:19Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [R8](), [Developer Tools](), [Android](), [obfuscation](), [Compilers and Linkers](), [APK]() Tags: [analysis](), [andriod-app-development](), [android](), [annotation](), [apk](), [apt](), [bytecode](), [compilation](), [compiler](), [dagger](), [debug](), [dependencies](), [inspection](), [java](), [jvm](), [kotlin](), [map](), [obfuscation](), [r8](), [source-code](), [tooling]() ### AI overview Inspecting compiled Dex output can reveal how source changes and dependency-provided R8 rules affect an Android app's binary, including whether debug code remains. Java or Kotlin source first becomes JVM .class files; annotation processors and Kotlin compiler plugins may generate or alter code at that stage. D8 converts classes and JAR/AAR dependencies into .dex files. When obfuscation or minification is enabled, R8 optimizes and obfuscates the bytecode and produces a mapping file recording name changes. The excerpt introduces tree shaking, which removes unused or unreachable code, and mentions inlining and outlining as structural optimizations. ### Source excerpt During the development process, we often focus on the source code but rarely inspect the compiled bytecode. This means we're missing out on a valuable source of information and data for analysis. How? Let's delve into Dex file inspection and build a tool that demonstrates how source code changes impact the compiled binary. Have you ever set R8 rules to obfuscate your app? Have you used an APK analyzer or a diffuse tool to understand how the code is compiled? Are you confident that debug code hasn't leaked into production? There's another potential pitfall: libraries may provide obfuscation rules (e.g., Gson) that merge with the ones in your project. This means third-party dependencies can alter configurations for the entire app. We often assume everything is fine and that we'll notice if something isn't right. But will we? Does this make you feel uneasy? Does it concern you? Because it certainly concerns me. Here, we'll attempt to enhance the situation and enable you to see precisely how your code changes impact the compiled binary. To better comprehend this, let's start with the code compilation process: It all begins with the Java and/or Kotlin source code, which is then compiled into JVM .class files. Note that at this stage, Java and Kotlin compilers can execute annotation processing tools (APT/KAPT) to generate source code (e.g., Dagger), and Kotlin compiler can run plugins to modify the internal code representation. Then, the D8 compiler takes these compiled classes, third-party libraries (JARs, AARs), and converts them into .dex files. However, if obfuscation and/or minification are enabled (which is almost always the case for release builds), R8 comes into play after D8. R8 obfuscates and optimises the bytecode, and additionally, R8 produces a source map file -- a special file listing all the changes and replacements. Obfuscation replaces human-readable names of various entities (classes, functions, fields, etc.) with very short, yet still unique names, for e ## How to break your Android App with proguard / R8 DevFeed: [How to break your Android App with proguard / R8]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2021-03-02T15:19:22Z Content type: article Language: en Sources: [YAZIO]() Topics: [R8](), [proguard](), [Android Testing](), [Android](), [Android Gradle Plugin](), [Software Testing]() Tags: [android](), [android-app-development](), [androiddev](), [app](), [proguard](), [r8]() ### AI overview A broad R8/ProGuard rule, `-assumenosideeffects class android.util.Log { public *; }`, can affect inherited public methods as well as logging calls. The article reports that this includes synchronization methods on `Object`, such as `notify`, potentially breaking app synchronization and causing hangs. It recommends avoiding `*` wildcards with `-assumenosideeffects` and specifying the logging signatures explicitly (`v`, `d`, `i`, `w`, `e`, and `println`) when removing production log calls. The author also warns that the issue can enter an app through a library's consumer ProGuard rules. ### Source excerpt I recently updated the android gradle plugin to 4.0.0. While developing, everything went smoothly and at some point I was ready to cut a release. The very last manual testing of the release app bundle was also fine so no Proguard / R8 issues on the first sight either. Then I thought: Let me check the CI results again. Everything was fine, but: The instrumentation tests. Almost all of them were timing out. After inspecting the logs, they all hang at the end of the on-boarding. Strangely the loading spinner was loading for way longer than the timeout should be. So I tested it on my phone and faced the same results. At that time I had no idea it was caused by updating AGP, so I did a 2 hours long git bisect. Okay, now lets create a minimal self reproducible bug report because I found a huge bug in AGP, everyone should know about immediately. I created a Hello World project that was making a single network call and printed it results into a TextView. Strangely here it did not reproduce. After experimenting with the OkHttp configuration and testing if it was related to some gradle plugin, I finally had the idea that it might be related to R8. So I added my proguard configuration and now the network call hang! Let's locate the issue further. I was step by step removing lines from my proguard configuration until only a single line was left: -assumenosideeffects class android.util.Log { public * ; } Now what is this? How is that even slightly related to anything? It should remove the log spam of some third party libraries we're using. So I was asking Mads Ager. (he works on D8/R8) you have to be very careful with -assumenosideeffects The problem is that in order for -assumenosideeffects to have the effect of actually removing calls, it matches up the class hierarchy. Therefore, this rule says that anything public in android.util.Log and its superclasses has no side-effects. That include the synchronization methods defined on Object. So, please don't use * wildcards in conne ## How to break your Android App with proguard / R8 DevFeed: [How to break your Android App with proguard / R8]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2020-06-08T05:52:07Z Content type: article Language: en Sources: [Paul Woitaschek]() Topics: [R8](), [proguard](), [Android](), [Android Testing](), [Software Testing](), [Concurrency](), [Android Gradle Plugin](), [Test automation](), [CI/CD]() Tags: [android](), [android-app-development](), [androiddev](), [proguard](), [r8]() ### AI overview After updating Android Gradle Plugin 4.0.0, the author traced hanging network calls and instrumentation-test timeouts to a ProGuard/R8 rule: `-assumenosideeffects class android.util.Log { public *; }`. The wildcard matched public methods through the class hierarchy, including synchronization methods inherited from `Object`; treating those as side-effect-free could remove essential synchronization. The proposed replacement lists logging signatures explicitly (`v`, `d`, `i`, `w`, `e`, and `println`) instead of using `public *`. The excerpt cautions that the rule can also arrive through a library's consumer ProGuard rules. ### Source excerpt I recently updated the android gradle plugin to 4.0.0. While developing, everything went smoothly and at some point I was ready to cut a release. The very last manual testing of the release app bundle was also fine so no Proguard / R8 issues on the first sight either. Then I thought: Let me check the CI results again. Everything was fine, but: The instrumentation tests. Almost all of them were timing out. After inspecting the logs, they all hang at the end of the on-boarding. Strangely the loading spinner was loading for way longer than the timeout should be. So I tested it on my phone and faced the same results. At that time I had no idea it was caused by updating AGP, so I did a 2 hours long git bisect. Okay, now lets create a minimal self reproducible bug report because I found a huge bug in AGP, everyone should know about immediately. I created a Hello World project that was making a single network call and printed it results into a TextView. Strangely here it did not reproduce. After experimenting with the OkHttp configuration and testing if it was related to some gradle plugin, I finally had the idea that it might be related to R8. So I added my proguard configuration and now the network call hang! Let's locate the issue further. I was step by step removing lines from my proguard configuration until only a single line was left: -assumenosideeffects class android.util.Log { public * ; } Now what is this? How is that even slightly related to anything? It should remove the log spam of some third party libraries we're using. So I was asking Mads Ager. (he works on D8/R8) you have to be very careful with -assumenosideeffects The problem is that in order for -assumenosideeffects to have the effect of actually removing calls, it matches up the class hierarchy. Therefore, this rule says that anything public in android.util.Log and its superclasses has no side-effects. That include the synchronization methods defined on Object. So, please don't use * wildcards in conne ## R8 Optimization: Lambda Groups DevFeed: [R8 Optimization: Lambda Groups]() Original publisher: [Read original article]() Published: 2020-04-30T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [R8](), [Optimization](), [Android](), [Kotlin](), [Java]() Tags: [android](), [apk](), [kotlin](), [lambda](), [optimization](), [r8]() ### AI overview An analysis of how R8 optimizes Kotlin lambda groups in Android applications, using compiled examples to compare the generated classes before and after optimization. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". Lambda usage in Kotlin feels more pervasive than Java because of the functional nature of the Kotlin standard library. Some lambdas are merely syntactic constructs that are eliminated at compile-time through the use of inline functions. The rest materialize into whole classes for use at runtime. The mechanisms by which lambdas work was covered in the Android Java 8 support post, but here's a quick refresher: javac hoists lambda bodies to a package-private method and writes an invoke-dynamic bytecode for the target lambda type at the call-site. The JVM spins a class at runtime of the desired type and invokes the package-private method in the method body. Android does not ship this runtime support, so D8 performs a compile-time transformation to a class which implements the desired type and which invokes the package-private method. kotlinc skips the invoke-dynamic bytecode (even when targeting Java 8+) and generates full classes directly. Here's two Kotlin classes and some lambda usage that we can experiment with. class Employee( val id: String, val joined: LocalDate, val managerId: String? ) class EmployeeRepository(val allEmployees: () -> Sequence) { fun joinedAfter(date: LocalDate) = allEmployees() .filter { it.joined >= date } .toList() fun reports(manager: Employee) = allEmployees() .filter { it.managerId == manager.id } .toList() } The EmployeeRepository class accepts a lambda which produces a sequence of employees and exposes two functions for listing the employees who joined after a particular date and those who report to a particular employee. Both functions use a lambda to filter the sequence to the desired items before converting to a list. Kotlin's approach to lambdas is immediately visible after compiling this class. $ kotlinc EmployeeRepos ## Which is better on Android: divide by 2 or shift by 1? DevFeed: [Which is better on Android: divide by 2 or shift by 1?]() Original publisher: [Read original article]() Published: 2020-04-23T00:00:00Z Content type: tutorial Language: en Sources: [Jake Wharton]() Topics: [Android](), [Kotlin](), [Compiler](), [Java](), [R8]() Tags: [android](), [compiler](), [kotlin](), [kotlin-multiplatform](), [optimization](), [r8](), [writing]() ### AI overview This article investigates whether dividing by 2 or shifting by 1 is better on Android. It examines how Java and Kotlin source code is transformed by javac or kotlinc, D8/R8, and ART, using bytecode and Dalvik bytecode examples. The discussion is motivated by work porting the AndroidX collection library to Kotlin Multiplatform and by concerns about performance, readability, and compiler optimization. ### Source excerpt I've been porting the AndroidX collection library to Kotlin multiplatform to experiment with binary compatibility, performance, tooling, and the different memory models. Some of the data structures in the library use array-based binary trees to store elements. The Java code has a lot of shifts to replace power-of-two multiplications and divides. When ported to Kotlin, these turn into the slightly-awkward infix operators which further obfuscate the intent of the code. I sampled a few people about bitwise shifts vs. multiplication/division and many had heard anecdotal claims of shifts having better performance, but everyone remained skeptical of whether it was true. Some assumed that one of the compilers seen before the code ran on a CPU would handle optimizing this case. In an effort to satisfy my curiosity (and partially to avoid Kotlin's infix bitwise operators) I set out to answer which is better and some other related questions. Let's go! Does anyone optimize this? There are three major compilers that code passes through before it hits the CPU: javac/kotlinc, D8/R8, and ART. Each of these has the opportunity to optimize. But do they? javac class Example { static int multiply(int value) { return value * 2; } static int divide(int value) { return value / 2; } static int shiftLeft(int value) { return value << 1; } static int shiftRight(int value) { return value >> 1; } } This Java can be compiled with javac from JDK 14 and the resulting bytecode can be displayed with javap. $ javac Example.java $ javap -c Example Compiled from "Example.java" class Example { static int multiply(int); Code: 0: iload_0 1: iconst_2 2: imul 3: ireturn static int divide(int); Code: 0: iload_0 1: iconst_2 2: idiv 3: ireturn static int shiftLeft(int); Code: 0: iload_0 1: iconst_1 2: ishl 3: ireturn static int shiftRight(int); Code: 0: iload_0 1: iconst_1 2: ishr 3: ireturn } Every method starts with iload_0 which loads the first argument value. The multiply and divide methods both then have ## D8 Optimization: Assertions DevFeed: [D8 Optimization: Assertions]() Original publisher: [Read original article]() Published: 2020-03-25T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Android](), [R8](), [Java](), [Concurrency]() Tags: [android](), [java](), [jvm](), [main-thread](), [optimization](), [r8](), [thread]() ### AI overview This article explains how D8 and R8 optimize Java assert statements in Android applications. Because Android does not support enabling Java assertions, D8 can remove the assertion check and its dependent expressions, allowing dead-code elimination. The example uses an assertion to enforce main-thread access when generating unique IDs, and the article connects this optimization to R8's SSA-based analysis. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". The assert keyword is quirky Java language syntax used for testing invariants. That is: things you expect to always be true. Its syntax has two forms: assert ; assert : ; The first expression will only be evaluated at runtime if the -ea (enable assertions) flag is set on the JVM. The second expression, if present, is used as the argument to the AssertionError constructor that's thrown if the first expression returns false. As an Android developer you might not be too familiar with assert. This is because every Android app runs on a VM which is forked from a shared "zygote" process which has assertions disabled. Thus, even if you put an assert in your code, there is no way to actually enable it. So why bother talking about it? Well it turns out they're about to become useful on Android for the first time! Today's behavior assert statements guard things which must always be true in order for your program to execute correctly. Let's write one. class IdGenerator { private int id = 0; int next() { assert Thread.currentThread() == Looper.getMainLooper().getThread(); return id++; } } This class creates unique IDs and guarantees they're unique by only allowing calls from the main thread. If this class was called concurrently from multiple threads you might see duplicate values. Sure it's a little contrived and there's things like @MainThread which is checked by Lint but we're focusing on assert so roll with it. The Null Data Flow Analysis post introduced the SSA form that R8 uses to eliminate branches of code which it can prove will never be executed. The SSA for the next() method when parsed from Java bytecode looks very roughly like this: D8 knows that Android does not support Java assertions. It will remove the check an ## Diving deep into Android Dex bytecode DevFeed: [Diving deep into Android Dex bytecode]() Original publisher: [Read original article]() Published: 2020-02-02T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [Android](), [Kotlin](), [R8](), [Compiler](), [Java](), [Mobile]() Tags: [android](), [bytecode](), [compiler](), [inlining](), [java](), [kotlin](), [memory](), [performance](), [r8]() ### AI overview This practical guide explains how Kotlin and Java code is transformed into Android DEX bytecode. It describes examining Java bytecode, the role of the Dalvik bytecode format and Android Runtime, and the compilation tools kotlinc, javac, d8, and R8, with attention to possible memory and performance effects. ### Source excerpt Source Introduction Modern Android development is based on Kotlin, which is interoperable with Java. Whenever we use some cool feature from Kotlin (say High-order functions) under the hood (when running on JVM) the feature is implemented in terms of Java bytecode. This might lead to some overheads in memory and performance if used without caution (for example excessive usage of lambdas with parameters without inlining might produce a lot of anonymous classes and put additional pressure on GC). ## Fixing the Initial Dispatchers.Main Delay in Kotlin Coroutines DevFeed: [Fixing the Initial Dispatchers.Main Delay in Kotlin Coroutines]() Original publisher: [Read original article]() Published: 2019-12-19T03:02:18Z Content type: tutorial Language: en Sources: [Colin The Shots]() Topics: [Coroutines](), [Kotlin](), [Android](), [R8](), [Optimization](), [Android Studio]() Tags: [android](), [android-studio](), [builds](), [coroutines](), [kotlin](), [kotlin-coroutines](), [optimization](), [r8]() ### AI overview This article explains an initial delay of up to a quarter second when Android apps first use Kotlin Coroutines' Dispatchers.Main. It attributes the delay to ServiceLoader triggering a checksum of the entire JAR inside the APK and describes a stable fix using Kotlin coroutines 1.3.3 or higher, required Proguard rules, and R8 optimization. ### Source excerpt Kotlin Coroutines have been almost unanimously received with applause by the Android software development community. However, there are some significant issues I have noticed in practice that are ## ProGuard & R8: Part 2 DevFeed: [ProGuard & R8: Part 2]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2019-11-20T09:00:00Z Content type: tutorial Language: en Sources: [Dustin Summers]() Topics: [R8](), [Android](), [Compiler](), [Android Studio](), [Java](), [Kotlin]() Tags: [android](), [android-studio](), [code](), [compiler](), [java](), [kotlin](), [proguard](), [proguard-android-r8-smali-dalvik-jvm-kotlin-art-gradle-java](), [r8](), [sdk](), [terminal]() ### AI overview A hands-on tutorial covering the Android build pipeline with ProGuard and R8. It walks through compiling Java or Kotlin source code, using Android Build Tools, and examining generated bytecode. ### Source excerpt This blog post is the second in a series to teach about the build tools ProGuard and R8, and the first in the hands-on portion of the series. In the first post I talked about the Android Build Pipeline. In this blog, I would like to actually reinforce those concepts with hands on exercises. If you haven't read the first blog on this topic, this is part two in that series, so I highly suggest going back and understanding that material first. ## Understanding the Android Build Pipeline with ProGuard and R8 DevFeed: [Understanding the Android Build Pipeline with ProGuard and R8]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2019-11-06T12:08:40Z Content type: tutorial Language: en Sources: [Dustin Summers]() Topics: [R8](), [Code](), [obfuscation](), [software-development](), [Software]() Tags: [android](), [compilation](), [obfuscation](), [proguard](), [proguard-android-r8-smali-dalvik-jvm-kotlin-art-gradle-java](), [r8](), [software-development](), [tutorials]() ### AI overview A tutorial explaining the Android build pipeline and where ProGuard and R8 fit into it. It introduces compilation stages, optimization, shrinking, and code obfuscation, with an emphasis on understanding and diagnosing how these tools transform source code into bytecode. ### Source excerpt Tools such as R8 and ProGuard are available for free, but to many they are a black box that code goes into and stuff comes out. My goal is to demystify the black box and teach developers how to properly diagnose the code going into and coming out of these build tools. It will also explain why you should care and why applying these tools should be a priority before shipping any code into the wild. ## D8 Optimizations DevFeed: [D8 Optimizations]() Original publisher: [Read original article]() Published: 2019-10-30T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Android](), [Optimization](), [Compiler](), [Java](), [R8]() Tags: [android](), [code](), [compiler](), [java](), [optimization](), [performance](), [r8]() ### AI overview D8 Optimizations explains how D8, Android's Java-to-Dalvik bytecode compiler, performs local optimizations in addition to Java language backporting and platform bug workarounds. It discusses rewriting switch statements when the resulting Dalvik bytecode is smaller and evaluating certain constant method calls at compile time. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". No, that's not a typo! While the optimizations in this series so far have been done by R8 during whole-program optimization, D8 can also perform some simple optimizations. D8 was introduced as the new Java-to-Dalvik bytecode compiler for Android. It handles backporting of Java 8 language features to work on Android (as well as those of Java 9 and beyond). It also works around vendor- and version-specific bugs in the platform. That's what we've seen from D8 so far in the series, but it has two other responsibilities that we'll cover in this post and the next: Backporting methods to work on older API levels where they didn't exist. Performing local optimizations to reduce bytecode size and/or improve performance. We'll cover API backporting in the next post in the series. For now, let's look at some of the local optimizations that D8 might perform. Switch Rewriting The last two posts (1, 2) have dealt with optimizing switch statements. Both have slightly lied about the bytecode that D8 and R8 produce for certain switch statements. Let's look at one of those examples again. enum Greeting { FORMAL, INFORMAL; static String greetingType(Greeting greeting) { switch (greeting) { case FORMAL: return "formal"; case INFORMAL: return "informal"; default: throw new AssertionError(); } } } The full Java bytecode that was shown for greetingType used the lookupswitch bytecode which has offsets for where to jump when a value is matched. static java.lang.String greetingType(Greeting); Code: 0: getstatic #2 // Field Main$1.$SwitchMap$Greeting:[I 3: aload_0 4: invokevirtual #3 // Method Greeting.ordinal:()I 7: iaload 8: lookupswitch { 1: 36 2: 39 default: 42 } 36: ldc #4 // String formal 38: areturn 39: ldc #5 // String informal 41: areturn 42: new #6 // class java/lang/AssertionE ## R8 Optimization: Enum Switch Maps DevFeed: [R8 Optimization: Enum Switch Maps]() Original publisher: [Read original article]() Published: 2019-10-16T00:00:00Z Content type: tutorial Language: en Sources: [Jake Wharton]() Topics: [R8](), [Optimization](), [Android](), [Java](), [Compiler](), [Code]() Tags: [android](), [code](), [compiler](), [java](), [optimization](), [r8]() ### AI overview This article explains how Java enum switch statements are compiled and how R8 optimizes them. It describes the generated switch-map array that translates enum ordinals into stable branch values, allowing the application to continue working when enum constants are reordered and only part of the code is recompiled. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". The previous post on R8 covered enum ordinals which then allowed branch elimination to apply to a switch statement. In that post, the full bytecode for switch on an enum was omitted because there's actually more to the optimization. Let's start with a simple enum and a switch over its contents in two separate source files (this will be important later). enum Greeting { FORMAL, INFORMAL } class Main { static String greetingType(Greeting greeting) { switch (greeting) { case FORMAL: return "formal"; case INFORMAL: return "informal"; default: throw new AssertionError(); } } public static void main(String... args) { System.out.println(greetingType(Greeting.INFORMAL)); } } If we compile and run these files the output is as expected. $ javac Greeting.java Main.java $ java -cp . Main informal The bytecode in the previous post showed that the compiler produces a call to ordinal() which is then used in the switch. But if that was all that the compiler did, re-ordering the constants of Greeting would break the output of Main. enum Greeting { - FORMAL, INFORMAL + INFORMAL, FORMAL } After changing the constant order, we can recompile only Greeting.java and yet the application still produces the correct output. $ javac Greeting.java $ java -cp . Main informal If the bytecode was only relying on the value of ordinal(), this code would have produced "formal". Into The Bytecode To understand how this works we can look at the Java bytecode of greetingType. $ javap -c Main.class class Main { static java.lang.String greetingType(Greeting); Code: 0: getstatic #2 // Field Main$1.$SwitchMap$Greeting:[I 3: aload_0 4: invokevirtual #3 // Method Greeting.ordinal:()I 7: iaload 8: lookupswitch { 1: 36 2: 39 default: 42 } 36: ldc #4 // String formal 38: areturn 39: ldc #5 // String informa ## R8 Optimization: Enum Ordinals and Names DevFeed: [R8 Optimization: Enum Ordinals and Names]() Original publisher: [Read original article]() Published: 2019-10-09T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Optimization](), [R8](), [Java](), [Android](), [Compiler](), [Data structures]() Tags: [android](), [compiler](), [display](), [enum](), [java](), [optimization](), [r8](), [serialization]() ### AI overview This article explains how R8 optimizes Java enums in Android applications. It focuses on replacing compile-time-known enum ordinal lookups with integer values, enabling switch-branch elimination, and inlining enum name access when appropriate. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". Enums are (and have always been!) a recommended way to model a fixed set of constants. Most commonly an enum only provides a set of possible constants and nothing more. But being full classes, enums can also carry helper methods and fields (both instance and static) or even implement interfaces. A common optimization for enums in tools that perform whole-program optimization is to replace simple occurrences (i.e., those which don't have fields, methods, or interfaces) with integer values. However, there are other optimizations which are applicable to all enums that are still available. Ordinal Each enum constant has an ordinal() which returns its position in the list of all constants. Since the ordinal range is always [0, N), it can be used for indexing into other zero-based data structures such as arrays or even bits. The most common usage is actually by the Java compiler itself for switch statements over enums. enum Greeting { FORMAL { @Override String greet(String name) { return "Hello, " + name; } }, INFORMAL { @Override String greet(String name) { return "Hey " + name + '!'; } }; abstract String greet(String name); static String type(Greeting greeting) { switch (greeting) { case FORMAL: return "formal"; case INFORMAL: return "informal"; default: throw new AssertionError(); } } } The compiled bytecode reveals the hidden call to ordinal(). [000a34] Greeting.type:(LGreeting;)Ljava/lang/String; 0000: invoke-virtual {v1}, LGreeting;.ordinal:()I 0003: move-result v1 ⋮ If we call this method with one of the constants, an opportunity for optimization presents itself. public static void main(String... args) { System.out.println(Greeting.type(Greeting.INFORMAL)); } As this is the only usage of type in our whole application, R8 inlines the method. [000b60] Greeter.ma [Next page]()