Tag Archives: latest

Policy Updates: New Wear OS App Quality Requirements

Posted by Ishaan Aggarwal, Product Manager

Today we are announcing upcoming policy changes intended to improve the quality of apps for Wear OS and their presentation in the Google Play Store. We are introducing these changes to ensure app users get a basic consistent experience across all apps in accordance with our latest Wear OS design and development principles. In addition, updates to the publishing requirements will improve the discovery and presentation of your Wear OS apps in the Google Play Store.

The new requirements will come into effect from August 31, 2023. Until then, we will continue to use the existing policies to review and maintain the quality of Wear OS apps. The overall Wear OS app review process will continue to be mandatory and remains unchanged.

Alongside the above policy changes, all Wear OS apps must target Android 11 (API level 30). Apps that target lower levels will stop being discoverable to all Google Play users whose devices run Android OS versions newer than the app’s target API level from August 31, 2023. This is to ensure that the app is built to meet the safety and quality standard that users expect from newer Wear OS versions.

The following list highlights examples of upcoming quality changes. See a comprehensive list of review criteria here:

  • Black Background – Use a black background for all apps and tiles.
images of watch faces side by side showing Do: Use black Background on the left and Don't use any other color for background on right
  • Ongoing Activity – When a user has an ongoing activity, you must do the following:
    • Show the ongoing activity indicator on the watch face.
    • Update recent apps with the appropriate app launcher chip for the ongoing activity.
    • Reference the ongoing activity from the tile, if the tile is present in the user’s tile carousel.

    Images of two watch faces displaying ongoing activity indicator at the bottom of the watch face on the left and Ongoing activity on an app launcher chip in recent apps on the right
  • Show Time – Display the time of day clearly at the top of the app home screen and any ongoing activity screens. We recommend that you display the time of day at the top of all activities except dialogs and confirmation screens.
    Images of two watch faces with showing time display at the top of the app on the left and Don’t display the time in a dialog, confirmation screen, or picker on the right
These quality updates span visual experience, functionality, performance, and Google Play listings; they are designed to help you provide a consistent, intuitive and enjoyable experience for Wear OS users. With careful consideration of app design, optimal functional behavior, and Google Play experiences, we are aiming to improve app quality and discoverability of quality apps across the Wear OS ecosystem.

As you design and develop, keep in mind the following recommendations to ensure a modern, successful, and discoverable app:
  • Build a modern app that targets API Level 30.
  • Test your app on devices running Wear OS 3 and above to make sure it works well on the latest Wear OS versions.
  • Consider the new Wear OS quality requirements early when designing and developing your app to create quality experience.

Thank you for your continued support of Wear OS by Google. We look forward to seeing what you create.

The first developer preview of Android 14

Posted by Dave Burke, VP of Engineering

Making Android work well for each and every one of the billions of Android users is a collaborative process between us, Android hardware manufacturers, and you, our developer community.

Illustration of badge style Android 14 logo

Today we're releasing the first Developer Preview of Android 14, and your feedback in these previews is a critical part of making Android better for everyone. Android 14 continues our work to improve your productivity as developers, along with enhancements to performance, privacy, security, and user customization. This preview is just the beginning, and we’ll have lots more to share as we move through the release cycle.

Android continues to deliver enhancements and new features year-round, and your Android 14 developer preview and Quarterly Platform Release (QPR) beta program feedback plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, 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 devices and form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. To help you build apps that adapt to different screen sizes, we've created window size classes, sliding pane layout, Activity embedding, and box with constraints and more, all supported in Jetpack Compose. With every release, our goal is to make it easier for you to optimize your app across all Android surfaces.

To help streamline getting your apps ready we have updated our app quality guidance for large screens, and provided additional learning opportunities around building for large screens and foldables. The large screen gallery contains proven design patterns along with design inspiration around the markets that your app supports such as social and communications, media, productivity, shopping, and reading apps.

Multi-device experiences are a big part of the future of Android. You can get started today with the Cross device SDK preview, allowing you to build rich experiences that intuitively work across different devices and form factors, and there's more to come.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Updates and additions to JobScheduler and Foreground Services

It's more complicated than necessary to perform some background work, such as downloading large files when WiFi is available. We're creating a standard path for this work to simplify your app development and potentially improve the user experience. We're also being more opinionated about how foreground services should be used, reserving them for only the highest priority user-facing tasks so that Android can improve resource consumption and battery life.

In Android 14, we are making changes to existing Android APIs (Foreground Services and JobScheduler) including adding new functionality for user-initiated data transfers, along with an updated requirement to declare foreground service types. The user-initiated data transfer job will make managing user initiated downloads and uploads easier, particularly when they require constraints such as downloading on Wi-Fi only. The requirement to declare foreground service types allows you to clearly define the intent of the background work of your app while making it clear which use-cases are appropriate for foreground services. In addition, Google Play will be rolling out new policies to ensure the appropriate use of these APIs, with more details coming soon.

Optimized broadcasts

We’ve made several optimizations to the internal broadcast system to improve battery life and responsiveness. While most of the optimizations are internal to Android and should not impact your apps, we have adjusted how apps receive context-registered broadcasts once the app goes into a cached state. Broadcasts to context-registered receivers may be queued and only delivered to the app once it comes out of the cached state. Furthermore, some repeating context-registered broadcasts, such as BATTERY_CHANGED, may be merged into one final broadcast before it is delivered once the app comes out of the cached state.

Exact alarms

The invocation of exact alarms can significantly affect the device's resources, such as battery life. So in Android 14, newly installed apps targeting Android 13+ (SDK 33+) that are not clocks or calendars must request the user to grant them the SCHEDULE_EXACT_ALARM special permission before setting exact alarms. Apps can direct users to the settings page via an intent to toggle this permission, but we encourage you to evaluate your use cases and choose more flexibly scheduled alternatives when possible.

Clock and calendar apps targeting Android 13+ (SDK 33+) that rely on exact alarms as part of their core app workflow will be able to declare the USE_EXACT_ALARM normal permission instead (granted on install). Apps will not be able to publish a version of their app to the Play store with this permission in the manifest unless they qualify based on the policy language.

Customization

We're continuing to make sure that Android users can tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling

Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%.

To mitigate issues where text gets too large, starting in Android 14, a non-linear font scaling curve is automatically applied. This ensures that text that is already large enough doesn’t increase at the same rate as smaller text.
Examples of text scaling showing the differences between the sizing of standard font at 100% (no scaling)on the left, standard scaling (200%) in the middle, and non-linear scaling (200%)on the rightIn Android 14, you should test your app UI with the maximum font size using the Font size option within the Accessibility > Display size and text settings. Ensure that the adjusted large text size setting is reflected in the UI, and that it doesn’t cause text to be cut off. Our documentation has more on best practices.

Per-app language preferences

You can dynamically update your app's localeConfig with LocaleManager.setOverrideLocaleConfig to customize the set of languages displayed in the per-app language list in Android Settings. This allows you to customize the language list per region, run A/B experiments, and provide updated locales if your app utilizes server-side localization pushes.

IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language.

Grammatical Inflection API

The Grammatical Infection API allows you to more easily add support for users who speak languages which have grammatical gender. For example,

Masculine: “Vous êtes abonné à...”

Feminine: “Vous êtes abonnée à…”

Neutral: “Abonnement à…activé”

Grammatical gender is inherent to the language and cannot be easily worked around in some non-English languages. This new API lowers the effort to support viewer gender (who’s viewing the UI; not who’s being talked about) as compared to using the SelectFormat in ICU which must be applied on a per string basis.

To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

Privacy and Security

Runtime receivers

Apps targeting Android 14 must indicate if dynamic Context.registerReceiver() usage should be treated as "exported" or "unexported", a continuation of the manifest-level work from previous releases. Learn more here.

Safer implicit intents

To prevent malicious apps from intercepting intents, apps targeting Android 14 are restricted from sending intents internally that don't specify a package. Learn more here.

Safer dynamic code loading

Dynamic code loading (DCL) introduces outlets for malware and exploits, since dynamically downloaded executables can be unexpectedly manipulated, causing code injection. Apps targeting Android 14 require dynamically loaded files to be marked as read-only. Learn more here.

Block installation of apps

Malware often targets older API levels to bypass security and privacy protections that have been introduced in newer Android versions. To protect against this, starting with Android 14, apps with a targetSdkVersion lower than 23 cannot be installed. This specific version was chosen because some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 (API level 23).

On devices that upgrade to Android 14, any apps with a targetSdkVersion lower than 23 will remain installed.

You can test apps targeting an older API level using the following ADB command: 

adb install --bypass-low-target-sdk-block FILENAME.apk

Credential Manager and Passkeys support

We recently announced the alpha release of Credential Manager, a new Jetpack API that allows you to simplify your users' authentication journey, while also increasing security with support of passkeys. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors and more convenient for users (they require just a biometric swipe to securely sign in on any device). Read more here.

App compatibility

We’re working to make updates faster and smoother with each platform release by prioritizing app compatibility. In Android 14 we’ve made most app-facing changes opt-in to give you more time to make any necessary app changes, and we’ve updated our tools and processes to help you get ready sooner.

OpenJDK 17 Support - This preview includes access to 300 OpenJDK 17 classes. We are working hard to fully enable Java 17 language features in upcoming developer previews. These include record classes, multi-line strings and pattern matching instanceof. Thanks to Google Play system updates (Project Mainline), over 600M devices are enabled to receive the latest Android Runtime (ART) updates that include these changes. This is part of our commitment to give apps a more consistent, secure environment across devices, and to deliver new features and capabilities to users independent of platform releases.

Easier testing and debugging of changes - To make it easier for you to test the opt-in changes that can affect your app, we’ll make many of them toggleable again this year. With the toggles, you can force-enable or disable the changes individually from Developer options or adb. Check out the details here.
App compatibility toggles in Developer Options
Platform stability milestone - Like last year, we’re letting you know our Platform Stability milestone well in advance, to give you more time to plan for app compatibility work. 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 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

The Developer Preview 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. For phones, you can get started today by flashing a system image onto a Pixel 7 Pro, Pixel 7, Pixel 6a, Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5, or Pixel 4a (5G) device. 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 during the early part of the developer preview. 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 system images and SDK regularly throughout the Android 14 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download only. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 1 now. Otherwise you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

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

The first developer preview of Android 14

Posted by Dave Burke, VP of Engineering

Making Android work well for each and every one of the billions of Android users is a collaborative process between us, Android hardware manufacturers, and you, our developer community.

Illustration of badge style Android 14 logo

Today we're releasing the first Developer Preview of Android 14, and your feedback in these previews is a critical part of making Android better for everyone. Android 14 continues our work to improve your productivity as developers, along with enhancements to performance, privacy, security, and user customization. This preview is just the beginning, and we’ll have lots more to share as we move through the release cycle.

Android continues to deliver enhancements and new features year-round, and your Android 14 developer preview and Quarterly Platform Release (QPR) beta program feedback plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, 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 devices and form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. To help you build apps that adapt to different screen sizes, we've created window size classes, sliding pane layout, Activity embedding, and box with constraints and more, all supported in Jetpack Compose. With every release, our goal is to make it easier for you to optimize your app across all Android surfaces.

To help streamline getting your apps ready we have updated our app quality guidance for large screens, and provided additional learning opportunities around building for large screens and foldables. The large screen gallery contains proven design patterns along with design inspiration around the markets that your app supports such as social and communications, media, productivity, shopping, and reading apps.

Multi-device experiences are a big part of the future of Android. You can get started today with the Cross device SDK preview, allowing you to build rich experiences that intuitively work across different devices and form factors, and there's more to come.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Updates and additions to JobScheduler and Foreground Services

It's more complicated than necessary to perform some background work, such as downloading large files when WiFi is available. We're creating a standard path for this work to simplify your app development and potentially improve the user experience. We're also being more opinionated about how foreground services should be used, reserving them for only the highest priority user-facing tasks so that Android can improve resource consumption and battery life.

In Android 14, we are making changes to existing Android APIs (Foreground Services and JobScheduler) including adding new functionality for user-initiated data transfers, along with an updated requirement to declare foreground service types. The user-initiated data transfer job will make managing user initiated downloads and uploads easier, particularly when they require constraints such as downloading on Wi-Fi only. The requirement to declare foreground service types allows you to clearly define the intent of the background work of your app while making it clear which use-cases are appropriate for foreground services. In addition, Google Play will be rolling out new policies to ensure the appropriate use of these APIs, with more details coming soon.

Optimized broadcasts

We’ve made several optimizations to the internal broadcast system to improve battery life and responsiveness. While most of the optimizations are internal to Android and should not impact your apps, we have adjusted how apps receive context-registered broadcasts once the app goes into a cached state. Broadcasts to context-registered receivers may be queued and only delivered to the app once it comes out of the cached state. Furthermore, some repeating context-registered broadcasts, such as BATTERY_CHANGED, may be merged into one final broadcast before it is delivered once the app comes out of the cached state.

Exact alarms

The invocation of exact alarms can significantly affect the device's resources, such as battery life. So in Android 14, newly installed apps targeting Android 13+ (SDK 33+) that are not clocks or calendars must request the user to grant them the SCHEDULE_EXACT_ALARM special permission before setting exact alarms. Apps can direct users to the settings page via an intent to toggle this permission, but we encourage you to evaluate your use cases and choose more flexibly scheduled alternatives when possible.

Clock and calendar apps targeting Android 13+ (SDK 33+) that rely on exact alarms as part of their core app workflow will be able to declare the USE_EXACT_ALARM normal permission instead (granted on install). Apps will not be able to publish a version of their app to the Play store with this permission in the manifest unless they qualify based on the policy language.

Customization

We're continuing to make sure that Android users can tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling

Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%.

To mitigate issues where text gets too large, starting in Android 14, a non-linear font scaling curve is automatically applied. This ensures that text that is already large enough doesn’t increase at the same rate as smaller text.
Examples of text scaling showing the differences between the sizing of standard font at 100% (no scaling)on the left, standard scaling (200%) in the middle, and non-linear scaling (200%)on the rightIn Android 14, you should test your app UI with the maximum font size using the Font size option within the Accessibility > Display size and text settings. Ensure that the adjusted large text size setting is reflected in the UI, and that it doesn’t cause text to be cut off. Our documentation has more on best practices.

Per-app language preferences

You can dynamically update your app's localeConfig with LocaleManager.setOverrideLocaleConfig to customize the set of languages displayed in the per-app language list in Android Settings. This allows you to customize the language list per region, run A/B experiments, and provide updated locales if your app utilizes server-side localization pushes.

IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language.

Grammatical Inflection API

The Grammatical Infection API allows you to more easily add support for users who speak languages which have grammatical gender. For example,

Masculine: “Vous êtes abonné à...”

Feminine: “Vous êtes abonnée à…”

Neutral: “Abonnement à…activé”

Grammatical gender is inherent to the language and cannot be easily worked around in some non-English languages. This new API lowers the effort to support viewer gender (who’s viewing the UI; not who’s being talked about) as compared to using the SelectFormat in ICU which must be applied on a per string basis.

To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

Privacy and Security

Runtime receivers

Apps targeting Android 14 must indicate if dynamic Context.registerReceiver() usage should be treated as "exported" or "unexported", a continuation of the manifest-level work from previous releases. Learn more here.

Safer implicit intents

To prevent malicious apps from intercepting intents, apps targeting Android 14 are restricted from sending intents internally that don't specify a package. Learn more here.

Safer dynamic code loading

Dynamic code loading (DCL) introduces outlets for malware and exploits, since dynamically downloaded executables can be unexpectedly manipulated, causing code injection. Apps targeting Android 14 require dynamically loaded files to be marked as read-only. Learn more here.

Block installation of apps

Malware often targets older API levels to bypass security and privacy protections that have been introduced in newer Android versions. To protect against this, starting with Android 14, apps with a targetSdkVersion lower than 23 cannot be installed. This specific version was chosen because some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 (API level 23).

On devices that upgrade to Android 14, any apps with a targetSdkVersion lower than 23 will remain installed.

You can test apps targeting an older API level using the following ADB command: 

adb install --bypass-low-target-sdk-block FILENAME.apk

Credential Manager and Passkeys support

We recently announced the alpha release of Credential Manager, a new Jetpack API that allows you to simplify your users' authentication journey, while also increasing security with support of passkeys. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors and more convenient for users (they require just a biometric swipe to securely sign in on any device). Read more here.

App compatibility

We’re working to make updates faster and smoother with each platform release by prioritizing app compatibility. In Android 14 we’ve made most app-facing changes opt-in to give you more time to make any necessary app changes, and we’ve updated our tools and processes to help you get ready sooner.

OpenJDK 17 Support - This preview includes access to 300 OpenJDK 17 classes. We are working hard to fully enable Java 17 language features in upcoming developer previews. These include record classes, multi-line strings and pattern matching instanceof. Thanks to Google Play system updates (Project Mainline), over 600M devices are enabled to receive the latest Android Runtime (ART) updates that include these changes. This is part of our commitment to give apps a more consistent, secure environment across devices, and to deliver new features and capabilities to users independent of platform releases.

Easier testing and debugging of changes - To make it easier for you to test the opt-in changes that can affect your app, we’ll make many of them toggleable again this year. With the toggles, you can force-enable or disable the changes individually from Developer options or adb. Check out the details here.
App compatibility toggles in Developer Options
Platform stability milestone - Like last year, we’re letting you know our Platform Stability milestone well in advance, to give you more time to plan for app compatibility work. 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 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

The Developer Preview 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. For phones, you can get started today by flashing a system image onto a Pixel 7 Pro, Pixel 7, Pixel 6a, Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5, or Pixel 4a (5G) device. 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 during the early part of the developer preview. 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 system images and SDK regularly throughout the Android 14 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download only. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 1 now. Otherwise you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

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

Compose for Wear OS 1.1 is now stable: check out new features!

Posted by Kseniia Shumelchyk, Android Developer Relations Engineer

Today we’re releasing version 1.1 of Compose for Wear OS, our modern declarative UI toolkit to help developers build beautiful, responsive apps for Wear OS.

Since the first stable release earlier this year, we have seen many developers taking advantage of the powerful tools and intuitive APIs to make building their app simpler and more efficient. Todoist and Outdooractive are some of the developers that rebuilt their Wear apps with Compose and accelerated the delivery of a new, functional user experience.

Todoist increased its growth rate by 50% since rebuilding their app for Wear 3 and Outdooractive reduced development time by 30% and saw a significant boost in developer productivity and better design/developer collaboration:

“Compose makes the UI code more intuitive to write and read, allowing us to prototype faster in the design phase and also collaborate better on the code. What would have taken us days now takes us hours.”

The Compose for Wear OS 1.1 release contains new features and brings improvements to existing components, focusing on UX and accessibility. We’ve already updated our samples, codelab, and Horologist libraries to work with Compose for Wear OS 1.1.


New features and APIs

The Compose for Wear OS 1.1 release includes the following new functionality (baseline profiles already added for new components):

Outlined style for Chips and Buttons

To give you additional ability to customize the user interface, we added outlined styles for Chips and Buttons. New OutlinedChip and OutlinedButton composables provide a transparent component with a thin border that can be used for medium-emphasis actions. Also available for compact versions: OutlinedCompactChip and OutlinedCompactButton.
Demonstration of OutlinedChip and OutlinedButton composables on a round watch face
OutlinedChip and OutlinedButton composables

Modifying Chip and Button shapes

Starting from version 1.1, you can also modify shapes for Chip/ToggleChip and Button/ToggleButton components using new functions overloads.
Demonstration of Different Chip and Button shapes on a round watch face
Different Chip and Button shapes

Placeholder API

A new experimental API has been added to implement placeholder support. This can be used to achieve three distinct visual effects separately or all together:

  • A placeholder background brush effect used in containers such as Chip and Cards to draw over the normal background when waiting for content to load.
  • A Modifier.placeholder() to draw a stadium shaped placeholder widget over the top of content that is being loaded.
  • A Modifier.placeholderShimmer() for gradient/shimmer effect that is drawn over the top of the other effects to indicate to users that the current state is waiting for data to load.
These effects are designed to be coordinated and shimmer and wipe-off in an orchestrated fashion.
Moving demonstration of Placeholder API usage examples on a round watch face
Placeholder API usage examples

Check out the reference docs and sample in Horologist to see how to apply the placeholder to common use cases, such as a Chip with icon and a label that puts placeholder over individual content slots and draws a placeholder shimmer on top while waiting for data to load.

Modifier.scrollAway

Horologist’s fadeAway modifier has been graduated to scrollAway modifier in version 1.1. Modifier.scrollAway scrolls an item vertically in and out of view, based on the scroll state, and already has overloads to work with Column, LazyColumn and ScalingLazyColumn.

Use this modifier to make TimeText fade out of the view as the user starts to scroll a list of items upwards.
Moving demonstration of ScrollAway modifier usage with TimeText on a round watch face
ScrollAway modifier usage with TimeText

Additional parameters in CurvedTextStyle

CurvedTextStyle now supports additional parameters (fontFamily, fontWeight, fontStyle, fontSynthesis) to specify font details when creating a curved text style. Extended curved text style can be used on both curvedText and basicCurvedText.

Demonstration of applying different font to curved text on a round watch face
Applying different font to curved text

UX and accessibility improvements

The 1.1 release also focuses on bringing a refined user experience, improvements for TalkBack support and overall better accessibility:

  • ToggleChip and SplitToggleChip support usage of animated toggle controls (Checkbox, Switch and RadioButton) that can be used instead of the static icons provided by ToggleChipDefaults.
  • Default gradient colors for Chip/ToggleChip and Cards were adjusted to match the latest UX specification.
  • Updated a number of the default colors in the MaterialTheme to improve accessibility as the original colors did not have sufficient contrast.
  • Accessibility improvements to Picker so that multi-picker screens are navigable with screen readers and the content description is accessible.
  • InlineSlider and Stepper now have button roles, so that TalkBack can recognize them as buttons.
  • The PositionIndicator in Scaffold is now positioned and sized so that it only takes the space needed. This is useful when semantic information is added to it, so TalkBack gets the correct bounds of the PositionIndicator on screen.

It’s time ⌚ to bring your app to the wrist!

Get started

To begin developing with Compose for Wear OS, get started with hands-on experience trying our codelab, and make sure to check out the documentation and samples. Visit Compose for Wear OS release notes for full list of changes available in version 1.1.

Note that using version 1.1 of Compose for Wear OS requires using the version 1.3 of androidx.compose libraries and therefore Kotlin 1.7.10. Check out the Compose to Kotlin Compatibility Map for more information.

Provide feedback

Compose for Wear OS continues to evolve with the features you’ve been asking for. Please do continue providing us feedback on the issue tracker and join Kotlin Slack #compose-wear channel to connect with the Google team and dev community.

We’re excited to see a growing number of apps using Compose for Wear OS in production, and we’re grateful for all issues and requests that help us to make the toolkit better!

Start building for Wear OS now

Discover even more with technical sessions from the Android Dev Summit providing guidance on app architecture, testing, handling rotary input, and verticalized sessions for media and fitness.

Android 13 for TV is now available

Posted by Wolfram Klein, Product Manager, Android TV OSToday we’re releasing the newest version of Android TV OS, Android 13 for TV! This latest release brings further improvements in performance and accessibility to help our developers build engaging apps for the next generation of TVs.

Here’s a look at some of what’s new in Android 13 for TV.

Performance and Quality

Android 13 brings new APIs to the big screen that help developers deliver high quality experiences to users across different device types.

  • Improvements to the AudioManager API allow developers to anticipate audio attribute support for the active audio device and select the optimal format without starting playback.
  • Users can now change the default resolution and refresh rate on supported HDMI source devices for a more reliable playback experience.
  • HDMI state changes are now surfaced to the MediaSession lifecycle, allowing TV dongles and other HDMI source devices to save power and pause content in reaction to HDMI state changes.

Accessibility and Input Controls

Android 13 brings new features to make interacting with TV more adaptable.

  • The InputDevice API now supports different keyboard layouts. Game developers can also reference keys by their physical location to support different layouts of physical keyboards.
  • A newly created audio descriptions API in AccessibilityManager allows your app to query the new system-wide audio description preference setting, helping developers provide audio descriptions in line with a user’s preference automatically.

Check out the Android TV OS developer site for details on even more features that come with Android 13 on TVs. The new release is now available for both ADT-3 and the Android TV emulator, and developers can choose to test on either the Google TV interface or the standard Android TV interface. As always, we are thankful to our developers for the continued support of Android TV OS. We can’t wait to see what amazing and innovative experiences you’ll continue to build for the big screen.

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Over the course of 2022, we've published design proposals and released a number of Developer Previews. We appreciate all of the feedback we've received which has helped us refine and improve these proposals.

Beginning early next year we plan to rollout the initial Privacy Sandbox Beta to Android 13 mobile devices, so that developers can take the next steps in testing these new solutions. We'll start with a small percentage of devices and increase over time. Note that Developer Previews will continue to be released and this is where we’ll first deliver the latest features for early feedback before being released on production devices.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.


Enroll to access the Privacy-Preserving APIs

Starting with the Beta release, as well as future Developer Previews, developers will need to complete an enrollment process in order to utilize the ads-related APIs (including Topics, FLEDGE, and Attribution Reporting). The enrollment process will verify developer identity and gather developer-specific data needed by the APIs. You can learn more about how to enroll here.


How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

During the initial rollout stages, enrolled developers will also need to join the early testers program. This program will allow developers to test the APIs on a limited number of their own Android 13 devices for internal apps and requested published apps.

For the SDK Runtime, we’ll have a closed beta for developers to test Runtime-enabled SDK distribution to select apps. Because of the coordination required to test the SDK Runtime on production devices, we expect this beta to involve a limited number of partners who can dedicate resources to support this testing. If you’re interested in participating, please register your interest.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.


Advice For Advertisers & Publishers

We’ve heard from many advertisers and publishers about the role they can play in testing these new technologies. For companies that rely on third party solutions for ad serving or ad measurement, we recommend working with your providers to understand their testing roadmaps and how you can participate in early testing of Privacy Sandbox.

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Over the course of 2022, we've published design proposals and released a number of Developer Previews. We appreciate all of the feedback we've received which has helped us refine and improve these proposals.

Beginning early next year we plan to rollout the initial Privacy Sandbox Beta to Android 13 mobile devices, so that developers can take the next steps in testing these new solutions. We'll start with a small percentage of devices and increase over time. Note that Developer Previews will continue to be released and this is where we’ll first deliver the latest features for early feedback before being released on production devices.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.


Enroll to access the Privacy-Preserving APIs

Starting with the Beta release, as well as future Developer Previews, developers will need to complete an enrollment process in order to utilize the ads-related APIs (including Topics, FLEDGE, and Attribution Reporting). The enrollment process will verify developer identity and gather developer-specific data needed by the APIs. You can learn more about how to enroll here.


How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

During the initial rollout stages, enrolled developers will also need to join the early testers program. This program will allow developers to test the APIs on a limited number of their own Android 13 devices for internal apps and requested published apps.

For the SDK Runtime, we’ll have a closed beta for developers to test Runtime-enabled SDK distribution to select apps. Because of the coordination required to test the SDK Runtime on production devices, we expect this beta to involve a limited number of partners who can dedicate resources to support this testing. If you’re interested in participating, please register your interest.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.


Advice For Advertisers & Publishers

We’ve heard from many advertisers and publishers about the role they can play in testing these new technologies. For companies that rely on third party solutions for ad serving or ad measurement, we recommend working with your providers to understand their testing roadmaps and how you can participate in early testing of Privacy Sandbox.

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Over the course of 2022, we've published design proposals and released a number of Developer Previews. We appreciate all of the feedback we've received which has helped us refine and improve these proposals.

Beginning early next year we plan to rollout the initial Privacy Sandbox Beta to Android 13 mobile devices, so that developers can take the next steps in testing these new solutions. We'll start with a small percentage of devices and increase over time. Note that Developer Previews will continue to be released and this is where we’ll first deliver the latest features for early feedback before being released on production devices.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.


Enroll to access the Privacy-Preserving APIs

Starting with the Beta release, as well as future Developer Previews, developers will need to complete an enrollment process in order to utilize the ads-related APIs (including Topics, FLEDGE, and Attribution Reporting). The enrollment process will verify developer identity and gather developer-specific data needed by the APIs. You can learn more about how to enroll here.


How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

During the initial rollout stages, enrolled developers will also need to join the early testers program. This program will allow developers to test the APIs on a limited number of their own Android 13 devices for internal apps and requested published apps.

For the SDK Runtime, we’ll have a closed beta for developers to test Runtime-enabled SDK distribution to select apps. Because of the coordination required to test the SDK Runtime on production devices, we expect this beta to involve a limited number of partners who can dedicate resources to support this testing. If you’re interested in participating, please register your interest.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.


Advice For Advertisers & Publishers

We’ve heard from many advertisers and publishers about the role they can play in testing these new technologies. For companies that rely on third party solutions for ad serving or ad measurement, we recommend working with your providers to understand their testing roadmaps and how you can participate in early testing of Privacy Sandbox.

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."

Leading Health and Fitness Apps Roll Out Health Connect Integrations

Posted by Sara Hamilton, Developer RelationsEarlier this year, we introduced Health Connect as a way for app developers like you to have early access to a platform that securely shares health and fitness data across Android devices, with user consent. We collaborated with Samsung to build this platform which simplifies the connectivity between your apps while providing centralized privacy controls for users. We are now making the Health Connect (Beta) app available for download in Google Play to give users a central place to manage their privacy settings with granular controls to see which apps have access to data at any given time.

Today, 10+ health, fitness and wellness apps are rolling out integrations with the platform including early adopters of Health Connect like MyFitnessPal, Oura and Peloton.
Against a light blue background, an illustration of a person and their dog looking at a large screen with a 3x3 display of health app icons: Lifesum, Fitbit, MyFitnessPal, Dexcom, Samsung Health, Oura, Peloton, Flo,and WW.
Through the first wave of integrations, we have seen Health Connect provide many key benefits to developers.


Reduced fragmentation makes it easier to give users more holistic health insights

By enabling health and fitness apps to talk to each other, each app is able to provide a user with better, more holistic health insights.

In the past, developers had to establish multiple API connections to share data between different apps and each integration was costly to build and maintain. This limited developers’ data sharing capabilities and made it hard for users to unlock this data so that it could be utilized in different apps.

Now, with Health Connect, building an integration with a new app is as simple as reading in new data from Health Connect, rather than building a whole new integration.

For example, Android users will now be able to sync and get credit for their Peloton workouts in apps like Oura, MyFitnessPal, WeightWatchers and Lifesum. Now, through a single integration with Health Connect, Peloton Members will have the option to share their workout stats across the ecosystem of apps they use to support their overall wellness.

Phone screen showing App permissions for all apps that can access data stored in Health Connect

Standardized data schema ensures data consistency between apps

Health Connect provides a standardized data schema which supports 40+ data types across 6 categories. The schema is intuitive to use and covers a wide range of use cases, from exercises to sleep tracking to vital signs. It only requires just a few lines of code to read and write any of these data types in Health Connect. Health Connect even supports complex aggregations so that you can completely customize your queries to your app’s use case.

"With Health Connect APIs, our engineers were able to easily adapt their existing architecture in order to read and write user health data such as nutrition, hydration, exercise, and steps. With this integration, we're now able to consume data from any 3rd party application that also writes to Health Connect, expanding our users' choices while allowing them more flexibility to grant granular permissions about which data they want to share"
– Jason Peterson, Chief Technology Officer of MyFitnessPal


Centralize privacy controls for users, with less code

Previously, users had to navigate to multiple apps to manage data permissions. And, developers had to build out permissions management UIs themselves.

With Health Connect, users can easily manage permissions in a single place, with granular controls to see which apps are accessing data at any given time.

For developers, Health Connect provides the permissions management hub and granular permissions UIs out of the box, so you can set this up quickly.

Phone screen showing granular permissions for Run Tracker app to access in Health Connect
granular permissions screen that shows the different data types

For example, Signos was able to quickly set up permissions checks with Health Connect. “One aspect I was pleasantly surprised by was the user onboarding UX,” said Signos developer Jake Smith. “A simple, drop-in piece of code sets up the permissions so users can start reaping the benefits.”


We’re just getting started

Join the many developers who have already integrated with Health Connect and don’t miss out on the opportunity to develop richer insights for your users. Check out our documentation, helpful video tutorials, and code samples – and start building today!

What’s new in Jetpack Compose

Posted by Jolanda Verhoef, Android Developer Relations Engineer

We launched Jetpack Compose over a year ago, and have been busy improving it ever since. We’ve added new features and invented powerful tools to make your experience developing Android UI as productive, intuitive and fun as possible. So, if you're starting a new app, it's time to write it with Compose! With Material Design 3 support, new Bill Of Materials, Compose WearOS Stable and Android TV (alpha), Compose Camp, and many other pieces of news… It's an exciting release!

Compose in the Community

In the last year, we’ve seen many companies developing with Compose at scale, implementing new features and migrating screens from views to Compose. For example, we talked to the engineers at Lyft, who told us that over 90% of their new feature code is written in Compose, and moving to Compose made their code much simpler and easier to maintain. They also shared “We rewrote the button component in our app using Compose. Before it required 800 lines of code across three files plus 17 different XML files, and it is now down to a single Kotlin file with 300 lines of code. This is a 60% reduction in the Kotlin code alone“. The team at Zepeto has also been implementing Compose across many features, and are enjoying the experience, as “Compose simplified our UI layer logic, making it easier to understand code written by my colleagues.”
It’s great to see how these teams experience faster development cycles, and also feel their UI code is more concise and readable. And they’re not the only ones. Since this year’s Google I/O, the number of top 1000 apps on Google Play using Compose has increased by 50%! To help your team follow in the footsteps of the teams at Lyft, Zepeto, and others, we published a guide on How to Adopt Compose for your Team. It outlines how and where to start, and shows the areas of development where Compose can bring huge added value.


Compose, October ‘22 release

Today we’re releasing a new stable version of Compose, with some exciting features and news.

First of all, we’ve heard from you how it can be daunting to track versions across different artifacts that might go on different release schedules, so we’re now publishing, together with every Stable release of any of the Compose artifacts, a Bill of Materials, or BOM, to make your life easier.

Our first BOM release, Compose October ‘22, brings support for Staggered Grids, drawing Text directly to Canvas, Pull to Refresh, as well as performance improvements and bug fixes.


Compose Bill of Materials

A BOM is a Maven module that declares a set of libraries with their versions. It will greatly simplify the way you define Compose library versions in your Gradle dependencies block, especially now that we moved the various Jetpack Compose libraries to independent versioning schemes. Instead of defining each version separately, which can become cumbersome and prone to errors when library versions start to differ, you now only need to define one BOM version and all Compose library versions will be extracted from that. We will publish a new version of the BOM every time a Compose artifact has a new stable release, so moving from stable release to stable release is going to be much simpler.

dependencies {
    // Import the Compose BOM
    implementation platform('androidx.compose:compose-bom:2022.10.00')

    // Declare dependencies for the desired Compose libraries without versions
    implementation 'androidx.compose.foundation:foundation'
    androidTestImplementation 'androidx.compose.ui:ui-test-junit4'

    ...
}


We’ve added the instructions on how to add the Compose BOM to our Quick start guide. Note that you can still choose to define your dependencies using hard-coded versions. The BOM is added as a useful way to simplify dependencies and make upgrades easier.
    

Modifiers on overdrive

Behind the scenes, we’re always working on improving Compose performance. The October ‘22 release includes a major refactor of how Modifiers work under the hood. While you will not notice anything changing in the APIs, this refactor paves the way for greatly improving Modifier performance. Learn more about the rationale behind the changes, and what’s planned for the near future in the ADS talk Compose Modifiers deep dive.


Popup & Dialog elevation change

Accessibility is always a first-class citizen for Compose, and this release contains a behavior change that helps fix an Accessibility bug with Popups and Dialogs: their maximum elevation is decreased from 30dp to 8dp. Your app will be impacted only if it uses a custom dialog or popup implementation with an elevation higher than 8dp. The release notes contain more information about the change, including a way to override the new behavior as an interim solution (keep in mind that we always recommend using 8dp maximum when customizing popups or dialogs).


New features

We added a lot of new functionality to Compose. Here are some highlights:

Compose Material 3 stable

Today we also announce the first stable release of the Compose Material 3 library! You can build an app using Compose and theme it according to Material Design 3, our latest iteration of Material Design. Use Material Design 3 to further customize your app’s colors, typography and shapes to make your brand stand out! The library contains fresh and updated versions of many UI components, such as buttons, cards, checkboxes, switches, navigation bars, drawers, and many more, with support for others on its way. See a list of all the supported components in the documentation and learn more in this blog post.

To help you adopt Material 3 check out our new migration guide with clear guidance on how Material 2 concepts translate to Material 3. The default template in Android Studio Flamingo now uses Material 3, to get you up and running in no time. We’ve also updated many of our sample apps, tutorials, templates, and codelabs to use Material 3 so you can learn as you go!

New tools

Developing your app using Jetpack Compose is much easier with the new and improved tools around it. We’ve added tons of new features to Android Studio to improve your workflow and efficiency:

Android Studio Dolphin is the latest stable release, bringing you:

  • Animation Coordination
  • Multipreview annotations
  • Recomposition counts in Layout Inspector

Android Studio Electric Eel contains beta features, like:

  • Live Edit (experimental)
  • Composition rendering highlighting
  • Configuring Preview devices
  • Live updates in Previews

Android Studio Flamingo contains canary features such as:

  • New project templates use Compose and Material 3 by default
  • Live Edit turned on by default
  • Improved composition tracing to help you better inspect performance issues.

Relay

Today we also launch the first alpha version of Relay, a design-to-code solution for improving designer-developer collaboration. Designers create UI components using the Figma plugin, and developers use the Android Studio plugin to automatically use these components in their apps. The generated components are composable functions and can be integrated directly into your Compose app. Learn more about Relay in the documentation.


Compose on WearOS, Large Screens and TV

In July we released the first Stable version of Wear Compose, ready to build production apps. Compose for Wear OS is our recommended approach for building UIs for Wear OS apps. We’ve included over twenty Compose UI components that were designed specifically for Wearables, like TimeText, PositionIndicator, and ScalingLazyColumn.

We’re also continuing to make it easier to design, develop, and test apps for large screens such as foldables, tablets, and Chrome OS. The material3-window-size-class library graduated to Stable, giving you a set of opinionated viewport breakpoints to work with. Large screen designs often contain staggered grids, and the addition of LazyHorizontalStaggeredGrid and LazyVerticalStaggeredGrid will help implement these.



Feedback from the Android community always moves us forward. With your input we have updated our roadmap, focusing on areas that will help you implement Compose successfully. We’re now focusing on supporting more advanced use cases, covering more Material 3 components, improving platform support, tooling and performance.


New and updated guidance

No matter where you are in your learning journey, we’ve got you covered! We added and revamped a lot of the guidance on Compose:

Compose Camp

Running from September through December is a world-wide community-organized event series called Compose Camp! With both a beginner and an experienced track, developers of all levels can join Compose Camp to learn together with others. We already see lots of traction, with many videos being posted by GDGs and GDSCs all over the globe, and many events hosted on our Community platform.


Happy Composing!

We hope that you’re as excited by these developments as we are! If you haven't started yet, it's time to learn Jetpack Compose and see how your team and development process can benefit from it. Get ready for improved velocity and developer productivity. Happy Composing!