# 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. ## 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 ## 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. ## 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 ## Android Studio Quail 3 Canary 3 now available DevFeed: [Android Studio Quail 3 Canary 3 now available]() Original publisher: [Read original article]() Author: Android Studio Releaser (noreply@blogger.com) Published: 2026-07-02T15:19:27Z Content type: release Language: en Sources: [Android Studio Release Updates]() Topics: [Android Studio](), [Android Gradle Plugin](), [Release notes]() Tags: [android](), [android-gradle-plugin](), [android-studio](), [r8](), [release](), [release-notes]() ### AI overview Android Studio Quail 3 Canary 3 is available in the Canary channel. The release includes general fixes and features for Android Studio and Android Gradle Plugin 9.4.0-alpha03, with additional fixed issues documented in the release information. ### Source excerpt Android Studio Quail 3 Canary 3 is now available in the Canary channel. If you already have an Android Studio build on the Canary channel, you can get the update by clicking Help > Check for Updates (or Android Studio > Check for Updates on macOS). Otherwise, you can download it here. For information on new features and changes in Android Studio Quail 3, see the Android Studio Preview release notes. For details of bugs fixed in each previous release of Android Studio Quail 3, see closed issues. General fixes and features Below is a list of general fixes in Android Studio Quail 3 Canary 3 and Android Gradle Plugin 9.4.0-alpha03. These are a result of your bug reports, which help us to make Android Studio better. If you encounter a problem, let us know by reporting a bug. You can also vote for an existing issue to indicate that it also affects you. Fixed Issues Database Inspector Issue #528792471 Database Inspector can't edit/delete database rows Shrinker (R8) Issue #146403477 L8 obfucation mapping not included in app mapping.txt ## 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 ## Comparing Jetpack Compose performance with XML DevFeed: [Comparing Jetpack Compose performance with XML]() Original publisher: [Read original article]() Author: Pratham Arora Published: 2022-08-09T05:41:24Z Content type: article Language: en Sources: [OkCredit - Medium]() Topics: [Jetpack Compose](), [XML](), [Android]() Tags: [android](), [android-app-development](), [compose](), [engineering](), [jetpack-compose](), [mobile-app-development](), [performance](), [r8](), [xml]() ### AI overview An Android team compares Jetpack Compose and XML-based layouts in production using frozen-frame rate, slow-frame rate, and median page-load duration. The article also examines Android Runtime AOT compilation as context for the measured results. ### Source excerpt As Jetpack compose is progressing towards stability, our team decided to measure the performance differences between Compose and XML-based layouts to build the foundation for gradually moving towards Jetpack compose. The differences were measured in terms of frozen frames, slow frames and page load duration. Additionally, we deep-dived into how Android Runtime (ART) optimises the performance by using Ahead-of-time (AOT) compilation. Both the below-mentioned experiments were performed on Production build with R8 enabled. Compose version used throughout was 1.1.0 Let's get started... Experiment -- 1 To begin with, we decided to convert one of the existing screens from XML to compose. Then, using our internal A/B experimentation platform, we made 2 equal cohorts/groups of users. The first cohort would experience the old XML-based screen whereas the other cohort would experience the newly compose built screen. Aim -- To understand the rendering performance of both the screens by comparing frozen frame rate, slow frame rate and page load duration. Screen -- This screen shows all the transactions as well as their summary in an interval. Results - Frozen frame percentage: For compose-based layout, the frozen frame rate came out to be 0.044% whereas it was 0.034% for XML-based layout. An alternate way to understand this can be, that if we open this XML-based activity, then nearly 3.4 frames out of 10,000 frames would fall under the frozen frame category. Similarly, for the compose-based activity, it would be 4.3 frames out of 10,000 frames. Slow frame percentage: For compose-based layout, the slow frame rate came out to be 8.91% whereas it was 9.93% for XML-based layout. Like frozen frames, ~10 out of 100 frames would fall under the slow frame category for XML-based layout. Whereas it was ~9 out of 100 frames for compose-based activity. Median Page Load Duration (in milliseconds): Internally, we define page load duration as the time taken from launching an activity to drawing it ## Влияние 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 ## Analyze Stack Traces in Android Studio DevFeed: [Analyze Stack Traces in Android Studio]() Original publisher: [Read original article]() Author: Segun Famisa Published: 2020-06-22T09:00:00Z Content type: tutorial Language: en Sources: [Segun Famisa]() Topics: [Android Studio](), [debugging](), [Development](), [Firebase]() Tags: [android](), [android-studio](), [debug](), [debugging](), [firebase](), [proguard](), [r8]() ### AI overview A tutorial on using Android Studio's built-in stack trace analysis tool to format imported crash reports and make their entries clickable and navigable. It also discusses obfuscated stack traces from release builds using ProGuard or R8/D8. ### Source excerpt Introduction As programmers, we spend a significant part of our time debugging errors. Stack traces are very useful in doing so, and careful analysis of the stack traces help us to locate and fix the problem. In this post, I'll show a quick way we can use Android Studio to make it easier to debug errors using the built-in "stack trace analysis" tool. Context As Android developers, once an app is released into the wild (i.e deployed on a device outside our development environment), we have to rely on crash reporting tools like Firebase Crash reporting, Instabug, Appsee, etc, to collect these reports and aggregate them for us. The experience of working with stack traces varies from whether we are in development or in production. In development, we often get the stack traces right there in the logcat of Android Studio where each line in the stack trace is a clickable link that takes us straight to corresponding line of code. On the other hand, when we collect crash reports and stack traces in the wild, we collect them as text - sometimes formatted, sometimes not. This adds the additional overhead of having to format the stack trace in order to be human-readable and then manually search for the corresponding lines of code in the IDE. Using the "Anaylze Stack Trace" tool Luckily for us, Android Studio solves a part of this problem and makes it easier for us when we are analyzing stack traces that are generated in the wild. When you receive a stack trace, you can import them into Android Studio and introduce all the nice formatting, hyperlink and navigating functionality that we get as if it's a crash from the logcat. The Android Developer docs page pretty much explains how to use this tool, but I'll summarize the steps here: In the Android Studio menu bar, navigate to "Analyze > Analyze Stack Trace or Thread Dump" Paste the stack trace in the window Click "Normalize" to format the stack trace - in case it is not already formatted. Click on "OK" to complete this. On click ## 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. [Next page]()