Category Archives: Android Developers Blog

An Open Handset Alliance Project

Android Support for Kotlin Multiplatform to Share Business Logic Across Mobile, Web, Server, and Desktop Platforms

Posted by Maru Ahues Bouza – Director, Product Management, and Jeffrey van Gogh – Director, Engineering

Traditionally, developers must either write code individually for each platform they want to target, or make a number of compromises in order to reuse code across platforms. Android has been actively supporting Kotlin since 2017, and today we are excited to announce we are supporting Kotlin Multiplatform on Android, which enables sharing code across mobile, web, server, and desktop platforms. This helps increase productivity for developers, and fits great with Android's Kotlin-first approach, resulting in higher quality Android apps. Our focus is to support sharing business logic (the parts that are most agnostic to the user interfaces) because we've seen Android developers get the most value in not having to maintain duplicate copies of this code.

Kotlin Multiplatform (KMP) has been a long-standing investment for the team behind Google Workspace, allowing for flexibility and speed in delivering valuable cross-platform experiences. The Google Workspace team is enthusiastic about KMP's potential as the direction for its multi-platform architecture investment, confident in its ability to meet performance expectations for various workloads.

The initial step in this journey is the rollout of the Google Docs app for Android, iOS, and Web, which leverages KMP for shared business logic, validating its readiness for production use at Google scale. The Google Workspace team is thrilled to continue exploring the possibilities of KMP across its product suite, aiming to enhance productivity and deliver seamless experiences to users on all platforms.

We see a lot of companies successfully leveraging Kotlin Multiplatform for cross-platform development of their apps, learn how they apply different code-sharing strategies here.

Kotlin Multiplatform, developed by JetBrains, provides a novel approach to sharing code across platforms by compiling Kotlin to platform-native binaries. Kotlin is able to provide the full, modern, memory managed language to native platforms enabling native interoperability and incremental adoption. Kotlin on Android, combined with Kotlin Multiplatform on other platforms, provides a great way to increase productivity and quality, without compromising on performance or interoperability.

Architecture overview for Kotlin Multiplatform (KMP)
Kotlin Multiplatform Architecture

Current Status of Support

Many widely-used libraries offer built-in support for Kotlin Multiplatform, streamlining your cross-platform development experience. These libraries work seamlessly together. For example, Ktor simplifies networking tasks by handling REST service consumption, while kotlinx.serialization converts data to formats like JSON, and Okio manages essential file I/O. Additionally, SKIE facilitates the use of modern types and coroutines on iOS, and CocoaPods integration enables the use of iOS-specific dependencies.

We've worked with JetBrains and the Kotlin developer community to add Kotlin Multiplatform support to a number of Jetpack libraries and in some cases provide the iOS platform targets, while in others, JetBrains and the community provide the multiplatform distributions.

Today, the Annotations, Collections, and DataStore libraries all have support for Kotlin Multiplatform in stable versions. We are also adding support to validate binary compatibility for the iOS platform targets, bringing them on a par with the quality standards for Android. In addition to the libraries above, we've also begun working on Kotlin Multiplatform support for Room, Lifecycle, and ViewModels with alpha versions now available. To better understand which classes and functions are available where, the library reference documentation now indicates "common" and platform support.

Indication of Common, Native and Android support in documentation
Indication of Common, Native and Android support in documentation

Android engineers have collaborated with JetBrains on the Kotlin compiler to improve runtime performance in Kotlin/Native (for iOS & native desktop operating systems), showing 18% runtime performance improvements in compiler benchmarks. In addition the Android team contributed to build time performance improvements for the Kotlin Native Compiler of up to 2x speed ups.

The Android Gradle Plugin now has official support for Kotlin Multiplatform, enabling a concise build definition for setting up Android as a platform target for shared code as shown below:

plugins {
    id("org.jetbrains.kotlin.multiplatform")
    id("com.android.library")
}

kotlin {
    androidTarget {
        compilations.all {
            kotlinOptions {
                jvmTarget = "11"
            }
        }
    }  
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "Shared"
            isStatic = true
        }
    }    
    sourceSets {
        commonMain.dependencies {
            // put your Multiplatform dependencies here
        }
    }
}
KMP Support in the Android Gradle Plugin DSL

As Android Studio is based on the IntelliJ Platform from JetBrains, it inherits support for Kotlin Multiplatform code editing and many other development features. Other Android development tools like Android Lint and Kotlin Symbol Processing (KSP) are also beginning to add more Kotlin Multiplatform support as well.

Google Chrome now has official support for WasmGC which is used by Kotlin Multiplatform's WebAssembly platform target to enable code sharing with the browser in an efficient and performant way.

Latest details on these projects are available on the updated Android Kotlin Multiplatform page.

Future Areas of Work

We've heard from many Android developers and Google engineering teams that they want expanded support for Kotlin Multiplatform so they can more easily share code with other platforms. Android plans to continue collaborating with JetBrains, Google engineering teams, and the community on a variety of projects, including:

    • Expanding and stabilizing Jetpack libraries with Kotlin Multiplatform support
    • Wasm platform target support in Jetpack libraries
    • Kotlin/Native build performance
    • Kotlin/Native debugging
    • Expanding Kotlin Multiplatform support in Android Studio

Learn More and Try It Out

Sharing code with Kotlin Multiplatform between Android and other platforms enables higher developer productivity and quality so we hope you will give it a try! You can use the Kotlin Multiplatform wizard to create a new KMP project. Learn more in the documentation.

Alternatively, explore one of these sample projects showcasing how to use some of the Jetpack libraries with Kotlin Multiplatform:

If there are additional areas you would like Android to work on let us know and also be a part of our vibrant Android Developer community on LinkedIn, Medium, YouTube, and X.

Build better, safer SDKs with Google Play SDK Console

Posted by Yafit Becher – Product Manager

SDKs offer a wide range of benefits for app developers, but they can also impact apps in ways that aren’t always easy to identify or control. That’s why, in 2021, we launched Google Play SDK Console and invited some of the most widely adopted SDKs to join, empowering SDK providers to improve the performance, quality, and security of their SDKs.

SDK Console allows SDK providers to access usage statistics, crash and ANR (application not responding) reporting, and tools to help them guide app developers in adopting SDK versions that fix quality issues and comply with Play policies.

Based on the success of our early access program for both SDK providers and app developers, today we’re pleased to make SDK Console available to all SDKs, as long as they're distributed from a canonical Maven repository source that we can verify.

Improve communication between SDK providers and app developers

Without clear communication between SDK providers and app developers, problems can be hard to identify and slow to resolve. SDK providers don’t always know how their SDKs are performing in the wild, so app developers often have to wait for bug fixes or use outdated SDK versions.

SDK Console bridges this gap by giving SDK providers visibility into usage and adoption stats, crash and ANR reporting, and a communication channel with app developers. With access to crash and ANR reporting across apps, SDK providers can identify and solve issues before they escalate into customer complaints.

Once resolved, SDK providers can report back to the developers with the reason for the crash and how to solve it. SDK providers can also receive a full stack trace report directly from app developers, ensuring all information is shared for a quick fix.

Screenshot of ANR reporting in SDK Console
click to enlarge

SDK providers can also encourage app developers to upgrade to newer SDK versions or provide guidance for a particular SDK version. SDK Console lets SDK providers add notes to their versions, report them as outdated, and for SDK versions that are very behind and have little usage, give app developers 90 days to update their SDK version, after which they would no longer be allowed to publish new app releases with those SDK versions.

Screenshot of prompt to report version as outdated in SDK Console
click to enlarge

Build with confidence with insights and timely updates

Many SDK providers struggle to collect usage and adoption data for their SDKs, making it difficult to make informed decisions about their future development efforts. SDK Console fills in these gaps by providing detailed usage and adoption stats by app category, country, or even SDK version.

Screenshot of market share metrics available in SDK Console
click to enlarge

As part of our commitment to a safe user experience, Google Play policies are constantly evolving. While it’s essential for maintaining a secure ecosystem, we know that keeping track of these updates can be a challenge for SDK providers. SDK Console will help simplify this process by notifying SDK providers about policy issues within the platform.

Get started with SDK Console

SDK Console is free for all SDK providers. Head over to Google Play SDK Console to get started.

More frequent, focused updates for Android Studio

Posted by Adarsh Fernando, Senior Product Manager, Android Studio

Three years ago, we changed how we named and versioned Android Studio to make it easier to follow updates – we changed how we numbered the versions of the IDE to more closely map to versioning of the IntelliJ IDEA platform, on which Android Studio is built. We also introduced animal codenames to signify each major release, starting with Arctic Fox. Our most recent release, Koala (2024.1.1), will soon be available in the Beta channel and is built on top of IntelliJ IDEA 2024.1. All Studio releases use a version number that maps to the following schema:

<Year of IntelliJ Version>.<IntelliJ major version>.<Studio major version>

Soon, we are launching the Koala Feature Drop to the Canary channel as version 2024.1.2 — our second release based on IntelliJ IDEA 2024.1. This signals the start of an improved release cycle, where each animal codename includes two major Studio releases: a platform update followed by a feature drop.

The initial animal releases will have the ‘.1’ Android Studio major version and introduce the updated IntelliJ platform version, while subsequent Feature Drops will increase the Android major version to ‘.2’ and focus on introducing Android-specific features that help you be more productive for Android app development.

Versioning system

Year of IntelliJ Version

IntelliJ major version

Studio major version

Jellyfish

2023

.3

.1

Koala

2024

.1

.1

Koala Feature Drop

2024

.1

.2


Leading with IDE platform updates

Going forward, each new “animal” of Android Studio will prioritize updates to the underlying IntelliJ platform. This focus on foundational elements lets developers benefit from usability, performance, and stability improvements to the underlying IntelliJ IDEA platform.

The base version of Android Studio Koala, numbered 2024.1.1 and launched to Canary in March, focuses on adopting updates from IntelliJ IDEA 2024.1. Some benefits of this platform update include:

    • Sticky lines in the editor to simplify working with large files and exploring new codebases
    • Overhauled terminal featuring both visual and functional enhancements
    • Basic IDE functionalities available for Java and Kotlin during indexing
    • Language injections in string templates
    • (Alpha) K2 Kotlin mode for enhanced Kotlin code analysis
    • Inline breakpoints for multiple statements
    • New inspections and quick-fixes
    • And much much more…

See What’s New in IntelliJ IDEA 2024.1 for more details on all the platform updates included in this release.

By focusing a whole release cycle on updating to the latest IntelliJ IDEA platform version, we’re able to get those changes into the Stable channel faster than with the previous release process — ensuring developers have access to the latest upstream features and improvements.

Android-specific functionality with Feature Drops

architecture of Feature Drops in Android Studio
Feature Drops are built on top of the IntelliJ platform updates, and follow soon after each new animal release.

Android Studio is a tailored environment for Android developers. You will continue to receive new and updated features specifically designed for Android development. These will arrive through Feature Drops that share the same animal codename as the base release, and will follow soon after the base animal release hits the Stable channel. Our first such release is Android Studio Koala Feature Drop, and numbered 2024.1.2.

When the Android Studio Koala Feature Drop is available, you can benefit from these new features:

    • A new sign-in flow that makes onboarding with multiple Google services, such as Firebase and Gemini in Android Studio, much easier
    • Device UI Setting Shortcuts in the Running Device Window to quickly test your app against different device UI settings
    • A new Gemini API template to help build Generative AI into your app
    • And more

Feature Drops will leverage the stabilized IDE platform from the previous Android Studio update and focus on new features geared towards Android development. By doing so, we hope to bring these features to the stable channel faster and with higher quality. To learn about even more new features coming to Koala Feature Drop, make sure to tune in to Google I/O 2024.

To sum it up: 2X more frequent updates

timeline of the expected release schedule in the Android Studio Stable channel
Expected release schedule in the Android Studio Stable channel.

Our primary goal with these changes is to ensure that important updates to the IntelliJ IDEA platform reach the Android Studio Stable channel more frequently, and new Android-specific features ship with higher quality and polish. Expect the first animal release to introduce a number of updates from the latest IntelliJ IDEA platform, with a Feature Drop update to follow soon after with more Android-specific features and tools.

By separating IDE platform updates from Feature Drops, we can deliver both types of enhancements in a more streamlined manner, resulting in much more frequent updates to the stable channel that are each focused on improving your productivity.

Similarly, versions of the Android Gradle plugin will also see updates to the stable channel more frequently. Each new animal version and Feature Drop of Android Studio will be accompanied by a new version of the Android Gradle plugin. For example, Android Studio Koala was released alongside AGP 8.5 and Android Studio Koala Feature Drop will be released alongside AGP 8.6.

As always, if you want to be on the cutting edge, we encourage you to join the Canary channel by downloading and installing Android Studio Koala Feature Drop for early access to the latest and greatest. Also you can be part of our vibrant Android developer community on LinkedIn, Medium, YouTube, or X.

Get ready for Google I/O: Program lineup revealed

Posted by Timothy Jordan – Director, Developer Relations and Open Source

Developers, get ready! Google I/O is just around the corner, kicking off live from Mountain View with the Google keynote on Tuesday, May 14 at 10 am PT, followed by the Developer keynote at 1:30 pm PT.

But the learning doesn’t stop there. Mark your calendars for May 16 at 8 am PT when we’ll be releasing over 150 technical deep dives, demos, codelabs, and more on-demand. If you register online, you can start building your 'My I/O' agenda today.

Here's a sneak peek at some of the exciting highlights from the I/O program preview:

Unlocking the power of AI: The Gemini era unlocks a new frontier for developers. We'll showcase the newest features in the Gemini API, Google AI Studio, and Gemma. Discover cutting-edge pre-trained models from Kaggle, and delve into Google's open-source libraries like Keras and JAX.

Android: A developer's playground: Get the latest updates on everything Android! We'll cover groundbreaking advancements in generative AI, the highly anticipated Android 15, innovative form factors, and the latest tools and libraries in the Jetpack and Compose ecosystem. Plus, discover how to optimize performance and streamline your development workflow.

Building beautiful and functional web experiences: We’ll cover Baseline updates, a revolutionary tool that empowers developers with a clear understanding of web features and API interoperability. With Baseline, you'll have access to real-time information on popular developer resource sites like MDN, Can I Use, and web.dev.

The future of ChromeOS: Get a glimpse into the exciting future of ChromeOS. We'll discuss the developer-centric investments we're making in distribution, app capabilities, and operating system integrations. Discover how our partners are shaping the future of Chromebooks and delivering world-class user experiences.

This is just a taste of what's in store at Google I/O. Stay tuned for more updates, and get ready to be a part of the future.

Don't forget to mark your calendars and register for Google I/O today!

Evolving Health on Android: Migrating from Google Fit APIs to Android Health

Posted by Chris Wilk – Senior Product Manager, Android Health

At Google, we're committed to empowering developers to create innovative health and fitness experiences on Android. Over the past few years, we've been investing heavily in establishing the Android Health platform, making significant improvements to build a more unified, secure, and user-friendly health ecosystem. Our goal is to provide developers with a powerful, integrated health platform that reduces fragmentation and streamlines the development process.

What is changing

As a result of these advancements, we're excited to announce that Google Fit developer services will be transitioning to become a core part of the Android Health platform. This change allows us to better serve developers and users, providing a seamless experience across the platform.

As part of this transition, Google Fit APIs, including the REST API, will remain available until June 30, 2025, giving developers ample time to migrate to Android Health. Starting today, new sign-ups for the Google Fit APIs will no longer be accepted as we focus on enhancing the Android Health platform.

What this means for developers

Developers Using Google Fit APIs for Android

If you are a developer using Google Fit APIs for Android, we recommend migrating to Android Health products now to ensure uninterrupted service for your users. Android Health APIs offer several advantages over the Google Fit APIs for Android, including:

    1. Recording steps, distance, and calories: In the near future, Android Health will provide the Recording API on mobile, which doesn’t require a Google user account or the need for you to request access to API scopes. And it is more battery-efficient than using Android SensorManager (ASM). The Recording API will launch with steps, and soon support distance and calories.

    2. Accessing recorded data: The Recording API on mobile will enable developers to access up to 10 days of recorded data.

    3. Storing and sharing data between apps: By integrating with Health Connect, your Android app can access data from a growing ecosystem of apps with just one connection. Plus, data is stored on-device, ensuring the user is in full control of their data.

To help you get started with the migration process, we've created a comprehensive migration guide. This guide will walk you through the steps needed to transition your app from Google Fit APIs to Android Health products, primarily Health Connect, to ensure a smooth experience for both you and your users.

Developers using Google Fit REST APIs

Our Android Health API offerings have moved to an on-device model, so there will not be an alternative to the Fit REST API. Where possible, we encourage Fit REST API users to migrate to Android Health APIs.

In addition to Fitbit which supports Health Connect today, partners like Withings, Signos, Oura, Peloton, and Lifesum are already building innovative experiences with Android Health products. As more developers embrace this powerful set of APIs, we anticipate a thriving ecosystem of connected health and fitness apps that empower users to take control of their wellbeing.

We're committed to supporting you throughout this transition and can't wait to see the innovative solutions you'll create. If you encounter issues, have proposals for features you would like to see, or have any feedback, please provide them here.


We will share more details about what’s next for Android Health at Google I/O on May 14, 2024. Stay tuned for updates and announcements during the event.

Gemini in Android Studio and more: Android Studio Jellyfish is Stable!

Posted by Paris Hsu – Product Manager, Android Studio

Android Studio Jellyfish (2023.3.1) is making waves with its official stable release! 🪼🌊 Dive into cutting-edge AI features like Gemini in Android Studio, seamless Google services integrations like Android Device Streaming, and much more. All designed to supercharge your Android development to build next-generation, high-quality apps. Surf below to learn more about all the updates, product quality improvements, and new features across your key flows in Android Studio Jellyfish, and download the latest stable version today to try them out!

Develop

Gemini in Android Studio: stable, and now available in 200+ countries!

Today, Gemini in Android Studio is available in over 200+ countries and territories, including a new set of countries in Europe. Thanks to all of the valuable feedback you’ve provided us over the last year, we’re excited to bring Gemini in Android Studio (formerly Studio Bot) into this stable release of Android Studio, as your AI-powered development companion in Android Studio, ready to level up your productivity. Ask your Android development questions and get help instantly: whether it’s to generate code, find resources, or explain best practices, Gemini in Android Studio is here to save you valuable time. Plus, it integrates seamlessly with your workflow:

    • Chat: Get code samples and questions answered
    • AI code completion: Intelligent suggestions as you type
    • Error analysis: Understand Logcat and Build errors with ease
    • Smart actions: Streamline tasks with powerful shortcuts

Onboard and then opt-in with the built-in AI privacy controls, and learn more about how the current capabilities of Gemini in Android Studio can accelerate your development workflow.

Modular login permissions

To provide you with more precise control over the permissions you grant for specific features, the new sign-in flow lets you select only the Google Service integrations you want to enable. This means you decide exactly which features, like Gemini for Android Studio, App Quality Insights, and Android Device Streaming, are able to access the required Google services using your Google account.

Manage login settings in Android Studio
Manage login settings in Android Studio
Switch accounts in Android Studio
Switch accounts in Android Studio

Debug

Android Device Streaming, powered by Firebase

Android Device Streaming, powered by Firebase, lets you securely connect to remote physical Android devices hosted in Google's secure data centers. It’s a fast and easy way to test your app against physical units of some of the latest Android devices, including the Google Pixel 8 and 8 Pro, Pixel Fold, select Samsung devices, and more.

Device Streaming in Android Studio, running your app on a remote Pixel Fold
Device Streaming in Android Studio, running your app on a remote Pixel Fold

After connecting to a device, you can deploy your app, view the display, interact with the device (including rotating or unfolding the device), and anything else you might do with a device using a direct ADB over SSL connection—all without leaving Android Studio. When you're done using the device, Google wipes all your data and factory resets the device before making it available to another developer.

Android Device Streaming is currently available as a no-cost trial after you sign in to Android Studio with your Google account and select a Firebase project to use. If you don’t already have a Firebase project, it’s easy to create one.

AQI Crashlytics: Multi-events, keys, and logs

Dive deeper into App Quality Insights (AQI) crash reports with Android Studio Jellyfish! We've listened to your feedback and made analyzing crashes easier than ever:

    • Iterate through events: Now explore multiple events within a Crashlytics report in reverse chronological order, revealing patterns for faster debugging.
    • Explore custom data: View custom keys/values and logs for each Crashlytics crash report (find them in the Keys and Logs tabs after selecting a report).
    • Analyze ANRs (Application Not Responding): Access and investigate ANRs directly within both the Android Vitals and Crashlytics tabs.
App Quality Insights in Android Studio
Device Streaming in Android Studio, running your app on a remote Pixel Fold

Embedded Layout Inspector

In Android Studio Jellyfish, Layout Inspector is now embedded by default in the Running Devices tool window. This integration saves screen real-estate, centralizes your workflow in a single tool window, and delivers significant performance gains - with a 50% improvement in rendering speeds. You can effortlessly toggle between deeply inspecting and interacting with your app, and use snapshots for 3D visualizations of your UI. Discover the full range of features here.

Embedded Layout Inspector with Pixel Fold Emulator
Embedded Layout Inspector with Pixel Fold Emulator

Optimize

App Links Assistant: Web associations file support

App Links Assistant now supports web association file validation. This new feature streamlines deep linking by helping you identify and fix errors in your deep links setup (both in your Android manifest file and the corresponding Digital Asset Links JSON file). Ensure a seamless user experience by validating that your JSON file is correctly formatted for upload to your domain.

App Links Assistant: Web associations file support
App Links Assistant: Web associations file support

Baseline Profile installation

Baseline Profiles improve code execution speed by about 30% from the first launch by avoiding interpretation and just-in-time (JIT) compilation steps for included code paths. While Android Studio has included Baseline Profiles in builds for years now, these were only actually compiled by the OS in production (often by Play Store).

Android Studio Jellyfish now compiles these Baseline Profiles when any non-debuggable app build is installed on a device. This applies to release builds, as well as when you're profiling with low-overhead.

This means — as long as you aren't using a debug variant of your app — the performance you see when installing from Studio / CLI now much more closely matches production by taking advantage of profiles from a Baseline Profile generator module and libraries like Compose.

Quality improvements

Beyond new features, we also continue to improve the overall quality and stability of Android Studio. In fact, over 900 bugs were addressed during the Jellyfish/AGP-8.4 cycle, and memory errors are down by 40%.

IntelliJ platform update

Android Studio Jellyfish (2023.3.1) includes the IntelliJ 2023.3 platform release, which has many new features such as comprehensive support for the latest Java 21 programing language features, an intuitive floating toolbar with editing actions, and a Run to Cursor inlay option in the debugger to speed up your workflow. Learn more.

Summary

To recap, Android Studio Jellyfish 🪼includes the following enhancements and features:

Develop

    • Gemini in Android Studio
    • Modular login permissions

Debug

    • Android Device Streaming
    • AQI Crashlytics: Multi-events, keys, and logs
    • Embedded Layout Inspector

Optimize

    • App Links Assistant: Web associations file support
    • Baseline Profile installation

Quality Improvements

    • 900+ bugs addressed
    • Memory errors down by 40%

IntelliJ Platform Update

    • Latest Java 21 feature support
    • Run to Cursor inlay option
    • More 2023.3 features

Getting Started

Ready for next-level Android development? Download Android Studio Jellyfish 🪼 and unlock cutting-edge features today! As always, your feedback is important to us – check known issues, report bugs, suggest improvements, and be part of our vibrant community on LinkedIn, Medium, YouTube, or X. Let's build the future of Android apps together!

Jetpack Compose compiler moving to the Kotlin repository

Posted by Ben Trengrove - Developer Relations Engineer, Nick Butcher - Product Manager for Jetpack Compose

We are excited to announce that with the upcoming release of Kotlin 2.0, the Jetpack Compose compiler will move to the Kotlin repository. This means that a matching Compose compiler will release alongside each release of Kotlin. You will no longer have to wait for a matching Compose compiler release before upgrading the Kotlin version in your Compose app. The Compose team at Google will continue to be responsible for developing the compiler and will work closely with JetBrains, our co-founders of the Kotlin Foundation. The version of the Compose compiler now always matches the Kotlin version. The compiler version is therefore jumping to 2.0.0.

To simplify the set up of Compose, we are also releasing a new Compose Compiler Gradle plugin which lets you configure the Compose compiler with a type safe API. The Compose Compiler Gradle plugin’s versioning matches Kotlin’s, and it is available from Kotlin 2.0.0.

To migrate to the new plugin, add the Compose Compiler Gradle plugin dependency to the plugins section of your Gradle version catalog:

[versions]
kotlin = "2.0.0"

[plugins]
org-jetbrains-kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }

// Add the Compose Compiler Gradle plugin, the version matches the Kotlin plugin
compose-compiler = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

In your project’s root level Gradle file, add the plugin:

plugins {
   // Existing plugins 
   alias(libs.plugins.compose.compiler) apply false
}

Then in modules that use Compose, apply the plugin:

plugins {
   // Existing plugins
   alias(libs.plugins.compose.compiler)
}

The kotlinCompilerExtensionVersion is no longer required to be configured in composeOptions and can be removed.

composeOptions {
   kotlinCompilerExtensionVersion = libs.versions.compose.compiler.get()
}

If required, you can now add a top level section to the same Gradle file to configure options for the Compose compiler.

android { ... }

composeCompiler {
   enableStrongSkippingMode = true
}

You might currently directly referencing the Compose compiler in your build setup, rather than using AGP to apply the compose compiler plugin. If that is the case, note that the maven artifacts will also change:

Old

New

androidx.compose.compiler:compiler

org.jetbrains.kotlin:kotlin-compose-compiler-plugin-embeddable

androidx.compose.compiler:compiler-hosted

org.jetbrains.kotlin:kotlin-compose-compiler-plugin


For an example of this migration, see this pull request.

For more information on migrating to the new Compose compiler artifact, including instructions for non-version catalog setups, see our updated documentation.

How to effectively A/B test power consumption for your Android app’s features

Posted by Mayank Jain - Product Manager, and Yasser Dbeis - Software Engineer; Android Studio

Android developers have been telling us they're looking for tools to help optimize power consumption for different devices on Android.

The new Power Profiler in Android Studio helps Android developers by showing power consumption happening on devices as the app is being used. Understanding power consumption across Android devices can help Android developers identify and fix power consumption issues in their apps. They can run A/B tests to compare the power consumption of different algorithms, features or even different versions of their app.

The new Power Profiler in Android Studio
The new Power Profiler in Android Studio

Apps which are optimized for lower power consumption lead to an improved battery and thermal performance of the device, which means an improved user experience on Android.

This power consumption data is made available through the On Device Power Monitor (ODPM) on Pixel 6+ devices, segmented by each sub-system called “Power Rails”. See Profileable power rails for a list of supported sub-systems.

The Power Profiler can help app developers detect problems in several areas:

    • Detecting unoptimized code that is using more power than necessary.
    • Finding background tasks that are causing unnecessary CPU usage.
    • Identifying wakelocks that are keeping the device awake when they are not needed.

Once a power consumption issue has been identified, the Power Profiler can be used when testing different hypotheses to understand why the app could be consuming excessive power. For example, if the issue is caused by background tasks, the developer can try to stop the tasks from running unnecessarily or for longer periods. And if the issue is caused by wakelocks, the developer can try to release the wakelocks when the resource is not in use or use them more judiciously. Then compare the power consumption before/after the change using the Power Profiler.

In this blog post, we showcase a technique which uses A/B testing to understand how your app’s power consumption characteristics might change with different versions of the same feature - and how you can effectively measure them.

A real-life example of how the Power Profiler can be used to improve the battery life of an app.

Let’s assume you have an app through which users can purchase their favorite movies.

Sample app to demonstrate A/B testing for measure power consumption
Sample app to demonstrate A/B testing for measure power consumption 
Video (c) copyright Blender Foundation | www.bigbuckbunny.org

As your app becomes popular and is used by more users, you realize that a high quality 4K video takes very long to load every time the app is started. Because of its large size, you want to understand its impact on power consumption on the device.

Originally, this video was in 4K quality in the best of intentions, so as to showcase the best possible movie highlights to your customers.

This makes you think…

    • Do you really need a 4K video banner on the home screen?
    • Does it make sense to load a 4K video over the network every time your app is run?
    • How will the power consumption characteristics of your app change if you replace the 4K video with something of lower quality (while still preserving the vivid look & feel of the video)?

This is a perfect scenario to perform an A/B test for power consumption

With an A/B test, you can test two slightly different variations of the video banner feature and choose the one with the better power consumption characteristics.

Scenario A : Run the app with 4K video banner on screen & measure power consumption

Scenario B : Run the app with lower resolution video banner on screen & measure power consumption

A/B Test setup

Let's take a moment and set up our Android Studio profiler to run this A/B test. We need to start the app and attach the CPU profiler to it and trigger a system trace (where the Power Profiler will be shown).

Step 1

Create a custom “Run configuration” by clicking the 3 dot menu > Edit

Custom run configuration
Custom run configuration

Step 2

Then select the “Profiling” tab and ensure that “Start this recording on startup” and CPU Activity > System Trace is selected. Then click “Apply”.

Edit configuration settings
Edit configuration settings

Now simply run the “Profile app startup profiling with low overhead” whenever you want to run this app from start and attach the CPU profiler to it.

Note on precision

The following example scenarios use the entire app startup for estimating the power consumption for this blog’s purpose. However you can use more advanced techniques to have even higher precision in getting power readings. Some techniques to try are:

    • Isolate and measure power consumption for video playback only after a tap event on the video player
    • Use the trace markers API to mark the start and stop time for power measurement timeline - and then only measure power consumption within that marked window

Scenario A

In this scenario, we run the app with 4K video playing and measure power consumption for the first 30 seconds. We can optionally also run the scenario A multiple times and average out the readings. Once the System trace is shown in Android Studio, select the 0-30 second time range from the timeline selection panel and record as a screenshot for comparing against scenario B

Power consumption in scenario A - playing a 4k video
Power consumption in scenario A - playing a 4k video

As you can see, the average power consumed by WLAN, CPU cores & Memory combined is about 1,352 mW (milliwatts)

Now let's compare and contrast how this power consumption changes in Scenario B

Scenario B

In this scenario, we run the app with low quality video playing and measure power consumption for the first 30 seconds. As before, we can also optionally run scenario B multiple times and average out the power consumption readings. Again, once the System trace is shown in Android Studio, select the 0-30 second time range from the timeline selection panel.

Power consumption in scenario B - playing a lower quality video
Power consumption in scenario B - playing a lower quality video

The total power consumed by WLAN, CPU Little, CPU Big and CPU Mid & Memory is about 741 mW (milliwatts)

Conclusion

All else being equal, Scenario B (with lower quality video) consumed 741 mW power as compared to Scenario A (with 4K video) which required 1,352 mW power.

Scenario B (lower quality video) took 45% less power than Scenario A (4K) - while the lower quality video provides little to no visual difference in perceived quality of the app’s screen.

As a result of this A/B test for power consumption, you conclude that replacing the 4K video with a lower quality video on our app’s home screen not only reduces power consumption by 45%, also reduces the required network bandwidth and can potentially also improve the thermal performance of the devices.

If your app’s business logic still requires the 4K video to be shown on the app’s screen, you can explore strategies like:

    • Caching the 4K video across subsequent runs of the app.
    • Loading video on a user tap.
    • Loading an image initially and only load the video after the screen has fully rendered (delayed loading).

The overall power consumption numbers presented in the above A/B test scenario might seem small, but it shows the techniques that app developers can use to effectively A/B test power consumption for their app’s features using the Power Profiler in Android Studio.

Next Steps

The new Power Profiler is available in Android Studio Hedgehog onwards. To know more, please head over to the official documentation.

The First Beta of Android 15

Posted by Dave Burke, VP of Engineering

Android 14 logo


Today we're releasing the first beta of Android 15. With the progress we've made refining the features and stability of Android 15, it's time to open the experience up to both developers and early adopters, so you can now enroll any supported Pixel device here to get this and future Android 15 Beta and feature drop Beta updates over-the-air.

Android 15 continues our work to build a platform that helps improve your productivity, give users a premium app experience, protect user privacy and security, and make your app accessible to as many people as possible — all in a vibrant and diverse ecosystem of devices, silicon partners, and carriers.

Android delivers enhancements and new features year-round, and your feedback on the Android beta program plays a key role in helping Android continuously improve. The Android 15 developer site has lots more information about the beta, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.

We’ll have lots more to share as we move through the release cycle, and be sure to tune into Google I/O where you can dive deeper into topics that interest you with over 100 sessions, workshops, codelabs, and demos.

Edge-to-edge

Apps targeting Android 15 are displayed edge-to-edge by default on Android 15 devices. This means that apps no longer need to explicitly call Window.setDecorFitsSystemWindows(false) or enableEdgeToEdge() to show their content behind the system bars, although we recommend continuing to call enableEdgeToEdge() to get the edge-to-edge experience on earlier Android releases.

To assist your app with going edge-to-edge, many of the Material 3 composables handle insets for you, based on how the composables are placed in your app according to the Material specifications.

a side-by-side comparison of App targets SDK 34 (left) and App targets SDK 35 (right) demonstrating edge-to-edge on an Android 15 device
On the left: App targets SDK 34 (Android 14) and is not edge-to-edge on an Android 15 device. On the right: App targets SDK 35 (Android 15) and is edge-to-edge on an Android 15 device. Note the Material 3 TopAppBar is automatically protecting the status bar, which would otherwise be transparent by default.

The system bars are transparent or translucent and content will draw behind by default. Refer to "Handle overlaps using insets" (Views) or Window insets in Compose to see how to prevent important touch targets from being hidden by the system bars.

Smoother NFC experiences - part 2

Android 15 is working to make the tap to pay experience more seamless and reliable while continuing to support Android's robust NFC app ecosystem. In addition to the observe mode changes from Android 15 developer preview 2, apps can now register a fingerprint on supported devices so they can be notified of polling loop activity, which allows for smooth operation with multiple NFC-aware applications.

Inter-character justification

Starting with Android 15, text can be justified utilizing letter spacing by using JUSTIFICATION_MODE_INTER_CHARACTER. Inter-word justification was first introduced in Android O, but inter-character solves for languages that use the white space for segmentation, e.g. Chinese, Japanese, etc.

JUSTIFICATION_MODE_NONE
image shows how japanese kanji (top) and english alphabet characters (bottom) appear with JUSTIFICATION_MODE_NONE
JUSTIFICATION_MODE_INTER_WORD
image shows how japanese kanji (top) and english alphabet characters (bottom) appear with JUSTIFICATION_MODE_INTER_WORD
JUSTIFICATION_MODE_INTER_CHARACTER
image shows how japanese kanji (top) and english alphabet characters (bottom) appear with JUSTIFICATION_MODE_INTER_WORD

App archiving

Android and Google Play announced support for app archiving last year, allowing users to free up space by partially removing infrequently used apps from the device that were published using Android App Bundle on Google Play. Android 15 now includes OS level support for app archiving and unarchiving, making it easier for all app stores to implement it.

Apps with the REQUEST_DELETE_PACKAGES permission can call the PackageInstaller requestArchive method to request archiving a currently installed app package, which removes the APK and any cached files, but persists user data. Archived apps are returned as displayable apps through the LauncherApps APIs; users will see a UI treatment to highlight that those apps are archived. If a user taps on an archived app, the responsible installer will get a request to unarchive it, and the restoration process can be monitored by the ACTION_PACKAGE_ADDED broadcast.

App-managed profiling

Android 15 includes the all new ProfilingManager class, which allows you to collect profiling information from within your app. We're planning to wrap this with an Android Jetpack API that will simplify construction of profiling requests, but the core API will allow the collection of heap dumps, heap profiles, stack sampling, and more. It provides a callback to your app with a supplied tag to identify the output file, which is delivered to your app's files directory. The API does rate limiting to minimize the performance impact.

Better Braille

In Android 15, we've made it possible for TalkBack to support Braille displays that are using the HID standard over both USB and secure Bluetooth.

This standard, much like the one used by mice and keyboards, will help Android support a wider range of Braille displays over time.

Key management for end-to-end encryption

We are introducing the E2eeContactKeysManager in Android 15, which facilitates end-to-end encryption (E2EE) in your Android apps by providing an OS-level API for the storage of cryptographic public keys.

The E2eeContactKeysManager is designed to integrate with the platform contacts app to give users a centralized way to manage and verify their contacts' public keys.

Secured background activity launches

Android 15 brings additional changes to prevent malicious background apps from bringing other apps to the foreground, elevating their privileges, and abusing user interaction, aiming to protect users from malicious apps and give them more control over their devices. Background activity launches have been restricted since Android 10.

App compatibility

With Android 15 now in beta, we're opening up access to early-adopter users as well as developers, so if you haven't yet tested your app for compatibility with Android 15, now is the time to do it. In the weeks ahead, you can expect more users to try your app on Android 15 and raise issues they find.

To test for compatibility, install your published app on a device or emulator running Android 15 beta and work through all of your app's flows. Review the behavior changes to focus your testing. After you've resolved any issues, publish an update as soon as possible.

To give you more time to plan for app compatibility work, we’re letting you know our Platform Stability milestone well in advance.

Android 15 release timeline

At this milestone, we’ll deliver final SDK/NDK APIs and also final internal APIs and app-facing system behaviors. We’re expecting to reach Platform Stability in June 2024, and from that time you’ll have several months before the official release to do your final testing. The release timeline details are here.

Get started with Android 15

Today's beta release has everything you need to try the Android 15 features, test your apps, and give us feedback. Now that we've entered the beta phase, you can enroll any supported Pixel device here to get this and future Android Beta updates over-the-air. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you're already in the Android 14 QPR beta program on a supported device, or have installed the developer preview, you'll automatically get updated to Android 15 Beta 1.

For the best development experience with Android 15, we recommend that you use the latest version of Android Studio Jellyfish (or more recent Jellyfish+ versions). Once you’re set up, here are some of the things you should do:

    • Try the new features and APIs - your feedback is critical during the early part of the developer preview and beta program. Report issues in our tracker on the feedback page.
    • Test your current app for compatibility - learn whether your app is affected by changes in Android 15; install your app onto a device or emulator running Android 15 and extensively test it.

We’ll update the beta system images and SDK regularly throughout the Android 15 release cycle. Read more here.

For complete information, visit the Android 15 developer site.


Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Google Drive cut code and development time in half with Jetpack Compose and new architecture

Posted by Nick Butcher – Product Manager for Jetpack Compose, and Florina Muntenescu – Developer Relations Engineer

As one of the world’s most popular cloud-based storage services, Google Drive lets people do more than just store their files online. With Drive, users can synchronize, share, search, edit, and even pin specified files and content for safe and secure offline use.

Recently, Drive’s developers revamped the application’s home screen to provide a more seamless experience across devices, matching updates made to Google Drive’s web version. However, the app’s previous architecture and codebase would’ve prevented the team from completing the updates in a timely manner.

Instead of struggling with the app’s previous tech stack to implement the update, the Drive team rebuilt the home page from the ground up using Android’s recommended architecture and Jetpack Compose, Android’s modern declarative toolkit for creating native UI.

Compose, combined with architecture improvements, cut our development time nearly in half.” — Dale Hawkins, Senior software engineer and tech lead at Google Drive

Experimenting with Kotlin and Compose

The Drive team experimented with Kotlin — which the Compose toolkit is built with — for several months before planning the app’s home screen rebuild. Drive’s developers liked Kotlin’s improved syntax and null enforcement, making it easier to produce code.

“We had been using RxJava, but started looking into replacing that with coroutines,” said Dale Hawkins, the features team lead for Google Drive. “This led to a more natural alignment between coroutines and Jetpack Compose. After a deep dive into Compose, we came away with a clear understanding of how Compose has numerous benefits over the Views-based approach.”

Following the Kotlin exploration, Dale experimented with Jetpack Compose. “I was pleased with how easy it was to build the UI using Compose. So I continued the experiment after that week,” said Dale. “I eventually rewrote the feature using Compose.”

Using Compose

Shortly after experimenting with Jetpack Compose, the Drive team decided to use it to completely rebuild the app’s home screen UI.

“We wanted to make some major changes to match the ones being done for the web version, but that project had a several-month head start. We wanted to release the Android version shortly after the web changes went live to ensure our users have a seamless Google Drive experience across devices,” said Dale.

The Drive team's experimentation and testing with Jetpack Compose showed that the new toolkit was powerful and reliable and that it would enable them to move faster. With this in mind, the Drive team decided to step away from their old codebase and embrace Jetpack Compose for the app’s home screen update. Not only would it be quicker and easier, but it would also better prepare the team to easily make future UI changes.

Using Android’s guidance for architecture

Before going all-in with Jetpack Compose, Drive developers wanted to restructure the application by implementing a completely new app architecture. Drive developers followed Android’s official architecture guidance to apply structural changes, paving the way for the new Kotlin codebase.

“The recommended architecture reinforces good separation between layers,” said Quintin Knudsen, an Android engineer for Google Drive. “We work in a highly dynamic environment and need to be able to adjust to any app changes. Using well-defined and independent layers helps isolate any changes or UI requirements. The recommendations from Android offered sound ways to structure the layers.” With a clear separation between the app’s data and UI layers, developers could work in parallel to significantly speed up testing and development.

Drive developers also relied on Mappers and UseCases when creating the new architecture. These patterns allowed them to create flexible code that is easier to manage. They also exposed flows from their ViewModels to make the UI respond immediately to any data changes, making it much simpler to implement and understand UI updates.

Less code, faster development

With the app’s newly improved architecture and Jetpack Compose, the Drive team was able to develop the app’s new home screen in less than half the time that they expected. They also implemented the new code and finished quality assurance testing nearly seven weeks ahead of schedule.

“Thanks to Compose, we had the groundwork done within a couple of weeks. We delivered a great implementation over a month ahead of schedule, and it’s been praised by product, UX, and even other engineering teams,” said Dale.

Despite having fewer features, the original home screen required over 12,000 lines of code. The new Compose-based home screen has many new features and only required 5,100 lines of code—a 57% reduction. Having less code makes it much easier for developers to maintain the app and implement any updates.

Testing the new UI in Jetpack Compose also required significantly less code. Before Compose, Drive developers used roughly 9,000 lines of code to test about 62% of the UI. With Compose, it took only 2,200 lines to test over 80% of the new UI.

The original home screen required over 12,000 lines of code. The Compose-based home screen only required 5,100 lines of code. That’s a 57% reduction.” — Dale Hawkins, Senior software engineer and tech lead at Google Drive

Looking forward

A new and improved app architecture paired with Jetpack Compose allowed Drive developers to rebuild the app’s home screen UI faster and easier than they could’ve imagined. The Drive team plans to expand its use of Compose within the application for things like supporting large dynamic displays and text resizing.

“As we work on new projects, we’re taking the opportunity to update older UI code to make use of our new architecture and Compose. The new code will be objectively better and features will be easier to write, test, and maintain,” said Dale.

Get started

Improve app architecture using Android’s official architecture guidance and optimize your UI development with Jetpack Compose.