Category Archives: Android Developers Blog

An Open Handset Alliance Project

Kotlin DSL is Now the Default for New Gradle Builds

Posted by James Ward, Product Manager, Kotlin and Boris Farber, Developer Relations Engineer

Android has been Kotlin-first for four years and many Android developers have made the switch resulting in higher productivity and more stable apps. However the default language to define builds has been Groovy (build.gradle), even though a Kotlin (build.gradle.kts) option has existed in Gradle for a number of years.

Today we're excited to announce that we're switching the default language for build scripts to Kotlin! This means that Kotlin is the single default language used for all project code, including UI with Jetpack Compose, and now build scripts! We've been working with the Gradle and JetBrains teams on this improvement, and you can read more in their related announcements: Gradle Blog; JetBrains Blog.

This doesn’t affect existing projects using Groovy, as those will continue working with no plans for deprecation. But if you are creating new projects or modules starting from Android Studio Giraffe, you now get the Kotlin DSL by default. The updated project templates are an easy way to get started with the new Kotlin DSL build scripts. To migrate existing builds, check out the Kotlin DSL migration guide.

While the Kotlin DSL is the default for new projects, large, existing Groovy DSL based projects should wait on migrating while Gradle, JetBrains, and Google work on improving build performance further. This work is ongoing and we will share updates as we make progress. Specifically, script compilation performance is slower than with the Groovy DSL. However, unlike with the Groovy DSL, the Kotlin DSL script compilation results are stored in Gradle local and remote caches so that subsequent builds do not need recompilation.

Having a single language for all code in a project isn't the only benefit to this change, so let's look at some other great things about using the Kotlin DSL for Gradle builds.

  • Kotlin is statically typed so you get quick and accurate code hints while editing Kotlin DSL build scripts:
  • Syntax errors are more accurate, and they’re displayed while editing Kotlin DSL build scripts, instead of when trying to sync the project:
  • Get type and method documentation by pressing Control+Q (Command+B on macOS).If you need more details you can go to the underlying source code by pressing Control+Click (Command+Click):
  • You can mix Groovy DSL build scripts and Kotlin DSL build scripts in one project and migrate incrementally module by module. This enables new modules to use the Kotlin DSL while keeping existing modules on Groovy.

An associated change we are also making to the New Project templates is an experimental option to use Gradle Version Catalogs with Kotlin DSL build scripts.

Version Catalogs give you a centralized, scalable way of defining your project’s dependencies. While using Version Catalogs is optional, they pair great with the Kotlin DSL by providing more type safety in your build definitions.

To learn about migrating to Version Catalogs, check out the migration guide.

The new Kotlin DSL default change is available now in Android Studio Giraffe previews. Please try it and let us know how it goes!

Bring your IOT apps to cars

Posted by Brad Hinkel, Product Manager, Android Automotive Developer Platform

To deliver seamless experiences in cars, we’re now enabling developers to bring their internet of things (IOT) apps to cars. This will allow users to easily manage IOT systems like home security and doors directly from their car. You can now launch IOT apps to production for both Android Auto and Android Automotive OS.

IOT apps

You can start building your IOT apps for cars using driving-optimized templates from the Android for Cars App Library.

Android for Cars App Library Grid Template for IOT apps

The Automotive OS emulator for Android Automotive OS and the DHU for Android Auto allow you to easily test apps for this category. To start building your app for the car, check out our updated developer documentation, car quality guidelines, and design guidelines. For additional instructions on building IOT apps, visit here.

Drivers of cars using Android Auto can now download IOT apps developed with the Android for Cars App Library immediately from Google Play. Additionally you can join the Google Group for new beta apps and opt-in to new app's beta on the Google Play store, with your Gmail account.

Samsung SmartThings running on Android Auto

Experience for yourself how your app will look within the different systems, by accessing the OEM emulator system images downloadable in Android Studio.

To publish your app today, follow the below steps.

  1. Design your app’s experience using our developer guide and app quality guidelines.
  2. Develop using the latest release of the car app library so you can get user feedback from now.
  3. Test using the desktop head unit.
  4. Publish your app to Close or Open testing to the Google Play Store to get pre-production feedback from users.
  5. Ship your final app to cars.

We’re excited to see what you’ve built and take it for a spin!

If you’re interested in joining our Early Access Program in the future, please fill out this interest form. You can get started with the Android for Cars App Library today by visiting g.co/androidforcars.

Android 14 Beta 1

Posted by Dave Burke, VP of Engineering

Illustration of badge style Android 14 logo

Today we're releasing the first Beta of Android 14, building around our core themes of privacy, security, performance, developer productivity, and user customization while continuing to improve the large-screen device experience on tablets, foldables, and more. We've been making steady progress refining the features and stability of Android 14, and it's time to open the experience up to both developers and early-adopters.

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 14 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.


Working across form factors

Android 14 builds on the work done in past releases to support tablets and foldable form factors, and we've been building tools and resources to help polish your app experience, including design inspiration and development guides.


Smarter System UI

In the Android operating system, features are implemented by two separate yet equally important packages: the framework, which provides services, and the System UI, which gives the user control of those services. Each Android release brings new refinements to the system UI, and here are some that you might notice in Beta 1.


New back arrow

Image showing the back arrow indicating gesture navigation on a mobile device

The gesture navigation experience includes a more prominent back arrow while interacting with your app to help improve back gesture understanding and usefulness. The back arrow also compliments the user's wallpaper or device theme.



A superior system sharesheet

Screen image of custom sharesheet with direct share targets


In Android 14, apps can now add custom actions to system sharesheets they invoke. Create your custom ChooserAction using ChooserAction.Builder and specify a list of your ChooserActions as the Intent.EXTRA_CHOOSER_CUSTOM_ACTIONS of the Intent created with Intent.createChooser.

In addition, the system now uses more app signals to determine the ranking of the direct share targets. You provide the signal by calling pushDynamicShortcut to report shortcut usage with the corresponding capability bindings.






More graphics capabilities

Android 14 adds new graphics features that you can use to make your app really stand out.


Paths are now queryable and interpolatable

Android's Path API is a powerful and flexible mechanism for creating and rendering vector graphics. Starting in Android 14, you can query paths to find out what's inside of them. The API updates include functionality to interpolate between paths whose structures match exactly, enabling morphing effects, and an AndroidX library provides backwards compatibility back to API 21. More details here.


Personalization

 Per-app language preferences

Android 14 enhances per-app language preferences, allowing for dynamic customization of the set of languages displayed in the Android Settings per-app language list, and giving IMEs a way to know the UI language of the current app. Starting with Android Studio Giraffe Canary 7 and AGP 8.1.0-alpha07, you can configure your app to support per-app language preferences automatically. Based on your project resources, the Android Gradle plugin generates the LocaleConfig file and adds a reference to it in the generated manifest file, so you no longer have to create or update the file manually when your language support changes. See Automatic per-app language support for more information and leave feedback.


Privacy

 Limiting visibility to disability-focused accessibility services

Android 14 introduces the accessibilityDataSensitive attribute to allow apps to limit visibility of specified views only to accessibility services that claim to help users with disabilities. Play Protect ensures apps downloaded from the Play Store are truthful about these claims. TalkBack and other services that claim to help users with disabilities will not be affected by this attribute.

Apps can consider using accessibilityDataSensitive to:

  • Protect user data (such as personal details or plaintext passwords) 
  • Prevent critical actions from being executed unintentionally (such as transfering money or checking out in a shopping app)
    •  

App compatibility

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

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

Image of Android 14 preview and release timeline indicating we are on target with Beta release in April

It’s also a good time to start getting ready for your app to target Android 14, by testing with the app compatibility changes toggles in Developer Options.

Partial screenshot of App Compatibility Changes in Developer Options
App compatibility toggles in Developer Options.

Get started with Android 14

Today's Beta release has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, the easiest way to get started is using the Android Emulator in a tablet or foldable configuration in the latest preview of the Android Studio SDK Manager. Now that we've entered the beta phase, you can enroll any supported Pixel device here to get this and future Android 14 Beta and feature drop 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.

For the best development experience with Android 14, we recommend that you use the latest preview of Android Studio Giraffe (or more recent Giraffe+ 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 as we finalize the APIs. Report issues in our tracker on the feedback page. 
  • Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14. Install your app onto a device or emulator running Android 14 and extensively test it. 
  • Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview and beta system images and SDK regularly throughout the Android 14 release cycle.

If you are already enrolled in the Android 13 QPR Beta program and your device is supported, Android 14 Beta 1 will be made available to you without taking any additional action.

For complete information on how to get the Beta, visit the Android 14 developer site.

What’s new in multiplatform Jetpack libraries

Posted by Márton Braun, Developer Relations Engineer

To support developers who are already using Kotlin Multiplatform for sharing business logic across mobile platforms, we previously released experimental multiplatform previews of the Collections and DataStore Jetpack libraries, and we've been receiving great feedback from the community.

The multiplatform Collections and DataStore libraries are now moving from experimental developer previews to alpha releases, and will follow the normal release cycle of Jetpack libraries. Annotations, a core Jetpack library, is now also available for multiplatform.

Please note that Kotlin Multiplatform is still in beta, therefore the non-Android targets of these libraries don’t have Jetpack’s usual stability guarantees.

The alpha releases are available from Google’s Maven repository. You can try them by adding the following dependencies to your Kotlin Multiplatform project:

val commonMain by getting { dependencies { implementation("androidx.annotation:annotation:1.7.0-alpha02") implementation("androidx.collection:collection:1.3.0-alpha04") // Lower-level APIs with support for custom serialization implementation("androidx.datastore:datastore-core-okio:1.1.0-alpha03") // Higher-level APIs for storing values of basic types implementation("androidx.datastore:datastore-preferences-core:1.1.0-alpha03") } }

The multiplatform DiceRoller sample app has also been updated to use the new alpha version of DataStore.

To provide feedback on these multiplatform releases, create a bug on our issue tracker, or join the conversation in the Kotlinlang #multiplatform channel.

Reduce uninstalls for your app with auto-archive

Posted by Chang Liu and Lidia Gaymond, Product Managers, Google Play

Did you know that one of the main reasons users uninstall apps is to free up space? Today, whenever users try to install a new app on a nearly-full device, they see a dialog that allows them to manually uninstall the app to make room. However, sometimes uninstalling a whole app, including all of the user’s app data just isn’t necessary.

To reduce unnecessary uninstalls and help users successfully install new apps, we are introducing a new feature: auto-archive. Once a user opts in, auto-archive can help them automatically free up to nearly 60% of an app’s storage space, without removing the app presence or users’ data from the device.

What is auto-archive?
image of a phone screen illustrating the archiving experience
Archived apps are visually indicated with cloud icons and remain on the user's device.

Auto-archive is a new feature that allows users to free up space on their device without the need to completely uninstall an app. Once the user opts in, infrequently used apps will be partly removed from the device to save space, whilst the app icon and the user’s personal app data will be preserved. When the user wants to start using the app again, they can simply tap to re-download it and pick up where they left off (as long as the app is still available on Google Play).


Eligibility of auto-archive

Auto-archive is only available for developers using the App Bundle to publish their apps. If your app supports archiving, users will be less likely to see it surfaced amongst uninstall suggestions.

How it works

Users can opt into auto-archive in a few steps.

  1. The user tries to install a new app when the device is out of storage.
  2. A pop-up window appears asking if the user wants to enable auto-archive.
  3. If the user opts in, unused apps on the user's device will be auto-archived to free up enough space for a new app request.

Auto-archive is an easy way for users to manage their device storage, and a great way for developers to lower the likelihood of their apps being uninstalled.


Clue’s development speed improves 3X after rebuilding the app with Jetpack Compose

Posted by the Android team

Clue is a freemium menstrual health application founded in 2012 and was among the earliest developers in femtech. The app helps women and people who menstruate track their cycles and serves 11 million monthly active users in over 190 countries. Additional features, including tools for tracking prenatal and postpartum health, are available through the app’s subscription tier, Clue Plus.

Having access to streamlined and easily digestible menstrual health data can be an invaluable resource for people who menstruate, and Clue has supported these insights for Android users for over a decade. As with any codebase, however, the Clue app inherited technical debt. This limited the team’s ability to push changes and features quickly, scale developer efforts, and provide a modern UI to its users.

Clue previously relied heavily on custom views that made extending the existing codebase difficult and required time-consuming testing methods that slowed the development process. Clue’s codebase had additionally amassed UI inconsistencies from hard-coded theme values such as colors and sizes, and in 2022 Clue’s engineers recognized that they needed a more efficient and flexible solution. They ultimately landed on migrating to Jetpack Compose, Android’s modern toolkit for building native UI.

“We decided that a complete rewrite of the application, with a specific emphasis on the UI layer, would be the best course of action,” said Moctezuma Rojas, an Android developer at Clue. “This decision was based on the fact that it would enable us to have a more efficient and faster development cycle, quickly implement features that would have taken much longer to develop using views, and make our code more testable.”

Building a faster and more efficient codebase with Compose

The Clue team saw immediate benefits by rewriting its app with Compose. For one, a faster, more efficient testing and development cycle significantly reduced the time and effort necessary to improve the codebase while reducing bugs and errors. Compose also enabled Clue’s engineers to implement features faster than they could with Views.

Migrating the app to Compose resulted in improved testability for screens, faster development from ideation to release, and better standardization processes that aligned with the best practices recommended by Android developer resources. Compose also helped the Clue team double—and in some cases, triple—their development speed when compared to the old codebase.

“With the traditional view system, adding new features, visual representations, or user interactions was difficult due to the need for custom view creation and maintenance. However, by utilizing Jetpack Compose, we've been able to effortlessly develop and expand the Cycle View feature without any limitations in adding elements,” said Moctezuma.

Photo of Moctezuma Rojas, Android developer at Clue,smiling while snuggling a cat, with quote text which reads, '...By utilizing Jetpack Compose, we've been able to effortlessly develop and expand the Cycle View feature without any limitations in adding elements.'

Compose also helped Clue’s developers quickly overhaul several other important features within the application, including Calendar View, Analysis View, and the account management and settings screens.

More creativity made possible with Compose

Compose enabled developers to make Clue screens more intuitive, improve scrolling, and deploy a custom color system and component library that aligned with the brand—a huge win for the team. Previously, adding new features, visual representations, or user interactions was complicated because they required creating a custom view and ongoing maintenance.

Compose APIs made it much easier to test UI so Clue developers felt more confident about what they were shipping to users. As an added benefit, Clue developers now have more space for exploring UX innovation.

“The custom dynamic theming allows designers to freely explore their creativity without being limited by technological constraints,” said Moctezuma. “It provides a flexible and scalable approach to styling that can be easily adapted as our app evolves and grows, resulting in a visually appealing and cohesive user experience.”

All of these changes vastly improved the user experience for Clue subscribers, resulting in fewer error messages and bug reports. The Clue team also says that using Compose has enabled them to identify areas of improvement in the app’s code that could have potentially impacted its users.

“Compose increases developer velocity by eliminating boilerplate code, works seamlessly with the existing code base thanks to its Interoperability APIs, and improves UI testing—which has always been painful in Android development,” said Tilbe Saltan, a senior Android developer at Clue.

Continued success with Jetpack Compose

Compose has improved each subsequent app release and made preview and live editing features more reliable for Clue engineers, allowing for a more flexible development experience from start to finish. Since implementing Compose, the Clue team has also seen excitement from prospective candidates interested in working on the app so they can work with more modern development technologies.

“The future of Compose holds many potential development areas that could benefit developers and companies. As Compose continues to evolve, we can expect to see more improvements in performance, stability, tooling, and cross-platform support, which will make it an even more compelling choice for building high-quality UIs,” said Tilbe.


Get started

Optimize your UI development with Jetpack Compose.

Giving Users More Transparency and Control Over Account Data

Posted by Bethel Otuteye, Senior Director, Product Management, Android App Safety

Google Play has launched a number of recent initiatives to help developers build consumer trust by showcasing their apps' privacy and security practices in a way that is simple and easy to understand. Today, we’re building on this work with a new data deletion policy that aims to empower users with greater clarity and control over their in-app data.

For apps that enable app account creation, developers will soon need to provide an option to initiate account and data deletion from within the app and online. This web requirement, which you will link in your Data safety form, is especially important so that a user can request account and data deletion without having to reinstall an app.

While Play’s Data safety section already lets developers highlight their data deletion options, we know that users want an easier and more consistent way to request them. By creating a more intuitive experience with this policy, we hope to better educate our shared users on the data controls available to them and create greater trust in your apps and in Google Play more broadly.

As the new policy states, when you fulfill a request to delete an account, you must also delete the data associated with that account. The feature also gives developers a way to provide more choice: users who may not want to delete their account entirely can choose to delete other data only where applicable (such as activity history, images, or videos). For developers that need to retain certain data for legitimate reasons such as security, fraud prevention, or regulatory compliance, you must clearly disclose those data retention practices.

Moving image of a accessing account deletion from a mobile device.
Note: Images are examples and subject to change

While we’re excited about the greater control this will give people over their data, we understand it will take time for developers to prepare, especially those without an existing deletion functionality or web presence, which is why we’re sharing information and resources today.

As a first step, we’re asking developers to submit answers to new Data deletion questions in your app’s Data Safety form by December 7. Early next year, Google Play users will begin to see reflected changes in your app’s store listing, including the refreshed data deletion badge in the Data safety section and the new Data deletion area.

Developers who need more time can file for an extension in Play Console until May 31, 2024 to comply with the new policy.

For more information on data deletion and other policy changes announced today:

As always, thank you for your continued partnership in making Google Play a safe and trustworthy platform for everyone.

What’s new in WindowManager 1.1.0-beta01

Posted by Jon Eckenrode, Technical Writer, Software Engineering blog header featuring Android logos

The 1.1.0-beta01 release of Jetpack WindowManager continues the library’s steady progress toward stable release of version 1.1.0. The beta adds an assortment of new features and capabilities, which are ready for testing and early adoption today!

We need your feedback so we can make WindowManager work best for you. Add the 1.1.0-beta01 dependency to your app, follow the migration steps below (if you’re already using a previous version of the library), and let us know what you think!

Activity embedding

androidx.window.embedding

Activity embedding enables you to optimize your multi-activity apps for large screens. The 1.1.0-beta01 release augments and refactors the APIs to provide greater versatility, capability, and control in managing task window splits. We started with experimental APIs in 1.0.0 and are promoting them ultimately to stable in 1.1.0.

tl;dr

Added a manifest setting so you can inform the system your app has implemented activity embedding. Refactored SplitController to be more focused on split properties; extracted split rule APIs to RuleController and activity embedding APIs to ActivityEmbeddingController. Added the SplitAttributes class to describe embedding splits. Added the EmbeddingAspectRatio class to set a minimum ratio for applying activity embedding rules. Changed pixels units to display-independent pixels (dp). Enabled customization of split layouts. Added a tag to rules so that developers can identify and manage specific rules.

What’s new

PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED

  • Added as a boolean property of the <application> tag in the app manifest.

ActivityEmbeddingController

  • Added class for operations related to the Activity or ActivityStack classes.

  • Includes isActivityEmbedded() to replace the API in SplitController.

RuleController

  • Added class for operations related to the EmbeddingRule class and subclasses.
  • Includes the following APIs to replace APIs in SplitController:
    • addRule() — Adds a rule or updates the rule that has the same tag.
    • removeRule() — Removes a rule from the collection of registered rules.
    • setRules() — Establishes a collection of rules.
    • clearRules() — Removes all registered rules.
    • parseRules() — Parses rules from XML rule definitions.

          SplitAttributes

          • Added class to define the split layout.

          EmbeddingAspectRatio

          • Added class to define enum-like behavior constants related to display aspect ratio. Lets you specify when splits are enabled based on the parent window’s aspect ratio.

          See SplitRule for properties that use the constants.


          What’s changed

          EmbeddingRule

          • Added tag field for identification of split rules.

          SplitController
          • Refactored APIs to the following modules:
            • ActivityEmbeddingController
              • Moved isActivityEmbedded() to ActivityEmbeddingController.
            • RuleController
              • Removed the following APIs and replaced their functionality with RuleController APIs:
                • clearRegisteredRules()
                • getSplitRules()
                • initialize()
                • registerRule()
                • unregisterRule()
            • Deprecated isSplitSupported() method and replaced with splitSupportStatus property to provide more detailed information about why the split feature is not available.

            • The getInstance() method now has a Context parameter.

                    Note: The getInstance() methods of ActivityEmbeddingController and RuleController also have a Context parameter.
                    • Added SplitAttributes calculator functions to customize split layouts:
                      • setSplitAttributesCalculator()
                      • clearSplitAttributesCalculator()
                      • isSplitAttributesCalculatorSupported() to check whether the SplitAttributesCalculator APIs are supported on the device.

                    • Defined SplitSupportStatus nested class to provide state constants for the splitSupportStatus property. Enables you to modify app behavior based on whether activity embedding splits are supported in the current app environment.

                    SplitRule

                    • Added defaultSplitAttributes property which defines the default layout of a split; replaces splitRatio and layoutDirection.
                    • Added translation of the XML properties splitRatio and splitLayoutDirection to defaultSplitAttributes.
                    • Changed minimum dimension definitions to use density-independent pixels (dp) instead of pixels.
                      • Changed minWidth to minWidthDp with default value 600dp.
                      • Changed minSmallestWidth to minSmallestWidthDp with default value 600dp.
                      • Added minHeightDp property with default value 600dp.
                    • Added maxAspectRatioInHorizontal with default value ALWAYS_ALLOW.
                    • Added maxAspectRatioInPortrait with default value 1.4.
                    • Defined FinishBehavior nested class to replace finish behavior constants.
                    • Applied the property changes to the Builder nested class of SplitPairRule and SplitPlaceholderRule.

                        SplitInfo

                        • Replaced getSplitRatio() with getSplitAttributes() to provide additional split-related information.

                        Window layout

                        androidx.window.layout

                        The window layout library lets you determine features of app display windows. With the 1.1.0-beta01 release, you can now work in contexts other than just activities.

                        What’s changed

                        WindowInfoTracker

                        • Added non-activity UI context support in experimental.

                        WindowMetricsCalculator

                        • Added non-activity UI context support.

                        Migration steps

                        Take the next step and upgrade your app from a previous alpha version. And please let us know how we can further facilitate the upgrade process.

                        PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED
                        • To enable activity embedding, apps must add the property to the <application> tag in the app manifest: 

                        < property android:name="android.window.PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED" android:value="true" />

                        When the property is set to true, the system can optimize split behavior for the app early.


                        SplitInfo

                        • Check if the current split is stacked:

                        SplitInfo.splitAttributes.splitType is SplitAttributes.SplitType.ExpandContainersSplitType

                        • Check the current ratio:

                        if (SplitInfo.splitAttributes.splitType is SplitAttributes.SplitType.RatioSplitType) { val ratio = splitInfo.splitAttributes.splitType.ratio } else { // Ratio is meaningless for other types. }
                         

                        SplitController

                        • SplitController.getInstance()

                        changes to

                            SplitController.getInstance(Context)

                        • SplitController.initialize(Context, @ResId int)

                        changes to:

                        RuleController.getInstance(Context) .setRules(RuleController.parse(Context, @ResId int)) 
                        • SplitController.getInstance().isActivityEmbedded(Activity)
                        changes to:

                        ActivityEmbeddingController.getInstance(Context) .isActivityEmbedded(Activity)

                        • SplitController.getInstance().registerRule(rule)
                                  changes to:
                        RuleController.getInstance(Context).addRule(rule)

                        • SplitController.getInstance().unregisterRule(rule)

                        changes to:
                        RuleController.getInstance(Context).removeRule(rule)
                        • SplitController.getInstance().clearRegisteredRules()

                        changes to:
                        RuleController.getInstance(Context).clearRules()
                        • SplitController.getInstance().getSplitRules()

                        changes to:

                            RuleController.getInstance(Context).getRules() 


                        SplitRule

                        • Change minWidth to minWidthDp and minSmallestWidth to minSmallestWidthDp
                        • minWidthDp and minSmallestWidthDp now use dp units instead of pixels

                        Apps can use the following call:

                        TypedValue.applyDimension( COMPLEX_UNIT_DIP, minWidthInPixels, resources.displayMetrics )

                        or simply divide minWithInPixels by displayMetrics#density.  


                        SplitPairRule.Builder

                        • SplitPairRule.Builder( filters, minWidth, minSmallestWidth )

                        changes to:

                        SplitPairRule.Builder(filters) // Optional if minWidthInDp argument is 600. .setMinWidthDp(minWidthInDp) // Optional if minSmallestWidthInDp argument is 600. .setMinSmallestWidthDp(minSmallestWidthInDp)

                        • setLayoutDirection(layoutDirection) and setSplitRatio(ratio)

                        change to:

                        setDefaultSplitAttributes(SplitAttributes.Builder() .setLayoutDirection(layoutDirection) .setSplitType(SplitAttributes.SplitType.ratio(ratio)) .build() )

                        • setFinishPrimaryWithSecondary and setFinishSecondaryWithPrimary take the FinishBehavior enum-like constants.

                        See SplitRule migrations for details.

                        • Use:
                        setMaxAspectRatioInPortrait( EmbeddingAspectRatio.ALWAYS_ALLOW )
                        to show splits on portrait devices.

                        SplitPlaceholder.Builder

                        • Has only filters and placeholderIntent parameters; other properties move to setters.
                        See SplitPairRule.Builder migrations for details.  
                        • setFinishPrimaryWithPlaceholder takes the FinishBehavior enum-like constants.
                        See finish behavior migrations for details.

                        • setLayoutDirection(layoutDirection) and setSplitRatio(ratio)

                        change to 

                        setDefaultSplitAttributes(SplitAttributes.Builder() .setLayoutDirection(layoutDirection) .setSplitType(SplitAttributes.SplitType.ratio(ratio)) .build() )

                        See layout direction migrations for details.

                        • Use:

                        setMaxAspectRatioInPortrait( EmbeddingAspectRatio.ALWAYS_ALLOW )

                        to show splits on portrait devices.

                         
                        Finish behavior

                        Finish behavior constants must be migrated to FinishBehavior enum-like class constants:

                        • FINISH_NEVER changes to FinishBehavior.NEVER
                        • FINISH_ALWAYS changes to FinishBehavior.ALWAYS
                        • FINISH_ADJACENT changes to FinishBehavior.ADJACENT

                        Layout direction

                        Layout direction must be migrated to SplitAttributes.LayoutDirection:

                        • ltr changes to SplitAttributes.LayoutDirection.LEFT_TO_RIGHT
                        • rtl changes to SplitAttributes.LayoutDirection.RIGHT_TO_LEFT
                        • locale changes to SplitAttributes.LayoutDirection.LOCALE
                        • splitRatio migrates to SplitAttributes.SplitType.ratio(splitRatio)


                        Get started 

                        To get started with WindowManager, add the Google Maven repository to your app’s settings.gradle or project-level build.gradle file: 


                        dependencyResolutionManagement {

                            repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

                            repositories {

                                google()

                            }

                        }

                         Then add the 1.1.0-beta01 dependency to your app’s module-level build.gradle file: 


                        dependencies {

                            implementation 'androidx.window:window:1.1.0-beta01'

                            . . .

                        }

                         Happy coding!

                        Mercari reduces 355K lines of code, a 69% difference, by rebuilding with Jetpack Compose

                        Posted by the Android team

                        In 2020, the Mercari team took on a big initiative to update its app’s technical infrastructure. At the time, its codebase was seven years old and hadn’t undergone any major architectural updates. This affected the team’s ability to develop new features and release timely app updates. To resolve this technical debt, Mercari launched what it called the GroundUP initiative—a complete rewrite of its application across platforms, including Android.

                        The goal was to create a completely modernized application with a scalable design. While retooling the app, Mercari developers turned to Jetpack Compose, Android’s modern declarative toolkit for creating native UI. During the evaluation, the team learned rewriting in Jetpack Compose would help clean up their codebase and have more control over how the app looks.

                        A rewrite with less code

                        The Mercari team completely rewrote the architecture and tech stack for its Android app using Jetpack Compose. Mercari developers created a new design system and completely integrated it using Compose, enabling them to easily test and implement new features. Using this new design system, the Mercari team rewrote more than 130 UI screens for its marketplace and modernized the look and feel of many of their components.

                        With the help of the Jetpack Libraries, Mercari’s team eliminated all legacy code during the rewrite, drastically reducing its codebase and making it more manageable for developers. “Virtually, it’s the same app with way less code,” said Allan Conda, Android technology lead at Mercari. “The rewritten app has about 355,000 fewer lines of code, which is about 69% less than what it had before.”

                        Moving image showing lines of code that appear and disappear on the leftmost panel of the screen. The spacing between the boxes in the center panel changes, and the overall app view reflects these changes in the rightmost panel.

                        Interoperability with Views as an early adopter

                        When the Mercari team first began its GroundUP initiative, Jetpack Compose was only available in developer preview. They wanted the app written completely in Jetpack Compose due to its new declarative approach to creating UI. However, because it was still so new, they found themselves having to solve for unique edge cases using both toolkits.

                        For example, on Mercari’s listing form screens, users are prompted to input details about the merchandise they want to list. Users were then supposed to be able to select photos from their device gallery and rearrange them on this screen using a drag gesture. Gesture APIs weren’t available in Jetpack Compose at the time, so the team took advantage of Compose's AndroidView to seamlessly integrate Views that handled gestures on the listing form screen. This provided a stable yet temporary solution to implementing drag gestures until the feature became available with Jetpack Compose.

                        The Mercari team was impressed by how easy it was to switch between the two toolkits, and having the option to use Views alongside Compose gave them better control of edge cases like this. Compose now supports gesture APIs, and Mercari developers have since completely written and integrated the drag gesture component solely using Compose.

                        Jetpack Compose has matured a lot since Mercari’s initial adoption, and most Android developers no longer need to worry about having to interoperate with both toolkits as Android apps can now be written completely in Compose.

                        Improving and monitoring performance with Compose

                        Using Compose, the Mercari team automated baseline profile generation for every stable release of the app and found it to be really helpful. The home screen renders frames up to 2x faster with the default Compose baseline profile compared to without a baseline profile. By providing a custom profile, there’s an additional improvement of up to 20% faster when Mercari users are scrolling compared to just having the default baseline profile.

                        The team also wrote automated performance tests based on the app’s core scenarios with Android Macrobenchmark. “Using Android Macrobenchmark, we can automatically test start-up, scroll, and screen load times performance,” said Allan. “Currently, we have six core scenarios covered by these tests, like search results and browsing items.”

                        Additionally, Mercari developers integrated Firebase Performance Monitoring, a real-time app performance monitoring tool, with custom code to calculate scrolling performance on Compose screens. With Firebase Performance Monitoring, the Mercari team detected a performance issue on its search result screen. Using the Android Profiler to pinpoint the problem, Mercari developers discovered there were poor frame rates when scrolling search results. This resulted in the slow rendering instances being reduced by around 23.6%.

                        The Mercari team solved this frame rate issue with guidance from Google’s Compose performance best practices and Compose stability. Mercari developers had the app skip its Composables and hoist the unused states on the search results screen, significantly improving the frame rates.

                        Headshot of Allan Conda, Android Tech Lead at Mercari, similing, with quote text reads 'Jetpack Compose helped us implement our Design System and rewrite 130+ screens and many of our components'

                        More opportunities with Jetpack Compose

                        With less code to maintain, it’s much easier for Mercari developers to test and implement features. “We have a ton of experiments we can finally conduct using our refreshed platforms. Our users can expect new features coming to the Mercari app at a faster rate,” said Allan.

                        Mercari’s developers are excited to further develop the app using Animation APIs. With Compose, it’s much easier to animate components, which can result in huge improvements for Android UXs.

                        Get started

                        Optimize your UI development with Jetpack Compose.

                        Concepts users spend 70% more time using the app on tablets than on phones

                        Posted by the Android team

                        Concepts is a digital illustration app created by TopHatch that helps creative thinkers bring their visions to life. The app uses an infinitely-large canvas format, so its users can sketch, plan, and edit all of their big ideas without limitation, while its vector-based ink provides the precision needed to refine and reorganize their ideas as they go.

                        For Concepts, having more on-screen real estate means more comfort, more creative space, and a better user experience overall. That’s why the app was specifically designed with large screens in mind. Concepts’ designers and engineers are always exploring new ways to expand the app’s large screen capabilities on Android. Thanks to Android’s suite of developer tools and resources, that’s easier than ever.

                        Evaluating an expanding market of devices

                        Large screens are the fastest growing segment of Android users, with more than 270 million users on tablets, foldables, and ChromeOS devices. It’s no surprise then that Concepts, an app that benefits users by providing them with more screen space, was attracted to the format. The Concepts team was also excited about innovation with foldables because having the large screen experience with greater portability gives users more opportunities to use the app in the ways that are best for them.

                        The team at Concepts spends a lot of time evaluating new large screen technologies and experiences, trying to find what hardware or software features might benefit the app the most. The team imagines and storyboards several scenarios, shares the best ones with a close-knit beta group, and quickly builds prototypes to determine whether these updates improve the UX for its larger user base.

                        For instance, Concepts’ designers recently tested the Samsung Galaxy Fold and found that users benefited from having more screen space when the device was folded. With help from the Jetpack WindowManager library, Concepts’ developers implemented a feature to automatically collapse the UI when the Galaxy’s large screen was folded, allowing for more on-screen space than if the UI were expanded.

                        Foldable UI

                        Concepts’ first release for Android was optimized for ChromeOS and, because of this, supporting resizable windows was important to their user experience from the very beginning. Initially, they needed to use a physical device to test for various screen sizes. Now, the Concepts team can use Android’s resizeable emulator, which makes testing for different screen sizes much easier.

                        Android’s APIs and toolkit carry the workload

                        The developers’ goal with Concepts is to make the illustration experience feel as natural as putting pen to paper. For the Concepts team, this meant achieving as close to zero lag as possible between the stylus tip and the lines drawn on the Concepts canvas.

                        When Concepts’ engineers first created the app, they put a lot of effort into creating low-latency drawing themselves. Now, Android’s graphical APIs eliminate the complexity of creating efficient inking.

                        “The hardware to support low-latency inking with higher refresh rate screens and more accurate stylus data keeps getting better,” said David Brittain, co-founder and CEO of TopHatch, parent company of Concepts. “Android’s mature set of APIs make it easy.”

                        Concepts engineers also found that the core Android View APIs take care of most of the workload for supporting tablets and foldables and make heavy use of custom Views and ViewGroups in Concepts. The app’s color wheel, for example, is a custom View drawing to a Canvas, which uses Animators for the reveal animation. View, Canvas, and Animator are all classes from the Android SDK.

                        “Android’s tools and platform are making it easier to address the variety of screen sizes and input methods, with well-structured APIs for developing and increasing the number of choices for testing. Plus, Kotlin allows us to create concise, readable code,” said David.


                        Concepts’ users prefer large screens

                        Tablets and foldables represent the bulk of Concepts’ investments and user base, and the company doesn’t see that changing any time soon. Currently, tablets deliver 50% higher revenue per user than smartphone users. Tablets also account for eight of the top 10 most frequently used devices among Concepts’ users, with the other two being ChromeOS devices.

                        Additionally, Concepts’ monthly users spend 70% more time engaging with the app on tablets than on traditional smartphones. The application’s rating is also 0.3 stars higher on tablets.

                        “We’re looking forward to future improvements in platform usability and customization while increasing experimentation with portable form factors. Continued efforts in this area will ensure high user adoption well into the future,” said David.

                        Start developing for large screens today

                        Learn how you can reach a growing audience of users by increasing development for large screens and foldables today.