# R8 R8 is an Android app optimizer that removes unused code and resources, rewrites code for efficiency, and reduces app size and runtime overhead. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 Blog](), [Android Developers Blog]() 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: Android Developers (noreply@blogger.com) Published: 2026-08-18T18:00:00Z Content type: article Language: en Sources: [Android Developers Blog]() Topics: [R8](), [Android](), [Optimization](), [configuration](), [audit]() Tags: [android](), [anr](), [audit](), [configuration](), [metrics](), [obfuscation](), [optimization](), [r8]() ### AI overview This developer case study explains how Tinder used the R8 Configuration Analyzer to identify and remove keep-rule blockers in its Android application. The reported results were a 47% reduction in cold-start time, a 28.98% reduction in download size to 61.5 MB, and a 28% reduction in user-perceived ANRs. The article also describes analyzer metrics for shrinking, optimization, and obfuscation, along with an R8 Analyzer skill for agentic development workflows. ### 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 ## The Hidden Costs of DIY Android App Security | Guardsquare DevFeed: [The Hidden Costs of DIY Android App Security | Guardsquare]() Original publisher: [Read original article]() Author: Michael Olechna - Product Marketing Manager Published: 2026-07-28T13:00:55Z Content type: opinion Language: en Sources: [Guardsquare Blog]() Topics: [Security](), [Android](), [Mobile](), [obfuscation](), [R8](), [Open Source]() Tags: [android](), [dexguard](), [mobile](), [obfuscation](), [open-source](), [protection](), [r8](), [security](), [thought-leadership](), [threat-monitoring]() ### AI overview The article argues that DIY Android app security built around open-source tools can leave important protection gaps. It explains that R8 helps compile and optimize Android applications but is not a complete security solution, lacking capabilities such as string encryption, API endpoint security, and control-flow obfuscation. ### Source excerpt The DIY temptation to build with open-source is strong for mobile app developers. After all, their job is to build, secure, and design new applications, features, and architectures that benefit the users of their apps. ## 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 Blog]() Topics: [Coroutines](), [Kotlin](), [R8](), [Android](), [Compose](), [Programming]() Tags: [android](), [android-gradle-plugin](), [app-performance](), [atomic](), [compose](), [coroutines](), [jetpack-compose](), [kotlin](), [perfetto](), [performance](), [programming](), [r8]() ### AI overview This article explains how R8 in AGP 9.2.0 optimizes Atomic*FieldUpdater calls into Unsafe variants, improving common operations by 2x to 4x. The optimization particularly benefits kotlinx.atomicfu and can make launching and cancelling Kotlin coroutines up to 2x faster. It also describes how coroutine overhead affected Jetpack Compose performance and how ART method traces helped identify bottlenecks. ### 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 ## 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 Blog](), [Android Developers Blog]() Topics: [Coroutines](), [Kotlin](), [R8](), [Android](), [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 ## 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: tutorial Language: en Sources: [Stories by Kirill Rozov on Medium]() Topics: [Android](), [obfuscation](), [R8](), [Reverse Engineering](), [Java](), [Optimization](), [configuration]() Tags: [android](), [configuration](), [java](), [obfuscation](), [optimization](), [proguard](), [r8](), [reverse-engineering](), [security]() ### AI overview This tutorial explains how R8 and ProGuard obfuscate Android applications and why their default naming dictionaries can make reverse engineering easier. It presents custom dictionary configuration, Java reserved-keyword names, invalid Windows filename names, and per-build randomized dictionaries, while noting compatibility and testing risks. ### 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 ## The curious case of a weird VerifyError crash DevFeed: [The curious case of a weird VerifyError crash]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2025-04-06T00:00:00Z Content type: article Language: en Sources: [Posts on Marco Gomiero]() Topics: [Android](), [debugging](), [R8](), [Kotlin](), [Compose]() Tags: [android](), [android-gradle-plugin](), [crash](), [debugging](), [dependency](), [issue](), [kotlin](), [r8]() ### AI overview A journal-style debugging account of a VerifyError runtime crash in FeedFlow's Android release build after upgrading the Android Gradle Plugin to version 8.7. The investigation tests R8, Compose, Kotlin, and dependency combinations, then narrows the problem to code in the dependency graph involving date-string parsing. ### Source excerpt This post can be considered as a journal entry. I had to clear my thoughts and vent off through writing after spending time debugging this issue. Maybe it will be helpful for future references or an example of the process to follow in such cases. The other day I was doing the usual dependency update routine of FeedFlow when I discovered a runtime crash that happened in the release version (so with R8 enabled) after updating the Android Gradle Plugin (AGP, in the rest of the article) to version 8.7. ## 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: tutorial Language: en Sources: [Bumble Tech]() Topics: [Android](), [Tooling](), [APK](), [obfuscation](), [R8](), [Kotlin](), [Java](), [Compiler]() Tags: [andriod-app-development](), [android](), [apk](), [bytecode](), [compilation](), [compiler](), [dagger](), [inlining](), [java](), [kotlin](), [obfuscation](), [optimization](), [r8](), [tooling]() ### AI overview This tutorial introduces Android bytecode analysis through DEX inspection and a tool for examining how source-code changes affect compiled binaries. It explains the Android compilation pipeline from Java or Kotlin source through JVM class files and D8-generated DEX files, then describes R8 obfuscation and optimization, including source maps, tree-shaking, inlining, and outlining. ### 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 ## Влияние Kotlin data-классов на вес приложения DevFeed: [Влияние Kotlin data-классов на вес приложения]() Original publisher: [Read original article]() Author: ChPr (Badoo) Published: 2021-03-04T14:13:38Z Content type: article Language: ru Sources: [Badoo EN](), [Badoo RU]() Topics: [data](), [Kotlin](), [R8]() Tags: [android](), [android-development](), [data](), [kotlin](), [kotlin-compiler](), [r8]() ### AI overview A Kotlin developer investigates the cost of using many data classes in an application. The article describes an experiment involving replacing data classes with ordinary classes and discusses how release optimizers such as R8 affect their generated methods. ### Source excerpt Kotlin имеет много классных особенностей: null safety, smart casts, интерполяция строк и другие. Но одной из самых любимых разработчиками, по моим наблюдениям, являются data-классы. Настолько любимой, что их часто используют даже там, где никакой функциональности data-класса не требуется. В этой статье я с помощью эксперимента постараюсь понять, какова реальная цена использования большого количества data-классов в приложении. Я попробую удалить все data-классы, не сломав компиляцию, но сломав приложение, а потом расскажу о результатах и выводах этого эксперимента. Читать дальше -> ## Wildcard ProGuard/R8 Rule Can Remove Android Synchronization Calls DevFeed: [Wildcard ProGuard/R8 Rule Can Remove Android Synchronization Calls]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2021-03-02T15:19:22Z Content type: tutorial Language: en Sources: [YAZIO Engineering - Medium]() Topics: [Android](), [R8](), [Android Gradle Plugin](), [configuration](), [Testing]() Tags: [android](), [android-app-development](), [android-gradle-plugin](), [androiddev](), [configuration](), [instrumentation](), [proguard](), [r8](), [testing]() ### AI overview An Android debugging article explains how instrumentation tests and a network call began hanging after an Android Gradle Plugin update. The cause was a ProGuard/R8 `-assumenosideeffects` rule using a wildcard for `android.util.Log`, which also matched superclass methods including synchronization methods on `Object`. ### 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 an R8 ProGuard rule can break Android application synchronization DevFeed: [How an R8 ProGuard rule can break Android application synchronization]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2020-06-08T05:52:07Z Content type: tutorial Language: en Sources: [Stories by Paul Woitaschek on Medium]() Topics: [R8](), [Android Gradle Plugin](), [Android](), [Testing](), [Concurrent Programming]() Tags: [android](), [android-app-development](), [android-gradle-plugin](), [androiddev](), [bug](), [ci](), [configuration](), [proguard](), [r8](), [synchronization](), [testing]() ### AI overview The article investigates Android instrumentation tests and network calls hanging after an Android Gradle Plugin update. It traces the behavior to the R8 rule `-assumenosideeffects class android.util.Log { public * ; }`, which can treat synchronization methods inherited from `Object` as having no side effects. The author recommends avoiding wildcards with `-assumenosideeffects` and specifying exact signatures. ### 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 Multiplatform](), [Compiler](), [Kotlin](), [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](), [Concurrent Programming]() 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-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. ## 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 ## R8 Optimization: Class Reflection and Forced Inlining DevFeed: [R8 Optimization: Class Reflection and Forced Inlining]() Original publisher: [Read original article]() Published: 2019-09-25T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [R8](), [Optimization](), [Android](), [obfuscation]() Tags: [android](), [code](), [inlining](), [obfuscation](), [optimization](), [r8]() ### AI overview This article explains how R8 optimizes Java class reflection in Android applications. It contrasts static class literals with instance getClass() calls, then describes how whole-program analysis can replace reflective calls with known class references and string constants. It also examines a case where method inlining is blocked by method-size limits and introduces forced inlining through R8 configuration rules compatible with ProGuard. ### 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 method outlining which automatically de-duplicated code. This was actually a detour from what I had promised was next at the end of the class constant operations post which preceded it. So let's get back on track. Class constant operations allow R8 to take calls such as MyActivity.class.getSimpleName() and replace it with the string literal "MyActivity". This was presented in the context of log tags, where you might write that expression instead of the string literal so that the tag always reflects the actual class name, even after obfuscation. This works great in a static context where the MyActivity.class literal is fixed, but it does not work when used on an instance. Instance reflection When dealing with an instance, the Class reference is obtained by calling getClass() instead of a MyActivity.class literal. This operation is not terribly expensive, but it is still a form of reflection. class MyActivity extends Activity { @Override void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); String name = this.getClass().getSimpleName(); Log.e(name, "Hello!"); } } The getClass() API is just a normal method on every Object and appears as a normal invoke-virtual in bytecode. [0003d0] MyActivity.onCreate:(Landroid/os/Bundle;)V 0000: invoke-super {v1, v2}, Landroid/app/Activity;.onCreate:(Landroid/os/Bundle;)V 0003: invoke-virtual {v1}, Ljava/lang/Object;.getClass:()Ljava/lang/Class; 0006: move-result-object v2 0007: invoke-virtual {v2}, Ljava/lang/Class;.getSimpleName:()Ljava/lang/String; 000a: move-result-object v2 Since R8 is performing whole-program analysis, it knows that there are no subtypes of MyActivity even though it's not marked as final. As a result, it can replace calls to this.getClass() with MyAct ## R8 Optimization: Method Outlining DevFeed: [R8 Optimization: Method Outlining]() Original publisher: [Read original article]() Published: 2019-04-11T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [R8](), [Optimization](), [Android](), [Code](), [JSON]() Tags: [android](), [code](), [examples](), [exception](), [java](), [json](), [optimization](), [r8](), [reduce]() ### AI overview This article explains how R8 optimization can make duplicated generated code smaller than a generated helper method in an Android APK. Using Moshi-style JSON parsing as the example, it discusses repeated exceptions and string-building logic generated for non-null properties, and why R8 method outlining and related optimizations affect the final bytecode size. ### 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". I recently wrote about the economics of generated code which talked about performing optimizations to generated code that aren't worthwhile in manually-written code. While the examples in that post were motivated by changes to code generators that I had worked on in the past, it also resulted in some new changes being made. One change proposed to Moshi, a JSON serializer, replaced its generated strings with StringBuilder to de-duplicate the constant parts. Each non-null property in your JSON model generates an exception to ensure non-null values are read from the JSON. name = stringAdapter.fromJson(reader) ?: throw JsonDataException( - "Non-null value 'name' was null at ${reader.path}") + StringBuilder("Non-null value '").append("name") + .append("' was null at ").append(reader.path).toString()) A second exception is generated when that non-null property lacks a default value and no value was present in the JSON. return Person( name = name ?: throw JsonDataException( - "Required property 'name' missing at ${reader.path}"), + StringBuilder("Required property '").append("name") + .append("' missing at ").append(reader.path).toString()), These two diffs are the result of applying the advice from that post. Each of these exceptions are generated for every property in the type. This means if you have a type with 10 properties you get 20 exceptions generated (assuming they're non-null and don't have default values). This winds up creating a lot of StringBuilder bytecode! One way to reduce this bytecode bloat is to generate a private method which takes four arguments (prefix, name, suffix, path) and returns the final string. This was proposed as part of the change to Moshi. We ultimately duplicated the code instead of generating a method because it ends up optimizing [Next page]()