Since introducing the Android XR SDK, developers have transformed their ideas into innovative, immersive experiences for XR headsets and wired XR glasses. As the ecosystem expands, you can more easily take those experiences from preview to production and reach users wherever they are.
Today, we're excited to announce that Jetpack SceneCore, ARCore for Jetpack XR, and XR Runtime have reached beta with Jetpack Compose for XR to follow soon! This means the APIs are stabilizing, making it a great time to start integrating them into your production workflows and creating for Android XR.
Why the Jetpack XR SDK?
The Jetpack XR SDK includes all the tools and libraries you need to build immersive and augmented experiences for Android XR. Whether you're porting an existing 2D app or creating a new 3D XR app from scratch, you can do so using the familiar Android development tools you already know and love.
To support your development, this release focuses on providing the fundamental building blocks across the SDK:
XR Runtime: Provides the essential runtime foundation of the SDK, handling device lifecycles, session creation, and system configurations that enable the API surface.
Jetpack Compose for XR: Create spatial UI layouts that take advantage of Android XR’s spatial capabilities. This library lets you use familiar Compose concepts to create spatial UIs and will be reaching Beta soon.
What's new in Beta?
Direct feedback from the developer previews helped shape these beta releases, introducing several important API refinements to ensure these libraries are ready for production.
Kotlin coroutines support: To better align with Kotlin coroutines, Session.create is now a suspend function.
Terminology and class updates: AnchorEntity has been renamed to AnchorSpace, and both ActivitySpace and AnchorSpace now extend a common SpaceEntity class for more consistent spatial management across scenes.
See the full release notes for each library to check out specific details on naming and API changes.
Get started and provide feedback
To add these dependencies, include the Google Maven repository in your project and add the newest XR libraries to your build.gradle files.
The ecosystem of Android XR devices that power immersive experiences is expanding, ranging from XR headsets to wired XR glasses. There’s never been a better time to start building immersive experiences with the Jetpack XR SDK Beta. Dive in and start building and testing on Samsung Galaxy XR or Android XR Emulator today.
Posted by Nick Butcher, Product Manager, Jetpack Compose
Today, the Jetpack Compose August ‘26 release is stable! This release brings version 1.12 across core Compose modules (see the full BOM mapping), introducing rich visual APIs like Mesh Gradients and Wide Color Gamut (WCG) support, structural layout features like named areas in Grid, seamless integration with Android’s Credential Manager, and significant testing and performance improvements.
To update your project to today’s release, upgrade your Compose BOM version to 2026.08.00:
AGP & Compile SDK: Compose 1.12 updates compileSdk to API 37, requiring a minimum AGP 9.1.1. As a reminder, Compose will always target the latest compileSdk. Learn more about this change here.
Modifier.onFirstVisible() is deprecated: Migrate to Modifier.onVisibilityChanged(), which provides more precise visibility threshold tracking.
Graphics
Mesh Gradients
Compose 1.12 introduces MeshGradientPainter to help you create multi-point, organic color gradients.
For more information and examples, see the documentation.
Wide Color Gamut & HDR Support
Modern displays offer extended color fidelity and higher dynamic range. In Compose 1.12, full pipeline support for Wide Color Gamut (P3) and HDR rendering has been enabled across Compose graphics, paint, and shaders. Colors defined in non-sRGB color spaces (such as Display P3) are preserved through to platform rendering without color clamping. Colors will safely fall back to sRGB if they use an unsupported color space (e.g. CieXyz, CieLab, or Oklab), rely on a color space on an unsupported Android version (e.g Bt2020Hlg on Android 13 and below), or if the app is running on Android 9 (API 28) and below.
Other notable changes:
LayerOutsets was added to GraphicsLayer & Modifier.graphicsLayer, which you can use to increase the visual bounds of the layer beyond its measured size. Apply LayerOutsets to avoid the implicit clipToBounds behavior when the layer is promoted to an offscreen buffer.
Styles
At Google I/O, we shared our early vision for the Compose Styles API—a unified, performant way to style components. Since then, we have continued building the underlying architecture to guarantee strict type safety and predictable correctness, and to support building custom design systems.
To ensure we get this foundational layer correct, the API will remain experimental, and you can expect breaking changes.
Runtime Optimizations
Keyed SideEffect Overload
SideEffect now supports key arguments, which lets you fire one-shot side effects whenever specific keys change. This can lead to better performance compared to using a LaunchedEffect or DisposableEffect when you don’t need the coroutine or dispose block. SideEffect is up to 90% faster than LaunchedEffect and around 20% faster than DisposableEffect. Note that SideEffect runs its effect before DisposableEffect and LaunchedEffect, so use caution if migrating existing effects to this API, especially for LaunchedEffects that rely on being dispatched to start after the current frame is completed.
Manual animation control: During a transition's deferred phase, animated properties (like scale or offset) can now be manually manipulated in real-time (e.g., tracking a swipe gesture).
Seamless handoff: Once the deferred phase ends, the transition engine takes over and performs a seamless handoff, including velocity transfer, to the automatic transition.
Shared element support: A new permitTransformDuringDeferredTransition flag in SharedContentConfig controls whether shared elements visually transform along with their parent containers during the deferred transition phase.
val state = remember { DeferredTransitionState(initialScreen) }
val transition = rememberDeferredTransition(state)
if (predictiveBackInProgress) {
state.defer(targetScreen)
} else {
state.animateTo(targetScreen)
}
transition.DeferredAnimatedContent(
targetState = targetScreen,
mutableTransformSpec = {
MutableContentTransform {
// Manually manipulate properties during the deferred phase
initialContentTransform { scale = swipeProgress }
}
}
) { screen ->
ScreenContent(screen)
}
Below are two demos of use cases where a gesture-driven animation is handed off to a triggered animation:
Text, Input & Platform Integrations
Editable Text Formatting
New APIs offer rich-text formatting for editable text in BasicTextField. You can now programmatically apply and manipulate inline character and paragraph formatting using SpanStyle and ParagraphStyle via the new addStyle() method inside a TextFieldBuffer scope (such as inside textFieldState.edit { ... } or an InputTransformation). Additionally, TextFieldBuffer provides getSpanStyles() and getParagraphStyles() APIs that return TrackedRange objects, allowing you to read, update, or remove applied styles. To complement formatting creation, TextFieldState now exposes a read-only textStyles property for querying active styles across ranges, while TextFieldBuffer provides originalTextStyles to inspect formatting state prior to an edit. Text formatting and custom annotations are persisted across configuration changes.
val state = rememberTextFieldState("Formatted text in Compose 1.12")
// Apply bold and color styles to a range of text
state.edit {
addStyle(
SpanStyle(fontWeight = FontWeight.Bold, color = Color.Blue),
start = 0,
end = 9
)
}
// Query active styles from TextFieldState
val currentStyles = state.textStyles
Text Selection
A new SelectionState API provides programmatic control and observability over text selection within a SelectionContainer. Hoisting a SelectionState object via rememberSelectionState() and passing into SelectionContainer exposes selectedTexts as a reactive list of AnnotatedStrings and provides methods like selectAll(), clear(), select(TextRange), and extendSelectionByWord().
Additionally, use getSelectableTexts() to retrieve all selectable text items in layout order and select text across composables in the SelectionContainer using a global range.
@Composable
fun ProgrammaticSelectionExample() {
val selectionState = rememberSelectionState()
Column {
Button(
onClick = { selectionState.selectAll() },
modifier = Modifier.disableSelectionClearOnTap()
) {
Text("Select All")
}
SelectionContainer(state = selectionState) {
Text("Text content to be selected programmatically.")
}
}
}
Credential Manager Integration
Compose text fields now natively integrate with Android’s Credential Manager (API 34+) via the Autofill framework (below API 34 is handled by androidx.credentialslibrary). By attaching the new credentialRequest semantics property with CredentialRequestData, text inputs can prompt passkeys, saved credentials, or sign-in requests directly within the user input flow.
Enabled auto-scrolling when dragging text selection beyond the viewport in SelectionContainer.
Added support for automatic interaction sounds (clicks and focus navigation) to Compose components, with a new SoundEffectOnInteraction composable to allow opt-out. Note that as a consequence of this change, semantics click listeners must now be called from the main thread, which may affect a small number of test cases.
KeyboardType now includes Date, Time, DateTime, and SignedDecimal.
BasicSecureTextField now uses TextObfuscationMode.System by default, while RevealLastTyped serves as an absolute override.
Layout Enhancements
Named Areas in Grid Layout
Building complex 2D layouts is now easier with named areas in the @ExperimentalGrid component. Rather than managing numeric column and row indices across items, you can define semantic regions in your GridConfigurationScope and position composables by area name.
As with every release, we continue to invest in Compose's performance to ensure that the framework helps you to build beautiful, performant apps. In this release we've focused on improving startup performance and are now seeing Time to Initial Display (the time it takes for an app to produce its first frame) that is comparable to Views in our benchmarks.
Testing & Tooling Upgrades
Test Synchronization
Compose 1.12 introduces new test APIs designed to reduce test execution times and eliminate flakiness during state sampling:
hasPendingWork: Passively checks if the UI has pending work without advancing the clock, which is ideal for manual animation loops.
runWithoutImplicitWait: Temporarily disables implicit synchronization when stepping through manual clock frames (e.g. animation tests).
@Test
fun testAnimationStateFast() {
composeTestRule.mainClock.autoAdvance = false
while (composeTestRule.hasPendingWork()) {
composeTestRule.mainClock.advanceTimeByFrame()
composeTestRule.waitForIdle()
composeTestRule.runOnUiThread {
composeTestRule.runWithoutImplicitWait {
// This is most effective when querying multiple nodes in a single frame.
// It prevents the redundant synchronization overhead that would
// otherwise occur on every individual query.
val box1 = composeTestRule.onNodeWithTag("Box1").fetchSemanticsNode()
val box2 = composeTestRule.onNodeWithTag("Box2").fetchSemanticsNode()
assertThat(box1.boundsInRoot.right).isAtMost(box2.boundsInRoot.left)
}
}
}
}
Other notable changes:
The captureToImage API now allows you to capture a popup or dialog together with its anchor in a single bitmap.
Added onRootWithViewInteraction to scope Compose semantic searches to specific Android Views. This simplifies testing hybrid UIs, such as RecyclerViews, without requiring unique test tags in production code.
@PreviewWrapper annotations can now be applied to custom @MultiPreview classes, enabling reusable preview setups (such as custom themes) across multiple components.
Happy Composing!
Compose 1.12 makes app development easier and more expressive than ever, with mesh gradients, wide color gamut support, downloadable variable fonts, Credential Manager integration, and faster testing tools. As always, we value your input, so please share your feedback on these changes or what you'd like to see next on our issue tracker. Happy composing!
Posted by Rebecca Franks, Developer Relations Engineer, Nick Butcher, Product Manager, Loryn Hairston, Product Marketing Manager, Android
Today, we officially celebrate five years since the release of Jetpack Compose 1.0. From version 1.0, announced on July 28th, 2021, to our latest 1.11 release, we’ve seen the APIs evolve significantly over the years, and we’re taking a moment to celebrate.
When we officially announced the 1.0 release, we promised a simpler, faster, and more intuitive way to build native interfaces on Android. Looking back, it's safe to say that Compose didn’t just deliver on that promise, but also completely changed the Android ecosystem, with more than 68% of the top 1,000 apps using it in production today.
History
Over the last five years, Compose has grown steadily. In the early days, we explored showing you how to build layouts with the basic Box, Row, and Column. Today, we’ve expanded Compose to work not just on mobile devices, but to other form factors such as Compose for TV, WearOS, Glance for Widgets, and even display glasses with Jetpack Compose Glimmer.
We recorded an Android Developers Backstage episode with Clara Bayarri, Engineering Lead for Jetpack, and two former leads of the team, Romain Guy and Chet Haase, along with Tor Norbye, Senior Engineering Director. In this episode, they discuss the history of Compose and the early days of development.
Compose highlights over the years
Looking back
The beginnings of Compose were very different from what you know today. Two projects were happening in parallel inside the Android team.
At the time, the Views toolkit team was thinking of unbundling the UI Toolkit into a library to help with development speed, and make it easier for developers to adopt and control updates. Meanwhile, a team was working on a novel idea to build declarative layouts by embedding XML inside Kotlin, which looked something like this:
Those two efforts merged to produce what you know today - a fully declarative UI Toolkit that utilizes the power of a compiler plugin, runtime, and Kotlin:
@Composable
fun Newsfeed(stories: List<Story>) {
LazyColumn {
items(stories) { story ->
Card {
val author = story.author
Image(painterResource(author.profilePhoto),
contentDescription = author.name)
Text(author.name)
Text(story.content)
if (story.hasCommentsEnabled()) {
for(comment in story.comments) {
Text(comment.mainContent)
}
}
}
}
}
}
And you, the community, helped us very early on! Before 2021, Compose had a pre-alpha phase, which helped ensure Compose was fit to solve the problems of our developers.
One of our favorite memories is the Android Dev Challenge. We challenged the community to build four different tasks with Compose, filling our feeds with Puppy apps, clocks, and weather apps, and giving us a ton of direct feedback that helped shape the 1.0 release.
Compose has continued to evolve, from launching with a set of Material 2 components to now supporting Material 3 Expressive.
Material 2 in Compose
Material 3 Expressive in Compose
Looking ahead
As of today, Compose 1.11 is the latest version with 1.12 coming soon, offering so much more than 1.0, 5 years ago. This year, we introduced more adaptive APIs, such as FlexBox, Grid, MediaQuery, and Styles. These APIs let you advance to the next level of premium, adaptive UI development with Compose.
At Google I/O 2026, we announced that we are now Compose-first, meaning that all future UI development will happen only in Compose, while the Views toolkit enters maintenance mode. Material Design is also shifting focus entirely to Compose, signaling an end to the findViewById era.
Community is at the heart of Compose
Over the years, you’ve inspired us with creative examples of how you’ve used Compose, and we’d love to highlight a few more examples of where we’ve seen exciting work. JetBrains has been a great partner for Google with Compose, expanding Compose to work across platforms with Compose Multiplatform and enabling desktop, iOS, and web developers to also enjoy the benefits of Compose.
We’ve really enjoyed following our most beloved newsletters from JetpackCompose.app’s Dispatch, AndroidWeekly, to jetc - helping Android Developers stay up-to-date with the latest in the world of Compose and Android.
Another standout contributor is sinasamaki. They’ve created many delightful experiences using Compose, such as this fun ribbon modifier and the glitchy effect:
Saket Narayan has also always been an inspiration when it comes to creating useful tools for Compose, such as telephoto, a library featuring support for pan and zoom gestures and automatic sub-sampling of large images, or the latest library, Touch Robot, which allows you to easily test interaction animations:
paparazzi.gif(end = 3_000) {
DebitCard(
Modifier.testTag("card")
)
val touchRobot = rememberTouchRobot()
LaunchedEffect(Unit) {
touchRobot.onNode(hasTestTag("card")).performGesture {
draw(
path = createAndroidHeadPath(),
duration = 3.seconds,
)
}
}
}
/** A path drawing the Android head. */
fun createAndroidHeadPath(bounds: Rect): Path = TODO()
Jake Wharton, who has used Compose in innovative ways (like molecule, and even building UI with Compose for the terminal with mosaic). Chris Banes, who has built many Compose libraries over the years, with our most recent favourite - Haze for background blurring, and many of the Android Google Developer Experts like Akshay Chordiya, Huyen Tue Dao, and Katie Barnett, who’ve contributed to the success of Compose. But this is not about selecting individuals - there have been so many great contributors to the Compose codebase, and many of you continue to inspire us with your fun examples, libraries, and in-depth talks. Without the community, Jetpack Compose wouldn’t be as successful as it is today.
Cheers to the next 5 years, and more!
Jetpack Compose has grown from an experimental idea into the standard for Android UI Development. Thank you to the entire Toolkit team at Google, and to the incredible global developer community that wrote libraries, filed bugs, and pushed the boundaries of what declarative UI can do.
This week, we’ll be celebrating with some in-person birthday parties across the globe, and a live “Birthday party” on the Android Developers YouTube channel on July 30th at 13:00 UTC. During this time, we’ll hang out and discuss Compose and answer your questions!
Posted by Paul Feng, VP of Product Management, Google Play
Providing a safe online experience and protecting users from harm is a top priority at Google Play. We take this responsibility seriously and have been investing continuously to offer baseline protections on our platform while also empowering parents with the tools they need to make decisions for their families. Importantly, we also want to empower Play developers with the capabilities to deliver age-appropriate experiences based on their app's content.
To support this, today, we are taking another big step in our ongoing partnership with parents and developers by announcing the expansion of the Google Play Age Signals API to all Play developers globally. Building on current availability in Brazil, we will expand this experience first to users in Australia and Canada by mid-August, with a full global rollout to all users later this year.
Empowering developers to create age-appropriate experiences
The Play Age Signals API is a privacy-preserving tool that puts parents in the driver's seat allowing them to share their child's age range (e.g. 16-17) directly with apps. It also enables adults to easily share their age when prompted by the app developer. In turn, developers receive the signals they need to tailor their own in-app safety experiences and content for users in an age-appropriate way.
We want to give developers the ability to choose the right protections for the nature of their app. A weather app, for example, shouldn't need the same safety settings as entertainment or media apps. Rather than enforcing one-size-fits-all rules, we give developers the flexibility to choose how they integrate safety signals. With this reliable signal, you retain complete agency to tailor your app's content, features, and settings to match your audience.
Users have a choice to share their age range in a privacy-friendly way
Simplifying controls for parents
Parents shouldn't have to manage complex safety settings across dozens of different apps to keep their children safe. The Play Age Signals API simplifies this by putting age-sharing controls in one place, directly inside the Google Family Link app. Parents have a choice to share their child’s age range, and if they choose to share, all Play apps that use Play Age Signals API can receive age signals. This lets children jump straight into age-appropriate content without parents having to manually configure settings inside these apps. Age ranges are never shared by default, and parents can update or turn off these settings at any time.
Centralized and easy way to manage age sharing settings for parents via Family Link App
Building on our broader safety tools
The Play Age Signals API builds upon a strong foundation of established safety features and strict policies we have long enforced on Google Play. Today, we already mandate that apps designed for families meet rigorous safety standards, and we continuously review and scan applications to ensure they are safe for children. For developers, we also offer built-in tools like Restrict Minor Access in the Play Console to help them manage who can discover their apps. For parents, Google Family Link remains a trusted, central dashboard where they can manage screen-time limits, PIN-based content filters, and app download approvals.
Expanding the Play Age Signals API globally adds a powerful new tool to our existing safety suite, helping parents and developers work together to make Google Play an even safer, more trustworthy place for families.
Posted by Jose Alcérreca, Developer Relations Engineer, Android Developer Relations
We released the official Android Skills in April, and the response surpassed all our expectations. In this blog post, I'll address some of the feedback we received, explaining the philosophy and methodology behind the project. Hopefully, this will also help you understand what happens behind the scenes when you install and use skills, allowing you to make better use of tokens and your own time.
Why are there so few official skills?
Currently, we only consider new skills when there's a verifiable knowledge gap in state-of-the-art (SOTA) models. Put simply: you don't need to teach the model what it already knows. (Though there are a few exceptions—read on!)
We’ve released around 20 official skills so far, and they intentionally target highly specific, fast-moving areas that standard models aren't fully grounded on yet—things like AGP 9, Navigation 3, advanced Camera APIs, and Perfetto SQL.
What about core, more general, skills? Every installed skill injects 100–200 tokens into the baseline context of every task you start. If that skill actually activates, that count can quickly jump into the thousands. In most cases, hoarding basic skills is both counterproductive and expensive. Before installing a skill for writing basic Kotlin or Compose, consider if your LLM of choice really needs it, or if it knows those topics well enough already.
Evaluating skills
Before their release, each skill is tested against a comprehensive set of evals that prove that the skill delivers clear value. These evals should pass when the skill is active, and fail otherwise. Evals are to skills what integration tests are to code.
timeout_s: 1200
repository:
url: [redacted - internal git repo]
working_dir: wear_compose_m3_empty_app
category_ids:
- wear
prompt: |-
Add a horizontal pager to MainActivity.kt. Have three pages in the pager. Each page should contain
the text "Page 1", "Page 2", and "Page 3" respectively in the center of the screen.
commands:
build:
- ./gradlew assembleDebug
acceptance_criteria:
project_builds: true
llm_diff_judge:
- Must use `HorizontalPagerScaffold`.
- Each page should use `AnimatedPage` to wrap a `ScreenScaffold`.
Example eval that checks the correct implementation of a horizontal pager on a wear app
At a minimum, we test the skill in Android Studio using the latest Gemini Flash model. Depending on the skill, we also ensure compatibility with other models such as Gemini Pro and other agents such as Antigravity, and third-party systems.
All of the evals run with access to the Knowledge Base, so if the information is in the documentation, and models decide to search for it, we don't publish a skill for it.
Using the Android Knowledge Base (Android Studio or Android CLI)
If you develop Android apps, you should always use the Android Knowledge Base to have access to the official documentation. If you use the agent in Android Studio, it's already available as a tool, but if you use another agent, install Android CLI. Among other things, it contains the docs command, which gives your agent access to the official Android documentation. Having a single tool is much more efficient than installing hundreds of skills.
If your model is acting overconfident, and you want it to consult the documentation more often, a very common way to motivate it is to add "Always consult the official Android documentation when dealing with Android APIs" to your AGENTS.md file or equivalent. Of course, you can also force this by asking the agent to check the documentation directly in your prompts.
Why are pull requests disabled?
Because our evaluation framework depends on internal infrastructure that cannot be open-sourced, we are unable to accept direct pull requests for new skills—without this infrastructure, we would have no way to re-evaluate incoming PR changes. However, we actively monitor community feedback. If you want to report a bug, suggest an optimization, or request a new official skill, please file an issue!
When do core or basic skills make sense?
While SOTA models generally don't need basic skills, there are some scenarios where enabling core or community-built skills adds real value. For example:
You're using vague prompts: Skills amplify your intent. If you give a loose prompt like "add animations to this screen," a specific Compose animation skill can inspire the model, pushing it toward modern APIs or screenshot testing patterns it might not have otherwise considered.
You want to use smaller, cheaper models: Frontier LLMs are expensive. If you are offloading routine tasks to smaller open-weight models like Gemma 4, enabling basic skills fills the knowledge gaps that smaller parameters miss.
You're refactoring or reviewing legacy code: Models excel at generating code that works, but when editing old codebases, they often prioritize staying consistent with the surrounding legacy patterns over rewriting things with modern accuracy. A specialized reviewer agent equipped with core skills can help break that habit.
You deviate from the norm: LLMs love the standard "Google way" of architecting Android apps. If your team uses a highly customized view-layer architecture, the model will struggle to stay aligned. A custom skill explicitly describing your architecture goes a long way.
Always download skills from reputable sources! I personally wouldn't trust repositories containing dozens or hundreds of Android skills as they're probably AI-generated and untested, and they could even contain malicious or biased instructions. Also, don't install general software engineering skills blindly; a lot of them are tailored for web development.
Goal: deprecation
Loosely paraphrasing Karpathy: Skills of today will be in the models of tomorrow. As SOTA models keep improving, we expect skills to be obsolete, especially those built around new APIs. To figure out when to retire them, we run our evals when new models drop. If they pass, we'll keep them around for a few months until most users have transitioned over.
Posted by Fahd Imtiaz, Senior Product Manager, Loryn Hairston, Product Marketing Manager, and Tracy Agyemang, Product Marketing Manager, Android Developer
Made by Google expands what's possible across the Android ecosystem. With the introduction of the Pixel 11 Pro Fold, Pixel Watch 5, and the entire Pixel family, users are moving seamlessly across diverse screen sizes, unique postures, and intelligent experiences. For you, the developer, this represents a massive opportunity: foldable users spend about 14x more than standard phone users. To help you elevate your existing experience without starting from scratch, we’re sharing our latest platform guidance alongside real-world examples from developers already putting these features into production.
Deliver adaptive experiences across foldables and expanded displays
The Pixel 11 Pro Fold gives your app a chance to flex its capabilities with an expanded inner display and a standard size outer screen. Building for the foldable form factor requires dropping hardcoded layout rules and designing around available window space. Leveraging Jetpack Compose APIs like Navigation 3 with Scene strategies or our newest layout APIs like Grid and FlexBox allows your layout containers to automatically wrap, span, and reflow. You can also use the experimental MediaQuery API to dynamically adapt your UI to environmental signals like foldable posture, and keyboard states.
Building adaptively requires tracking actual app dimensions rather than physical device size, especially during split-screen and multitasking flows. Using Window Size Classes from the WindowManager library allows your layout to respect folds and hinges as natural content separators.
For instance, Notability leveraged Material 3 Window Size Classes to create a responsive two-pane layout that transitions smoothly between folded and expanded screens. As Ryan Shea, Android Engineering Manager at Notability, shared, tracking the window itself allows their layout and canvas zoom to ensure notes stay fit to the page through every fold, rotation, or split-screen resize, noting that they wanted the app "to feel native at every size, not just stretched to fit."
Notability’s quiz UI adapted for expanded screens
Ensuring these transitions feel seamless also requires state preservation across configuration changes. Using ViewModel retains UI state so interactions like scroll position, form inputs, and open dialogs remain uninterrupted when transitioning between inner and outer screens.
Taking this approach, Flo Health used Jetpack Compose state primitives, ViewModel, and Window Size Classes to make their highest-traffic user journeys resilient to rotation, fold/unfold and resizing transitions. As Aleksandr Kolodiazhnyi, Senior Android Engineer at Flo Health, shared, “Android's adaptive guidance turned what looked like a major refactor into a templated rollout," allowing them to adopt Compose primitives without a rewrite, "cutting [their] state-preservation code by roughly 30% while fixing lifecycle and analytics correctness issues that improved the app on every form factor."
To take full advantage of the foldable form factor, leverage FoldingFeature updates to trigger posture-specific layouts. When a user partially folds their device into tabletop posture, you can split your UI automatically by placing primary controls on the lower display and main content or viewfinders on the upper display.
Handling camera previews across foldable state changes, requires managing orientation shifts carefully. Migrating to the CameraX library ensures automatic handling of sensor rotation and display scaling across screens, while existing Camera2 codebases can also achieve stability using the CameraViewfinder library. These camera and display capabilities allow you to power dual-screen previewing and high-resolution rear camera selfies with minimal custom logic.
Prepare your app for these form factors today by exploring our complete adaptive development guidance at Build adaptive apps.
Bring delightful, gesture-driven experiences to the wrist
The new Pixel Watch 5 is here, and we’ve optimized it to take advantage of the intelligent, power-efficient, touch-free convenience of Wear OS 7. Thanks to system-wide performance optimizations and a collection of new features built to help users complete tasks efficiently, you can provide rich experiences that require only a single user action to complete.
The one-handed gestures framework provides a convenient way for users to interact with their watches without needing to touch the screen with their opposite hand. Starting with the 1.7 beta release of Compose for Wear OS 7, you can seamlessly integrate one-handed gesture control into your Wear Compose apps with simple physical inputs on the watch-wearing arm, like a double-pinch or wrist turn.
Spotify is adopting this framework to make controlling media more effortless. By mapping Wear OS gesture events directly to the media player state, users will be able to pause or resume playback using a simple double-pinch, keeping music controls accessible even when their hands are full.
Pause Spotify media with a pinch gesture
Wear OS 7 also brings Live Updates directly to the wrist to surface real-time information like live sports scores, workout progress, and delivery status, which can also appear in the At-a-Glance surface on Pixel Watch 5. For example, Just Eat uses Live Updates to keep users informed on order arrival times at a glance. You can publish updates locally from your watch app or leverage phone notification bridging on supported devices to deliver real-time tracking across screens.
Live Updates from Just Eat delivering real-time status and delivery ETAs at a glance
You can also extend glanceable interactions across watch surfaces on Wear OS 7 by using Wear Widgets, powered by Jetpack Glance and RemoteCompose. Wear Widgets with Compose offer greater expressiveness and consistency than the old Tiles framework, and the two available widget layouts—small and large– align perfectly with the 2x1 and 2x2 formats on mobile, ensuring your designs feel cohesive across devices.
On top of all these great new features, Wear OS 7 delivers up to a 10 percent improvement in battery life over Wear OS 6, making the Pixel Watch 5 a truly indispensable all-day companion for your users.
Pixel 11 devices are built to run Gemini Nano 4, bringing fast, responsive, on-device intelligence to the hardware. By running AI workflows directly on device, you can offer low-latency, real-time interactions that feel instant and integrated without needing round trips to the cloud.
Through the ML Kit GenAI Prompt API, you can send natural language requests directly to Gemini Nano on device. The model supports over 140 languages, better multimodal understanding, and much more. Build intelligent on-device features using advanced capabilities like structured output and thinking mode.
Build smart capabilities into your app using our self-service tools and Gemini models.
Shape the next generation of experiences for the Pixel ecosystem today
Made by Google showcases what's possible when hardware and software evolve together, and you are at the center of that innovation. You can begin optimizing your apps today by exploring our updated adaptive guidance, creating glanceable experiences for Wear OS 7, and integrating on-device AI with ML Kit.
To help you implement these updates even faster, you can now leverage Android skills, which provide AI-optimized instructions for agents and tools. Whether you are using Gemini in Android Studio or running the Android CLI through other agents, Android skills give your AI tools the context needed to execute complex workflows automatically. For instance, you can prompt your agent with the CameraX skill to handle camera display scaling across foldables, or use the Adaptive skill to set up dynamic Compose layouts without additional manual work.
Take advantage of these new surfaces, accelerate your workflow with agentic tools, and share your latest builds with the Android community! Head over to developer.android.com to access full documentation, explore the Android skills GitHub repository, and start building today.
Posted by Toni Heidenreich, Software Engineer, Android
Media3 1.11 is out. Powering the vast majority of top Android media apps, this release brings new features, bug fixes, and improvements across playback, editing, and UI components. We're expanding our Jetpack Compose UI modules with customizable Player slots and easy to use defaults, interactive gestures, state observers, and short-form video preloading using PlayerPool. We also modernized the Media3 Cast integration with SystemUI Output Switcher support, introduced a new Ktor HTTP client network extension, and added new muxing utilities for Ogg and WAV files.
Read on for key highlights, and check out the full release notes for a comprehensive list of changes.
Playback UI and Compose
With Android becoming Compose-first, we are continuing to expand the media3-ui-compose and media3-ui-compose-material3 modules. This update introduces more granular control over your player layout, richer interaction patterns, and deeper integration with Material3.
Customizable Player layout
The Material 3 Player Composable now supports dedicated content slots for topControls, centerControls, bottomControls, and errorOverlay. You can drop in your own Composables or use the ready-made defaults published in PlayerDefaults:
The Player Composable also integrates FocusRequester support, enabling seamless D-pad and keyboard navigation on Android TV, foldables, and desktop environments.
Example for a Composable Player with customized controls
Gestures and playback speed control
PlaybackSpeedState now provides a fast-forward/slow-motion API. The demo-compose app showcases this with a long-press gesture to fast-forward playback and seeking with double tap. Combined with the ProgressSlider introduced in 1.10, the Compose player UI now offers rich touch and gesture interactions out of the box.
Short-form video preloading with PlayerPool
For apps with sliding-window media feeds (for example, short-form vertical video), managing multiple ExoPlayer instances efficiently is a common challenge. Media3 1.11 introduces PlayerPool (in common-ktx) and rememberPooledPlayer (in ui-compose) to handle player recycling and preloading automatically.
The new ShortFormPlayerScreen in demo-compose shows this in action, a vertically paging feed where players are pooled, preloaded, and seamlessly recycled as the user scrolls.
MiniController
A new MiniController Composable in media3-ui-compose-material3 provides a compact playback bar displaying the current item's title, artist, artwork, and progress alongside play/pause controls. As all our default Composables in media3-ui-compose-material3, the MiniController supports Material3 Dynamic Color integration, allowing it to automatically adapt to the user's wallpaper theme.This is ideal for persistent bottom-sheet or mini-player affordances, for example while the user browses content or during active Cast sessions.
The Media3 MiniController showing album art, media metadata and basic controls
Expanded state holders for metadata and errors
We added several new reactive state holders to media3-ui-compose:
rememberCurrentMediaItemState – observe metadata about the currently playing item
rememberPlaylistState – observe the full playlist and active indices
rememberErrorState – track playback errors, with a matching ErrorText Composable and default ErrorOverlay in Material3
We'll continue working on new additions and more customization options in upcoming releases. Please share your thoughts on the project issue tracker.
Modernized Cast integration
Media3 1.11 updates the Cast extension with programmatic configuration options and support for OS-level routing.
CastParams and SystemUI Output Switcher
You can now configure the Cast extension using CastParams:
val castParams = CastParams.Builder()
.setShowSystemOutputSwitcherOnCastButtonClick(true)
.build()
Cast.getSingletonInstance(context).initialize(castParams)
Setting setShowSystemOutputSwitcherOnCastIconClick(true) configures the MediaRouteButton to open Android's native SystemUI Output Switcher on supported platform versions, providing a unified output picker experience.
Reactive MediaRouteButton state in Compose
Apps using Jetpack Compose can now easily add the Media routing button (also known as Cast button), which automatically observes the dialog state and updates accordingly. No further logic needed when used together with Media3's CastPlayer!
Media3 media route button in an app launching the default output switcher dialog
Core playback and session enhancements
Eclipsa Video - HAGC dynamic HDR metadata (API 37+)
Eclipsa Video promises a more consistent HDR experience across devices, with a consistent baseline HDR white, adaptive headroom depending on the screen and the surroundings, ensuring the creative intent is preserved on all devices.
ExoPlayer now supports playback of the necessary HAGC (ST 2094-50) timed metadata for progressive media (MP4, Matroska). The player automatically merges HAGC metadata tracks with the associated video track and delivers the metadata out-of-band to the decoder on API 37+ devices. On older devices, ExoPlayer seamlessly falls back to providing a standard HDR playback experience without the adjustments.
Illustration to show benefits of Eclipsa Video HDR, like more consistent color contract
New Ktor HTTP client extension
A new media3-datasource-ktor extension module provides KtorDataSource, backed by the Ktor HTTP stack. This offers a Kotlin-first, coroutine-friendly alternative to the existing Cronet and OkHttp data source modules.
Asynchronous MediaSession connections
MediaSession.Callback now includes onConnectAsync(), which lets you process controller connection attempts asynchronously — for example, to verify authorization before accepting a connection. You can return an immediate Future with Futures.immediateFuture(ConnectionResult) for the same behavior as the existing onConnect.
For apps that don’t override onConnect or onConnectAsync in MediaSession.Callback, the library now defaults to a more secure configuration. Specifically, session data is no longer shared by default with untrusted controllers, meaning third-party or non-system apps lacking notification access are restricted from accessing session data unless you explicitly implement these callback methods to authorize the connection.
New Muxer implementations & container parsing
OggMuxer and WavMuxer
We've added two new dedicated muxers: OggMuxer for muxing OPUS and VORBIS streams into standard .ogg files, and WavMuxer for generating uncompressed and floating-point PCM .wav audio files.
Container parsing and track references
MP4 Track References (tref): Mp4Muxer.addTrackReference allows linking dependent metadata or aux tracks to primary video streams.
Chapter Extraction: QuickTime and Nero chapter from MP4 files (.m4a, .m4b), and Matroska chapters, are now extracted as Chapter metadata entries for audiobook and podcast navigation.
Please use the issue tracker to report any bugs, or if you have questions or feature requests. We look forward to hearing from you!
Posted by Chiara Chiappini, Developer Relation Engineer, Android Developer Relations
One-handed gestures offer a convenient and touch-free way for users to interact with their watches, enabling them to perform key actions using only the hand on which the device is worn.
First introduced on Pixel Watch with Wear OS 6.1, one-handed gestures made quick interactions effortless, such as starting and stopping a timer, accepting calls, and controlling media.
Now, with Wear OS 7, we're expanding this functionality with a new Gestures framework that allows OEMs to map gestures to primary actions and dismissals, and an API to bring gesture control to the developer community.
Starting with the 1.7 beta release of Compose for Wear OS, you can seamlessly integrate gesture control into your Wear Compose apps. To use this release, upgrade your Wear Compose dependency to:
The one-handed gestures framework is designed around two primary interaction patterns that allow users to take action without touching the screen:
Primary action, which on Pixel Watch is mapped to a double-pinch gesture: this action should be mapped to the most important task in a given context. For example, users can perform this gesture to take a photo in a camera app, start/stop a timer, or accept an incoming call.
Dismiss action, which on Pixel Watch is mapped to a wrist turn gesture: this action is mapped to system back by default and provides an intuitive way to close interruptive screens or get back to the watch face. It may be overridden for specific use cases, such as silencing an incoming phone call.
These gestures are currently available on Pixel Watch 3 and newer, and the Wear OS gesture framework is available to all Wear OS device manufactures to adopt.
Check out our new design guidance for integrating one-handed gestures into your Wear app.
Integrating gestures with Compose on Wear OS
To provide seamless gesture support in Wear OS 7, we are introducing a new Modifier.oneHandedGesture that you can apply to any existing interactive composable to make it gesture-aware.
Implementing gestures with Compose on Wear OS requires these steps:
Define the gesture configuration. Start by using rememberOneHandedGestureConfiguration to define the nature of the interaction. This configuration dictates the basic behavior by providing the GestureAction (e.g. tracking a primary pinch or a dismiss wrist flick).
Initialize the indicator state. Depending on your UI component, initialize a specific state object, such as OneHandedGestureClickIndicatorState for buttons or OneHandedGestureScrollIndicatorState for scrollable lists. This state is used to coordinate visual feedback between the gesture detection modifier and the visual UI indicators, seamlessly managing visibility, timing, and animations.
Apply Modifier.oneHandedGesture to your interactive component. You'll pass in your configuration and state, and you’ll provide standard callbacks: onGestureAvailable to activate the visual hint when the system prepares the gesture, and onGesture to execute your action when the gesture happens.
The following sample shows how those three steps translate into code when configuring an IconButton:
val gestureConfig = rememberOneHandedGestureConfiguration(action = OneHandedGestureAction.Primary)
val indicatorState = remember { OneHandedGestureClickIndicatorState() }
val coroutineScope = rememberCoroutineScope()
OutlinedIconButton(
onClick = onPlayPauseButtonClicked,
modifier = Modifier.touchTargetAwareSize(IconButtonDefaults.LargeButtonSize)
.oneHandedGesture(
gestureConfiguration = gestureConfig,
interactionSource = interactionSource,
onGestureLabel = "play or pause",
onGestureAvailable = {
coroutineScope.launch { indicatorState.showIndicator() }
},
onGesture = onPlayPauseButtonClicked,
),
) {
// button content goes here
// See "Guided discovery with gesture indicators" section of this post for recommendations on adding a gesture indicator.
}
The GestureAction.Primary can also be used to scroll when the content is the end goal of the user journey, or there is a gesture actionable button off screen that the user can scroll to. Some examples include:
Scrolling through a notification to view the content and/or initiate a reply (available in TransformingLazyColumn and ScalingLazyColumn).
Paging through workout metrics or other content that doesn’t require the user to tap to continue the user journey (available in HorizontalPager and VerticalPager).
val scrollGestureConfig = rememberOneHandedGestureConfiguration(action = GestureAction.Primary)
val scrollIndicatorState = remember { OneHandedGestureScrollIndicatorState() }
val coroutineScope = rememberCoroutineScope()
TransformingLazyColumn(
state = scrollState,
contentPadding = contentPadding,
modifier = Modifier
.fillMaxSize()
.oneHandedGesture(
gestureConfiguration = scrollGestureConfig,
onGestureLabel = "scroll",
onGestureAvailable = {
coroutineScope.launch { scrollIndicatorState.showIndicator() }
},
onGesture = { OneHandedGestureDefaults.scrollDown(scrollState) }
)
) {
// list content goes here
// See "Guided discovery with gesture indicators" section of this post for recommendations on adding a gesture indicator.
}
Guided discovery with gesture indicators
To help users learn which gestures are available, gesture indicators work as hints to help discovery about which gestures are available on a screen.
These hints provide animated cues that inform users where they can perform a gesture. The framework manages the cadence and appearance of these hints, ensuring that they are helpful without being intrusive. System settings let users change the cadence to something less frequent if desired.
To integrate with hints, the API provides the following gesture indicator components:
The following example shows how to use the OneHandedGestureClickIndicator for a Button. See another example for using the OneHandedGestureScrollIndicator in our guidance.
Sample app showing gesture hint for media controls
We are already seeing early adoption of these APIs from partners like Spotify, who are using one-handed gestures to make music control more seamless on the go. By adopting the Modifier.oneHandedGesture into their Wear OS app, Spotify allows users to play or pause their music with the primary gesture action, which on Pixel Watch devices is the double-pinch gesture. This action triggers the same behavior as the physical play/pause button, and the user doesn’t need to touch the screen.
.
Spotify app with gesture integration
Bring one-handed gestures to your app
You can begin experimenting with one-handed gestures today in the 1.7 beta release of Compose for Wear OS.
Ensure your app is running on Wear OS 7, which provides the underlying platform support for gesture detection. Check out our new one-handed gestures developer guide to see how you can start building more convenient experiences for your users.
Posted by Ajesh R Pai, Developer Relations Engineer, Ulises Uriel Verduzco Diaz, Software Engineer, Tinder, and Tracy Agyemang, Product Marketing Manager
Tinder is on a mission to power and inspire real connections by making meeting easy and fun for every new generation of singles. However, as their Android application codebase grew in size, so did its complexity. Prior to their latest optimization efforts, approximately 70% of the application was not optimized, carrying 17 dex files,including three dedicated just to startup. Although they had enabled R8, much of its optimization potential was blocked due to keep rules, and the team was unable to identify which specific rules were preventing optimization. To reduce startup time and decrease user-perceived Application Not Responding (ANR) errors, Tinder turned to the new R8 Configuration Analyzer to tackle these challenges.
By utilizing the R8 Configuration Analyzer, Tinder successfully identified and removed unintentional optimization blockers. The results were immediate and impactful: Tinder achieved a 47% reduction in app cold starts, shrank their app download size by 28.98% (down to 61.5 MB), and reduced user-perceived ANRs by 28%.
Configuration analyzer
The R8 Configuration Analyzer shows R8 optimization by tracking shrinking, optimization, and obfuscation scores to show available refinement areas. It shows the broad, redundant, or obsolete keep rules, including those from external libraries so that you can analyse the keep rule impact and refine the keep rules.
Key metrics shown in Configuration Analyzer include:
Shrinking Score: Code percentage available for R8 shrinking.
Optimization Score: Code percentage open to optimization (for example, method inlining, horizontal class merging).
Obfuscation Score: Percentage of classes, methods and fields that can be renamed by R8 to decrease size.
Use the analyzer to audit keep rules and their impacts:
Find broad rules: Narrow the scope of package-wide rules that restrict R8 optimization, and identify the specific classes, methods, and fields excluded from shrinking, optimization, and obfuscation.
Refine rules: Target only specific classes/methods requiring reflection to unlock optimization
Remove redundant rules: Remove rules that match zero classes, methods, or fields in your current build.
Identical rules: Identical keep rules means rules that target the same classes, fields, and methods or duplicate declarations of keep rule in same or across keep rule files.
Find subsumed rules: Clean up specific rules already covered by broader configurations.
Identify problematic libraries: Check the combined optimization impact of merged consumer keep rules from all libraries.
R8 Configuration Analyzer report of a sample application
To assist you in using the R8 Configuration Analyzer with agentic tools, we have published an R8 Analyzer skill. This skill optimizes automated development workflows by summarizing the R8 Configuration Analyzer report to display key metrics: optimization, obfuscation, and shrinking scores. It also highlights the five most impactful keep rules, giving you clear insight into what blocks code optimization.
Pinpointing hidden optimization blockers
Prior to integrating the R8 Configuration Analyzer, Tinder's Android app suffered from significant technical debt due to a heavily unoptimized codebase. This lack of optimization directly degraded the user experience, leading to users experiencing slow cold starts
To resolve these issues, the Tinder team utilized the R8 Configuration Analyzer to comprehensively audit their R8 configuration. The analyzer showed the R8 optimization of the codebase was around 28% even with R8 full mode. With R8 Configuration Analyzer, Tinder identified that an in-house library was introducing a broad, unscoped keep rule.
# Prevents optimization in all public classes along with all of their public and protected members
-keep public class * {
public protected *;
}
This "wide" rule unintentionally covered various dependencies across the entire app, preventing optimization in a large number of classes. Because the over-inclusive rule prevented runtime crashes, developers frequently missed adding new rules for new features that used reflection, allowing hidden issues to compound over time.
By leveraging the insights provided by the R8 Configuration Analyzer, the team successfully traced and analyzed the specific classes affected by the broad keep rule from the library. The team immediately discovered that optimization was being blocked in larger, non-dynamically invoked classes where R8 could do optimization. Refining this specific keep rule allowed Tinder to unlock substantial optimization capabilities, untangle their legacy configurations, and drastically improve their overall optimization numbers, with R8 scores increasing from 28% to 50%, driving immediate performance gains across the application, and the Tinder team is actively working to further improve this figure.
Faster Loading: The team achieved a 47% reduction on users experiencing slow cold starts of the app.
Smaller Footprint: The App download size went from 86.6MB down to 61.5 MB (28.98% decrease).
Improved Stability: User-perceived Application Not Responding (ANR) errors decreased from 0.35% to 0.28%, bringing them significantly closer to the peer median numbers
Reduced Complexity: The total number of DEX files was cut down from 17 to 11, including just two startup files.
Beyond these technical performance enhancements, the increased application optimization directly translated into tangible business growth and higher user engagement, particularly in resource-constrained markets.
Regional Engagement: Countries where Low RAM devices take a huge portion of the market, presented the largest increase in engagement, and decreasing the ANR rates was key to improving engagement in this vast market.
Engagement Growth: Engagement has increased 3% since the increase in app optimization.
Safeguarding future performance with continuous integration
Addressing code minification isn't just a one-time fix; it requires continuous vigilance. Inspired by the massive gains achieved through the R8 Configuration Analyzer, Tinder’s Android team proactively integrated optimization monitoring into their daily workflow to prevent regressions.
Tinder’s team added a new job in their CI/CD pipeline to report changes in the optimization stats so everyone can see how their contribution is affecting optimization. When advising other developers considering R8 configuration integration, the team emphasizes the importance of auditing internal dependencies. While most popular third-party libraries come with well-defined rules, internal company projects that are considered "stable" might actually be introducing wide rules that negatively impact overall optimization.
Key Takeaways
Faced with a heavily unoptimized codebase and a high volume of DEX files, Tinder needed a way to cleanly audit their app’s minification rules. The R8 Configuration Analyzer provided the ideal tooling necessary to identify overly broad internal library rules, the classes affected by the keep rule, allowing the team to confidently optimize their codebase. As a result, Tinder successfully cut cold starts by nearly half, shrank their APK size by over 28%, and established a healthier, more performant foundation for their users, with the team actively working to further improve these numbers.
How to Use R8 Configuration Analyzer
The R8 Configuration Analyzer and its standalone features can be utilized based on your current Android Gradle Plugin (AGP) version:
AGP 9.3 Release: The R8 Configuration Analyzer is fully integrated and released with AGP 9.3. When running an R8 release build, the report will be generated in the build/outputs/mapping/release/configanalyzer.html folder.
Standalone Gradle Task: AGP 9.3 introduces a standalone Gradle task that allows you to generate the analyzer report without running a full release build, providing a much faster feedback loop when refining keep rules locally:
./gradlew :app:analyzeReleaseR8Config
The report is generated at build/reports/r8/r8-config-analyzer-release.html.
Usage on Older AGP Versions: If you are using a version below AGP 9.3, you do not need to migrate your entire AGP version to analyze your configuration. You can update the R8 version independently to 9.3.7-dev or higher by following the Replacing R8 in AGP instructions. To generate the report locally, run your build with the property specified:
Posted by Blair Harmon, Director of Product Management, Android Platform
A great user experience is central to Android's mission, and delivering on that promise requires keeping devices fast, responsive, and reliable. This is why memory optimization is more critical than ever. Across the ecosystem, new devices are maintaining or even decreasing their physical memory capacity in response to memory price increases, yet users continue to expect the same seamless, high-performance app experience.
In Android 17, we introduced per-app memory limits, starting with Pixel devices, to help protect the overall user experience from applications using excess memory and causing system-wide slowdowns. Over the coming year, an increasing number of manufacturers will leverage the Android per-app memory limits across their portfolio of device RAM configurations from 4GB to 16GB+ devices. If your app exceeds these limits, it will be slowed down and may be terminated. Optimizing your app's memory footprint is essential to preventing OS throttling and maintaining a seamless user experience.
In this post, we’ll explore how these limits work under the hood, how to measure your memory footprint using new Android vitals metrics, and actionable steps to optimize your app or game.
Understanding Memory Limits
When your app exceeds its memory budget, Android takes progressive action to protect device responsiveness:
zRAM Swapping: If your app reaches its allocated limit, the system forces your app's pages into zRAM (compressed RAM). While zRAM prevents immediate eviction, compressing and decompressing pages adds CPU overhead, which can result in noticeable UI jank and experience slowdowns.
Process Termination: If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system. To determine if your app session was impacted by these constraints in the field, you can call getDescription() within ApplicationExitInfo. If the system applied a limit, the exit reason is reported as REASON_OTHER and the description string will contain "MemoryLimiter:AnonSwap". You can also leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached.
You can't optimize what you can't measure. Identifying memory leaks, excessive heap allocations, and Out-Of-Memory (OOM) crashes across the Android ecosystem requires leveraging complementary monitoring tools:
Macro-level health with Android vitals: For broad, population-level visibility without additional overhead, Google Play Console’s Android vitals provides essential metrics like Memory Usage (Anonymous RSS + swap) and Bitmap Memory Usage. This gives you a clear snapshot of memory distribution across different process states (foreground, background, user-perceived services, and cached) and RAM class ranges, helping you spot memory outliers.
Memory Limiter exits & OOM tracking with Firebase Crashlytics: To stay informed about severe memory degradation before it impacts your key metrics, Crashlytics version 20.1.0 introduces additional debug data to help you catch, prioritize, and fix Out-Of-Memory exceptions and memory limiter kills. Tracking these events alongside custom logs and key-value metadata gives you immediate context into process status when a memory failure occurs.
In-field traces with ProfilingManager: For teams able to maintain a performance observability framework, the ProfilingManager API introduced in Android 15 (API level 35) allows your app to programmatically request and collect detailed memory debug artifacts such as Java heap dumps and heap profiles directly from production devices. You can also trigger heap dump captures based on specific system signals, such as TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY.
Read our documentation to learn more about other memory monitoring techniques.
Summary & What's Next
With Android broadening per-app memory limits across all RAM classes, now is the time to audit your memory footprint:
Prioritize memory optimizations: Prevent your app from being impacted by app memory limits by using best practices.
The Android operating system brings the power of computing to everyone. This vision applies to all users, including those on entry-level phones that face real constraints across data, storage, memory, and more. This was especially important for us to get right because, when we first announced Android (Go edition) back in 2017, people using low-end phones accounted for 57% of all device shipments globally (IDC Mobile Phone Tracker).
What is Android (Go edition)?
Android (Go edition) is a mobile operating system built for entry-level smartphones with less RAM. Android (Go edition) runs lighter and saves data, enabling Original Equipment Manufacturers (OEMs) to build affordable, entry-level devices that empower people with possibility. RAM requirements are listed below, and for full Android (Go edition) device capability specifications, see this page on our site.
Year
2018
2019
2020
2021
2022
2023
Release
Android 8
Android 9
Android 10
Android 11
Android 12
Android 13
Min RAM
512MB
512MB
512MB
1GB
1GB
2GB
Android (Go edition) provides an optimized experience for low-RAM devices. By tailoring the configuration and making key trade-offs, we’re able to improve speed and performance for low-end devices and offer a quality phone experience for more than 250M people around the world.
Recent Updates
We are constantly making phones powered by Android (Go edition) more accessible with additional performance optimizations and features designed specifically for new & novice internet users, like translation, app switching, and data saving.
Below are the recent improvements we made for Android 12:
Faster App Launches
Longer Battery Life
Easier App Sharing
More Privacy Control
Why build for Android (Go edition)?
With the fast growing & easily accessible internet, and all the features available at low cost, OEMs and developers are aiming & building their apps specifically for Android (Go edition) devices.
Fast forward to today — over 250 million+ people worldwide actively use an Android (Go edition) phone. And also considering the big OEMs like Jio, Samsung, Oppo, Realme etc. building Android (Go edition) devices, there is a need for developers to build apps that perform well especially on Go devices.
But the markets with the fast growing internet and smartphone penetration can have some challenging issues, such as:
Your app is not starting within the required time limit.
A lot of features/required capabilities increases your app size
How to handle memory pressure while working on Go apps?
Optimize your apps for Android (Go edition)
To help your app succeed and deliver the best possible experience in developing markets, we have put together some best practices based on experience building our own Google apps Gboard & Camera from Google.
Before starting any optimization effort, it’s important to define the goals. Key Performance Indicators (KPIs) have to be defined for the app.
KPIs can be common across different apps and some can be very specific. Some examples of KPIs can be
KPI
Category
App Startup Latency
Common to all apps
App Crash Rate
Common to all apps
End to end latency for CUJ - Camera Shot
Specific to Camera app
App Not Responding Rate
Common to all apps
Once KPIs are defined the team should agree on the target thresholds. This can be derived from the minimum user experience/benchmarks in mind.
KPIs should ideally be defined from the perspective of balancing User Experience and technical complexity.
Breakdown
Once KPIs are defined, the next steps could be to break down a given KPI into individual signal metrics.
For example → End to end latency for CUJ (shots in Camera) can be divided into → Frame capture latency, image processing latency, time spent on saving a processed image to disk etc.
Similarly, App Crash Rate can be bucketed into → Crash due to unhandled errors, Crash due to high memory usage, Crash due to ANR etc.
Benchmark
Benchmark or measure the KPI values and individual metrics to identify current performance. If KPI targets are met, things are good. If not → identify the bottlenecks by looking at the individual breakdowns.
Repeat the process
After optimizing a certain bottleneck go back and benchmark the metrics again to see if the KPI targets are met. If not, repeat the process. If yes, great job!
Add Regular regression test
That either runs for every change or in some frequency to identify regressions in KPIs. It is more difficult to debug and find sources of regressions or bugs than to not allow them to get into the codebase. Don’t allow the changes that fail the KPI goals unless the decision is to update the KPI targets.
Try to invest in building a regression infrastructure to deal with such issues in early stages.
Decide on how often tests should run? What should be the optimal frequency for your app?
Optimize App Memory
Release cache-like memory in onTrimMemory(): onTrimMemory() has always proven useful for an app to trim unneeded memory from its process. To best know an app's current trim level, you can use ActivityManager.getMyMemoryState(RunningAppProcessInfo) and then try to optimize/trim the resources which are not needed.
GBoard used the onTrimMemory() signal to trim unneeded memory while it goes in the background and there is not enough memory to keep as many background processes running as desired, for example, trimming unneeded memory usage from expressions, search, view cache or openable extensions in background. It helped them reduce the number of times being low memory killed and the average background RSS. Resident Set Size(RSS) is basically the portion of memory occupied by your app process that is held in main memory (RAM). To know more about RSS, please refer here.
Check if malloc can be replaced with mmap when accessing read-only & large files: mmap is only recommended for reading a large file onto memory ('read-only memory mapped file'). The kernel has some special optimizations for read-only memory mapped files, such as unloading unused pages.
Typically this is useful for loading large assets or ML models.
Scheduling tasks which require similar resources(CPU, IO, Memory) appropriately: Concurrent scheduling could lead to multiple memory intensive operations to run in parallel and leading to them competing for resources and exceeding the peak memory usage of the app. The Camera from Google app found multiple problems, ensured a cap to peak memory and further optimized their app by appropriately allocating resources, separating tasks into CPU intensive, low latency tasks(tasks that need to be finished fast for Good UX) & IO tasks. Schedule tasks in right thread pools / executors so they can run on resource constrained devices in a balanced fashion.
Find & fix memory leaks: Fighting leaks is difficult but there are tools like Android Studio Memory Profiler/Perfetto specifically available to reduce the effort to find and fix memory leaks.
Google apps used the tools to identify and fix memory issues which helped reduce the memory usage/footprint of the app. This reduction allowed other components of the app to run without adding additional memory pressure on the system.
if ClassA allocates native resources underneath and doesn't cleanup automatically on finalize(..) and requires caller to call some release(..) method, it needs to be like this
ClassA obj = new ClassA("x"); // ... something // Explicit cleanup. obj.release(); obj = new ClassB("y");
else it will leak native heap memory.
Optimize your bitmaps: Large images/drawables usually consume more memory in the app. Google apps identified and optimized large bitmaps that are used in their apps.
Lessons learned :
Prefer Lazy/on-demand initializations of big drawables.
Release view when necessary.
Avoid using full colored bitmaps when possible.
For example:Gboard’s glide typing feature needs to show an overlay view with a bitmap of trails, which can only has the alpha channel and apply a color filter for rendering.
Check and only set the alpha channel for the bitmap for complex custom views used in the app. This saved them a couple of MBs (per screen size/density).
While using Glide,
The ARGB_8888 format has 4 bytes/pixel consumption while RGB_565 has 2 bytes/pixel. Memory footprint gets reduced to half when RGB_565 format is used but using lower bitmap quality comes with a price too. Whether you need alpha values or not, try to fit your case accordingly.
Configure and use cache wisely when using a 3P lib like Glide for image rendering.
Try to choose other options for GIFs in your app when building for Android (Go edition) as GIFs take a lot of memory.
The aapt tool can optimize the image resources placed in res/drawable/ with lossless compression during the build process. For example, the aapt tool can convert a true-color PNG that does not require more than 256 colors to an 8-bit PNG with a color palette. Doing so results in an image of equal quality but a smaller memory footprint. Read more here.
You can reduce PNG file sizes without losing image quality using tools like pngcrush, pngquant, or zopflipng. All of these tools can reduce PNG file size while preserving the perceptive image quality.
You could use resizable bitmaps. The Draw 9-patch tool is a WYSIWYG editor included in Android Studio that allows you to create bitmap images that automatically resize to accommodate the contents of the view and the size of the screen. Learn more about the tool here.
Recap
This part of the blog outlines why developers should consider building for Android (Go edition), a standard approach to follow while optimizing their apps and some recommendations & learnings from Google apps to improve their app memory and appropriately allocate resources.
In the next part of this blog, we will talk about the best practices on Startup latency, app size and the tools used by Google apps to identify and fix performance issues.
A medical game for doctors, a language game for kids, a scary game for horror lovers and an escape room game for thrill seekers! In this latest batch of #WeArePlay stories, we’re celebrating the founders behind a wonderful variety of games from all over the world. Have a read and get gaming!
To start, let’s meet Sam from Chicago. Coming from a family of doctors, his Dad challenged him to make a game to help those in the medical field. Sam agreed, made a game and months later discovered over 100,000 doctors were able to practice medical procedures. This early success inspired him to found Level Ex - a company of 135, making world-class medical games for doctors across the globe. Despite his achievements, his Dad still hopes Sam may one day get into medicine himself and clinch a Nobel prize.
Next, a few more stories from around the world:
Aldo and Sandro from Peru - founders of Dark Dome. They combine storytelling and art to make thrilling and chilling games, filled with plot twists and jump scares.
Vladimir, Tomislav and Boris from Croatia - founders of Pine Studio. They won the Indie Games Festival 2021 with their game Cats In Time.
Kelly, Mikk, Reimo and Madde from Estonia - founders of ALPA kids. Their language games for children have a huge impact on early education and language preservation.
Check out all the stories now at g.co/play/weareplay and stay tuned for even more coming soon.
Today, we’re releasing the Privacy Sandbox on Android Developer Preview 5 ‒ it’s a major milestone that will become the foundation for upcoming Privacy Sandbox Beta releases.
We appreciate that many of you have tested the Developer Preview and have reported issues and shared your feedback. This feedback has helped us evolve the Privacy Sandbox design. For example, we have modified the SDK Runtime design to allow reflection API usage, and have published additional design proposals on FLEDGE services, mediation, and app-to-web measurement.
Let’s have a look at the specifics in this release.
What’s in Developer Preview 5?
Developer Preview 5 includes additional functionality, data validation enhancements, and API signature changes across the privacy preserving APIs and the SDK Runtime. See the release notes for details.
Some source and trigger registration response headers have been consolidated for a more simplified design.
FLEDGE on Android API
To provide up-to-date data for auctions, you can set up a daily fetch URL to update custom audience AdData lists and other metadata.
This release incorporates various API signature changes and additional parameter validation to ensure robustness. Refer to the release notes for details. Be sure to update the sample code and your test projects using previous Developer Preview releases.
SDK Runtime
Apps get additional control on runtime enabled SDK lifecycle events, such as when the SDK is unexpectedly terminated by the platform. Implementing the SdkSandboxLifecycleCallback allows the app to take appropriate actions to recover.
After successfully loading an SDK, apps now have access to an IBinder interface to facilitate 2-way communications with the runtime-enabled SDK.
Topics API
Updated taxonomy for classification of mobile apps.
AdServices permissions
App developers must now declare AdServices permissions to access the privacy preserving APIs. Learn more.
In the coming months, we’ll continue to use the Developer Previews to innovate and implement new features. We’ll publish more details about the Beta and these future releases in the coming months.
Get started with Developer Preview 5
With today’s Developer Preview release, we hope to continue working with the industry and developers to get prepared for Privacy Sandbox on Android. The release provides the resources you need to begin early testing of features and share feedback. To get started developing, see instructions to set up the SDK and system images on the emulator or supported Pixel devices.
Posted by Miłosz Moczkowski, Developer Relations Engineer, Android
As your app grows in size and complexity, it becomes increasingly difficult to manage, build and scale. One way to address this challenge is a software technique called modular programming, or modularization in short. It’s a practice of organizing a codebase into loosely coupled and independent entities - modules.
We know that modularization has been a hot topic among the Android developers community for quite some time now. Recently, we ran a survey to ask you about your experiences in this topic. 86% of developers said that they work on multi-module codebases regularly, while over 90% stated that modularization is a practice they would recommend considering.
All large apps are fundamentally modular, and at Google, we’ve been utilizing modularization to develop our most popular applications such as YouTube, Play Store or Google News. This is what Google News team has to say about this practice:
“Modularity of code is critical to managing complexity, stability, readability, and testability in an ever-growing codebase.”
On the other hand though, over 54% responders mentioned that it’s difficult to find good learning materials on this topic and almost 95% claimed that currently available materials on developer.android.com are insufficient! In response to this popular demand, we’ve launched the guide to Android app modularization. The guide is split into two parts. The overview page gives you a high level, theoretical overview of the matter and addresses the following questions:
What is modularization?
What are the benefits of modularizing my codebase?
What are the things to watch out for when modularizing?
Is modularization the right technique for you?
The common modularization patterns page dives deep into practical examples in the context of the modern Android architecture and gives answer to the these problems:
What is the low coupling & high cohesion principle?
What are the types of modules and their roles?
How do modules pass data between each other?
To see modularization in action, check out the Now in Android project. It's a fully functional app which has a multi-module codebase, and there's a handy modularization learning journey which outlines what the modules do and how they communicate with each other.
Is this for you?
This modularization guide is targeted to intermediate and advanced developers. The guide focuses on modularization from a software architecture point of view. If you’re a beginner, only starting your Android developer journey, you should familiarize yourself with our guide to app architecture first. Modularization guide assumes you are familiar with our recommended app architecture.
It’s just a beginning
We’re not done yet. With modularization being such a wide topic, the two recently released pages are only a beginning. Help us shape the guidance by giving us feedback and telling us which issues you want us to cover. You can find us on social media or use the documentation issue tracker to report bugs.
Posted by Patricia Correa, Director, Global Developer Marketing
Today, at the finals of our Indie Games Festival, thousands of people came together to celebrate the passion, creativity and innovation of small games studios.
Players, jury members, and industry experts attended the event - hosted in a custom virtual world - where they discovered the finalist games and met the people who made them. They were also the first to find out who the winners are, who will receive prizes and promotions that will help them boost their visibility.
At the event we also announced the studios selected to join our Indie Games Accelerator. These companies will receive exclusive education and mentorship over a 10-week virtual program, to help them build and grow successful businesses.
Please join us in congratulating each of the winning games and studios.
Asantee Games - Brazil Fiveamp Hawaii - US MegaJogos - Brazil Niebla Games - Chile Northern Forge Studios - Canada SHD Games Inc. - Canada Skyborne Games Inc. - US Solaris Mobile - Brazil Starling Team - Brazil Temple Gates Games - US
Asia Pacific
Drakemount - South Korea Eternal Dream Studio - Indonesia Gambir Studio - Indonesia Hoit Studio - South Korea Ranida Games - Philippines Rigged Box Softworks - Indonesia SweatyChair - Australia The Sane Studio - South Korea THEAND COMPANY - South Korea Vnstart LLC - Vietnam
Europe, Middle East & Africa
Alcore Games - Ukraine Appox AB - Sweden Hammurabi Games - Turkiye JE Software AB - Sweden LoopyMood - Ukraine PocApp Studios AB - Sweden Rarepixels Indie Games - Spain Rikzu Games - Portugal Rojeh Maher - Egypt Štěpán Fiala - Prague
Didn’t make it?
If you missed the event or would like to explore further, you can still log in to the virtual world and discover more about the finalists. Available for a limited time only. Explore now.
Stay tuned for more programs helping small games companies grow on Google Play.
Posted by Donovan McMurray, CameraX Developer Relations Engineer
As part of Android Jetpack, the CameraX library makes complex camera functionality available in an easy-to-use API, helping you create a best-in-class experience that works consistently across Android versions and devices. As of today, CameraXversion 1.2 is officially in Beta. Update from version 1.1 to take advantage of the latest game-changing features: our new ML Kit integration, which can reduce your boilerplate code when using ML Kit in a CameraX app, and Zero-Shutter Lag, which enables faster action shots than were previously possible.
These two advanced features are simple to implement with CameraX 1.2, so let’s take a look at each of them in depth.
ML Kit Integration
Google’s ML Kit provides several on-device vision APIs for detecting faces, barcodes, text, objects, and more. We’re making it easier to integrate these APIs with CameraX. Version 1.2 introduces MlKitAnalyzer, an implementation of ImageAnalysis.Analyzer that handles much of the ML Kit setup for you.
You can use MlKitAnalyzer with both cameraController and cameraProvider workflows. If you use the cameraController.setImageAnalysisAnalyzer() method, then CameraX can also handle the coordinates transformation between the ML Kit output and your PreviewView.
Here’s a code snippet using setImageAnalysisAnalyzer() to set a BarcodeScanner on a cameraController to detect QR codes. CameraX automatically handles the coordinate transformations when you pass COORDINATE_SYSTEM_VIEW_REFERENCED into the MlKitAnalyzer. (Use COORDINATE_SYSTEM_ORIGINAL to prevent CameraX from applying any coordinate transformations.)
val options = BarcodeScannerOptions.Builder()
.setBarcodeFormats(Barcode.FORMAT_QR_CODE)
.build()
val barcodeScanner = BarcodeScanning.getClient(options)
cameraController.setImageAnalysisAnalyzer(
executor,
new MlKitAnalyzer(List.of(barcodeScanner),
COORDINATE_SYSTEM_VIEW_REFERENCED,
executor, result -> {
// The value of result.getResult(barcodeScanner)
// can be used directly for drawing UI overlay.
}
)
)
Zero-Shutter Lag
Have you ever lined up the perfect photo, but when you click the shutter button the lag causes you to miss the best moment? CameraX 1.2 offers a solution to this problem by introducing Zero-Shutter Lag.
Prior to CameraX 1.2, you could optimize for quality (CAPTURE_MODE_MAXIMIZE_QUALITY) or efficiency (CAPTURE_MODE_MINIMIZE_LATENCY) when calling ImageCapture.Builder.setCaptureMode(). CameraX 1.2 adds a new value (CAPTURE_MODE_ZERO_SHOT_LAG) that reduces latency even further than CAPTURE_MODE_MINIMIZE_LATENCY. Note: for devices that cannot support Zero-Shutter Lag, CameraX will fallback to CAPTURE_MODE_MINIMIZE_LATENCY.
We accomplish this by using a circular buffer of photos. On image capture, we go back in time in the circular buffer to get the frame closest to the actual press of the shutter button. No DeLorean needed. Great Scott!
Here’s an example of how this works in a CameraX app with Preview and ImageCapture use cases:
Just like any other app with a Preview use case, CameraX sends images from the camera to the UI for the user to see.
With Zero-Shutter Lag, CameraX also sends images to a circular buffer which holds multiple recent images.
When the user presses the shutter button, there is inevitably some lag in sending the current camera image to your app. For this reason, Zero-Shutter Lag goes to the circular buffer to fetch an image.
CameraX finds the photo in the circular buffer closest to the actual time when the user pressed the shutter button, and returns that photo to your app.
There are a few limitations to keep in mind with Zero-Shutter Lag. First, please be mindful that this is still an experimental feature. Second, since keeping a circular buffer of images is computationally intensive, you cannot use CAPTURE_MODE_ZERO_SHOT_LAG while using VideoCapture or extensions. Third, the circular buffer will increase the memory footprint of your app.
Next steps
Check our full release notes for CameraX 1.2 for more details on the features described here and more! If you’re ready to try out CameraX 1.2, update your project’s CameraX dependency to 1.2.0-beta01 (or the latest version at the time you’re reading this).
Posted by Márton Braun, Developer Relations Engineer
Five years ago, at the 2017 Google I/O Keynote, we did something we had never done before: we announced official support for a new programming language to build Android apps with: Kotlin. It was great to see how excited the Android developer community was about this announcement.
Since then, JetBrains and Google have been collaborating around the development of Kotlin, and the Kotlin Foundation was co-founded by the two companies.
As highlighted in those initial I/O announcements, Kotlin is interoperable, mature, production-ready, and open source. It also has outstanding IDE support, as JetBrains develops both the language and its tooling.
Now, five years have passed since the original announcement. To celebrate the amazing language that now powers modern Android app development, we’re taking a quick look at the journey of Kotlin on Android. This post includes quotes from a handful of people who were involved in making Kotlin on Android a success, who are joining us for this celebration.
Early years
The Kotlin adoption story started before official support from Google, within the Android developer community. The excitement in the community was one of the main reasons to invest in official support.
“The decision by Google to add support for Kotlin, I think we underestimate how wild of a notion that was at the time. The odds of another company that size making a similar decision based on community support and enthusiasm is very low.“ (Christina Lee, Android engineer at Pinterest, Kotlin and Android GDE)
After the 2017 announcement, Android Studio started shipping with built-in support for Kotlin. Lots of documentation and samples were updated to use Kotlin.
In 2018, we launched the Android KTX libraries, which provide Kotlin-friendly extensions wrapping the APIs of the Android framework and several AndroidX libraries. Tooling improved further, too, with Kotlin-specific live templates, lint checks, and optimizations in R8 and ART. The reference documentation for Android was also published in Kotlin for the first time.
Going Kotlin-first
At Google I/O 2019, we committed to Kotlin-first Android development, further increasing our investments in the language.
“If you look at a Kotlin new users graph, you immediately notice the two most significant spikes – one in May 2017 and another in May 2019. We have an inside joke about it: ‘Marketing a programming language is easy. All you have to do is make the largest operating system in the world call it an official language during the annual keynote’” (Egor Tolstoy, Kotlin Product Lead at JetBrains)
Being Kotlin-first means that we now design our documentation, samples, training content, new libraries and tools for the Kotlin language first, while still supporting users of the Java programming language.
”Now when we want to start a Jetpack Library, we are writing it in Kotlin unless we have a very, very, very good reason not to do that. It’s clear that Kotlin is the first-class language.” (Yigit Boyar, early proponent of Kotlin within Google, currently leading the development of a handful of Jetpack libraries)
Some examples of Kotlin-first Jetpack libraries are Paging 3 and DataStore, which are both powered by coroutines and Flows for asynchronous operations.
Jetpack Compose, Android’s modern UI toolkit is our greatest commitment to Kotlin so far, as it’s Kotlin-only. It’s powered by a Kotlin compiler plugin, and it makes extensive use of advanced language features like coroutines, top-level functions, and trailing lambdas.
“Kotlin is here to stay and Compose is our bet for the future. Right now, for developers that are starting to learn Android, we’re already recommending the Android Basics with Compose course.” (Florina Muntenescu, Jetpack Compose developer relations lead)
Kotlin beyond Android
Even though Kotlin is a great fit for Android, it’s a general-purpose language and not solely for use on Android. For teams within Google, Kotlin is now generally available to use for both Android and server-side projects. Thousands of Google engineers are writing Kotlin code, and our internal codebase contains more than 8.5 million lines of Kotlin code to date. This number has been increasing rapidly as well, doubling year over year.
“We’ve been working to bring Kotlin to Google engineers for the last few years by adding Kotlin support to all the tools they use. This includes the build system, static analysis tools, libraries and APIs. We’ve talked a lot about encouraging developers to use Kotlin for Android app development, and we strongly encourage using Kotlin for server-side development as well.” (Kevin Bierhoff, lead of the Kotlin at Google team, which supports Google engineers writing Kotlin code)
gRPC Kotlin and Kotlin for protocol buffers are examples of Kotlin projects Google uses both in Android apps and on servers that have been open sourced and are now receiving community adoption and contributions. Kotlin is also supported on Google Cloud.
Collaboration with JetBrains
There is close collaboration between JetBrains and Google around the development of Kotlin. The Kotlin Foundation was co-founded by the two companies, and it ensures that the language and ecosystem age well.
Google engineers have also been working on improving the compiler and on creating important tooling for the language.
“My team is helping JetBrains with rewriting the Kotlin compiler right now, and we also work on Kotlin Symbol Processing, which is the first compiler-related Kotlin project that’s been completely done at Google. We work more closely with JetBrains than some other parts of Google." (Jeffrey van Gogh, member of the Kotlin Foundation, lead of the Kotlin engineering team at Google)
JetBrains and Google also coordinate new releases of the language and the accompanying tooling so that developers are able to use the latest releases as smoothly as possible.
“The collaboration gets stronger over time, and I’m really excited to see its impact on Kotlin’s future. Our coordinated pre-release checks are getting better and better." (Liliia Abdulina, Kotlin QA team lead at JetBrains)
Learn more and share your own stories
You can read more stories about Kotlin from our interviewees in the accompanying Medium post.We’d also love to hear your stories of learning and adopting Kotlin for Android development! Share them on social media using the hashtag #Hi5KotlinOnAndroid!
Finally, let’s appreciate these kind words about Kotlin’s accomplishments to conclude our story.
“Technology can really change people's lives and it can really make people happier at work. We normally focus on ‘there's null safety’ or ‘there's type inference’ or all these other technical parts. But when you take a step back, there's a whole story in there about all of the people who had their passion for coding ignited or reignited because Kotlin is such a wonderful language. It's just so impressive that the team is able to do what they're able to do and that the community is as good as it is." (Christina Lee, Android engineer at Pinterest, GDE for Android and Kotlin)
Have a nice Kotlin on Android!
*Java is a trademark or registered trademark of Oracle and/or its affiliates.
TikTok serves a wide range of user groups. With users around the world, it’s inevitable that some of them experience network issues such as slow, intermittent, or expensive connectivity. Other users are using entry level devices with limited memory and storage. Ensuring an excellent app experience in all these scenarios is paramount. TikTok's team was able to significantly improve their overall performance by following Android’s performance guidance, and employing their deep understanding of development tools such as Android Gradle Plugin and Jetpack libraries. If you want to learn how the TikTok team improved their app experience to achieve better business performance, please read our business article here.
Intro
TikTok is one of the most popular community-driven entertainment platforms with 1 billion people across the globe publishing and browsing video content every day.
A diverse user base naturally means diverse network bandwidth conditions and devices with different screen sizes, available memory and processing power. All users want a smooth, responsive app experience, no matter which device they use. If the app is slow to load, or playback gets stuck, users will feel frustrated and might abandon the app altogether. To avoid issues like these, the TikTok team continuously tracks the overall app performance through ongoing data monitoring, peer benchmarks, and user surveys.
TikTok is constantly introducing new features. But a rapid increase in functionality sometimes leads to an upsurge in technical requirements. The engineering team identified three reasons that slowed down the app : janky frames, video playback lag, and network issues. To solve these issues, the TikTok team looked to Android tools to start their app improvement journey.
From Discovery to Solution
Reducing app startup time, a smoother user experience with reduced jank and better video playback experience were three major goals that the team prioritized. They also discussed how to measure the effects of performance optimization to prevent the occurrence of regression.
1. Faster startup: refactor startup framework
App startup time is one of the metrics in Android Vitals. Making sure the app startup time is no longer than the Android Vital’s recommendation is the best way to ensure the app loads and starts responding to user activity as quickly as possible. The App Startup library is an Android Jetpack library to help developers initialize app components simply and efficiently.
The team studied the App Startup library in depth and refactored the app's startup framework to achieve on-demand loading and meticulous scheduling of components. In order to further reduce the execution time of creating Views on the main thread, the team even used a background thread to load View components asynchronously, thus improving the overall speed of app startup.
TikTok used Simpleperf to analyze the code execution time, and Android Studio's Profiler to monitor the usage of resources such as memory, CPU, and network to optimize I/O, threads, and resource locks.
2. Smoother user interface
To ensure a smoother user interface, the team needed to tackle two challenges: 1) simplify the View hierarchy, so that the app only renders what is necessary on screen, and 2) reduce the number of task executions in each frame so that the app can have a steady frame rate.
The TikTok team used the Layout Inspector in Android Studio to pinpoint the unnecessary layout contents. The layout boundaries of each View are clearly visible in the inspector, so the team can easily simplify the View hierarchy of the interface and reduce excessive and unnecessary content drawing.
In many cases, TikTok used doFrame() to perform frame-by-frame tasks. Trying to fit too much work in a single frame will inevitably cause a jank. TikTok's approach was to use allocation algorithms to distribute tasks into different frames to ensure that the application has a steady frame rate.
3. Better video playback experience: reuse resources
TikTok users can create audio and video content in various ways, and different codecs are used to play different types of content. Android provides the MediaCodec class to help access the underlying codec. To further improve the speed of video playback, it is good practice to provide different media player instances for different codecs. The TikTok team created a pool of media player instances throughout the application to neatly provide for various media contents. They even run each media player instance in different threads to minimize interference between one another
Network connection speed is another contributor to video lag . The team tested different solutions, including optimizing connections and reusing sockets, and developed algorithms to dynamically adjust buffer length when streaming content to reduce lag during playback.
They also used on-device video super-resolution to generate high-resolution frames based on low-resolution video content, further improving the quality of video playback without increasing network pressure.
Preloading (loading the next video ahead of time) and pre-rendering (rendering the first frame of the video ahead of time) are critical components to ensure that users have a smooth experience when playing multiple videos in succession. TikTok drew a Surface in advance only adding it into the screen when it is actually needed, to reduce the pressure of drawing it on the spot.
4. Avoid regressions
The team continues to maintain a detailed understanding of performance and works to fine-tune elements when necessary. Luckily, Android has tools in place for this exact purpose, like Systrace to capture traces so developers can export system activities (including CPU scheduling, disk activities, and app threads) for detailed analysis. The team also relies heavily on tools like Perfetto and Android Studio CPU profiler to track the execution time of various events, especially for I/O and class loading.
Better Performance, Better Experience
TikTok creatively leveraged the Android toolchain to track, quantify, and optimize their app’s performance for its business priorities, resulting in improved user experience and an increase in user satisfaction
The app startup time was reduced by 45%, and the smoothness (the chance of the frame rate being lower than the target value) has been optimized by 49%. When playing a video, the first frame of the video appeared 41% faster, and the chance of video lag was reduced by 27%.
Users are now more willing to use TikTok: active days per user in 30 days increased by 1%as did the average of session duration. User surveys and TikTok’s rating in Google Play also show a significant increase in user satisfaction.
The Next Stage for TikTok
By constantly optimizing app performance and adapting to the latest Android 13 platform, TikTok has created a more seamless app experience, encouraging more users to discover, create, and share the content they love.
With more than 250 million active large-screen Android devices globally, the team has also been focusing on large-screen devices, including foldable devices. By adopting the app to large screens, the team has brought a more immersive experience to TikTok users.
To learn more about how TikTok optimized its Android app to improve user experience and business performance, read the article here.
Get Guidance on Performance
To learn how you can get started to inspect, improve and monitor your app's performance visit our developer guide. The fastest way to improve your app's launch speed is by adding a baseline profile to your next release.
Posted by Yafit Becher, Product Manager, Google Play and Luís Dorelli, Engineer, Google Play
Deep links are a great way to improve engagement with your in-app content and the overall user experience by accepting traffic from external sources, including the web. Keeping your deep links in good shape, however, can be a challenge, so many apps have partial, broken, or no deep links configured. For some developers, even answering basic questions like “is this URL deep-linked?” or “why is this deep link not working?” can be difficult to answer.
That’s why we’re making it easier for you to keep your deep links in good shape with a new, dedicated Play Console page. This page collects all the information and tools related to your app’s deep links in one convenient place, giving you a quick but comprehensive snapshot of your current setup to help you identify and troubleshoot issues at a glance.
See a comprehensive snapshot of your deep links so you can easily identify and troubleshoot issues.
On the new deep links page, you’ll find a quick summary of possible issues with your app’s deep links and the steps to take to fix them. The page also lists all web domains your app is configured to accept traffic from, as well as information about the user experience from those domains. In cases where the user experience could be improved, you’ll see step-by-step guidance on how to fix the issue, showing you exactly what’s missing from your app or website association with code snippets to make sure you get it right.
Get step-by-step guidance on how to fix issues with your deep links.
Lastly, the new deep links page offers a full drill-down of your deep links app configuration, listing details of all intent filters and the sources they are configured to receive traffic from. Again, you can see if each line item is properly configured, and if not, get specific instructions about how to fix it.
We’re very excited to share this first release of the deep links page with you, making it much easier to make sense of your setup and fix broken deep links. The next release, coming later this year, will also highlight important website URLs that aren’t yet configured as deep links, so that you don’t miss an opportunity to drive more quality traffic to your app.
Check out the new deep links page today to see the status of your deep links and fix any setup issues.
Posted by Tamzin Taylor, Head of Google Play Partnerships, Western Europe
Today I’m excited to announce that we are launching the second episode of Google Play Coffee breaks. In this episode I enjoyed a virtual coffee with Ravi Teja Akondi, co-founder and CEO of iMumz. iMumz caters to expecting and new parents to help them practice wellbeing and mindfulness during the early stages of parenthood. Ravi and his team recently graduated from Appscale Academy, an initiative aimed at supporting promising Indian app start-ups and helping them grow into global businesses. It’s great to see their continued growth and to hear them share tips and learnings they picked up along the way.
Watch the full Coffee breaks episode and get my take on it below:
The team at iMumz created their app with the mission to help expecting and new parents easily follow a healthy lifestyle every day, encouraging them to practice mindfulness daily. The app provides support to parents focusing on well-being during the first 1,000 days of pregnancy; that is 270 days of pregnancy and the first two years of parenthood. Today, the app helps over 600,000 people achieve these goals.
Ravi recalled how in the early days the iMumz team sent out actionable insights to their audience via a messenger app. They started by customizing small daily routines for those seeking to learn more about wellness during pregnancy and parenthood. By tracking the completion rates and retention rates, the team were able to see that they were really creating something valuable and gained the confidence to take the business from a messaging service to a full mobile application.
Growing a sustainable business
The first step for the iMumz team was to work on building out a community of early adopters. After conducting initial market research the team realized those in tier one cities - the metro cities in India - were the most likely to become early adopters. As they expanded to more and more parents, they learnt how important it was to tailor their pricing to different types of audiences. Experimentation was key to understanding what their different audiences were willing to pay. Remember that beyond the really useful data you can gather from running experiments, you can also get incredibly valuable direct and written feedback from users by inviting them into closed testing groups you can easily set up in the Play Console, without this feedback impacting your star rating.
Nurturing your app community
Through experimenting and listening to users, iMumz learnt that parents-to-be wanted to connect with others like them, and the team quickly realized that the people using their app needed a community. People wanted to connect with others going through similar life events. By building out community spaces the team was able to help initiate discussions on specific topics; such as breastfeeding, baby-led weaning, and self care postpartum. The community has since helped important conversations develop naturally, and provides iMumz users with another level of peer support. Today, their community is vibrant, with more than 5,000 conversations taking place every day!
When it comes to building out a community it’s important that your messaging to users feels genuine and authentic. This was especially important for iMumz, given the app caters to a sensitive and important set of life moments for parents. To start, as with any message, making message content relevant and timely is critical. For example, consider the time of day when determining the best time to post new content, updates, or sending push notifications, and remember different time zones when you’re dealing with a global audience. Additionally, it can help to put a relatable person or character behind the message (remember to localize this to your audience though).
Ravi also shared two key learnings he felt made the biggest difference to the growth of his app:
1) Experiment. There are so many ideas you might find counterintuitive - don’t automatically discount any or jump to conclusions until you test them. Be data driven. That's going to help you provide more value, faster.
2) Narrow down what you’re working on, so you focus on one task or challenge at a time. You might be tempted to do many things at once, but narrowing down will help give you amplified results.
To where does the future lead?
Moving forward, the team at iMumz plan to stay focused on their mission; making the future generation healthier, happier, and more intelligent. They also have global aspirations and they plan to launch across a few selected geographies soon, launching localized versions of the app.
It was such a pleasure to speak to Ravi about his experiences and I can’t wait to see iMumz’s continued growth and next steps. I get so much inspiration from speaking with the people behind apps like iMumz, and I know that inspires my team to continue investing in and developing initiatives such as Appscale Academy.
We are looking forward to continuing to learn from more businesses, and see what you all do next. Stay tuned for the next episode of Coffee Breaks.
Tamzin Taylor, Head of Play Partnerships, Western Europe
Do you have any questions for iMumz? What are your own tips for other app or game businesses? Let us know on Twitter.
Posted by Alex Rocha - Developer Relations Engineer Manager, Ryan Ausanka-Crues - Eng Manager, Multi-device development, Stella Loh - Product Manager, Multi-device development
Today we’re launching our Developer Preview of the new Cross device SDK for Android. First announced during the Google I/O ‘22 Multi-device development session, our Cross device SDK allows developers to build rich multi-device experiences with a simple and intuitive set of APIs. This SDK abstracts away the intricacies involved with working with device discovery, authentication, and connection protocols, allowing you to focus on what matters most—building delightful user experiences and connecting these experiences across a variety of form factors and platforms.
What’s in Developer Preview
This initial release contains a set of rich APIs centered around the core functionality of Device discovery, Secure connections, and Multi-device Sessions.
Device discovery: Easily find nearby devices, authorize peer-to-peer communication, and start the target application on receiving devices.
Secure connections: Enable encrypted, low-latency bi-directional data sharing between authorized devices.
Multi-device Sessions: Enable transferring or extending an application’s user experience across multiple devices.
In turn, this will allow you to build compelling cross-device experiences by enabling and simplifying the following use cases:
Discovering and authorizing communication with nearby devices.
Sharing an app’s current state with the same app on another device.
Starting the app on a secondary device without having to keep the app running in background.
Establishing secure connections for devices to communicate with each other.
Enabling task handoff where the user starts a task on one device, and can easily continue on another device.
Starting today with a Developer Preview for Android phones and tablets, the Cross device SDK will be available later for other Android surfaces and non-Android OSs.
Under The Hood
The Cross device SDK provides a software abstraction layer that handles all aspects of cross-device connectivity, leveraging wireless technologies such as Bluetooth, Wi-Fi, and Ultra-wide band; our SDK does all the heavy-lifting under the hood, offering you a modular,connectivity-agnostic API that supports bi-directional communication between devices and is backward compatible to Android 8. In addition, apps will not have to declare or request Runtime Permissions for any of the underlying connectivity protocols used (such as BLUETOOTH_CONNECT, BLUETOOTH_SCAN, ACCESS_FINE_LOCATION, etc.), and the user can allow apps to connect to only the device(s) they selected.
Getting started with Developer Preview
Head over to our developer guide to get started and try out the Developer Preview of the Cross device SDK for Android. Make sure to check out our Rock Paper Scissor sample app (Kotlin and Java) on GitHub for a demonstration on how to work with the various APIs and our Google I/O ‘22 Multi-device development session for a general overview of the SDK.
Feedback
We’d love to hear from you during this initial Developer Preview launch to help us shape the SDK and influence future roadmapping, so please share your feedback and let us know your experience with the SDK!
Our celebration of app and game businesses continues with more #WeArePlay stories. Today, we’re starting with George from Bristol, UK - a young entrepreneur taking the streetwear industry by storm.
After spending hours and hours searching for the latest styles in sneakers and streetwear, George realised there’s a market in helping fellow enthusiasts find the latest drops. At just 16 years old, he took it upon himself to learn to code and created his app, Droplist. It points people to upcoming special collections from major labels around the world. Find out more about his story.
Today we also spotlight few more stories from around the world:
Anica and Kristijan from an island in Croatia - founders of Dub Studio Productions to help music lovers around the global turn up the bass or lower the treble on their favourite songs.
Robert from Wyoming, founder of Bluebird Languages - language learning apps with over 6 million hours of audio lessons spanning 164 languages, from Hungarian to Haitian Creole.
And one more new story - because why not! This time, featuring Annabel from Kenya. After struggling to find a mechanic when stuck on the roadside in Nairobi, she and her co-founder created Ziada to help people find local service providers.
Check out all the stories now at g.co/play/weareplay and stay tuned for even more coming soon.
Today we’re pushing the Android 13 source to the Android Open Source Project (AOSP) and officially releasing the newest version of Android. For developers, Android 13 is focused on our core themes of privacy and security as well as developer productivity, making it easier for you to build great experiences for users. We’ve also continued to make Android an even better OS for tablets and large screens, giving you better tools to take advantage of the 270+ million of these devices in use across the world. You can read more about Android 13 for consumers in our Keyword blog post
Android 13 is rolling out to Pixel devices starting today. Later this year, Android 13 will also roll out to more of your favorite devices from Samsung Galaxy, Asus, HMD (Nokia phones), iQOO, Motorola, OnePlus, Oppo, Realme, Sharp, Sony, Tecno, vivo, Xiaomi and more.
As always, we thank you for the feedback you’ve shared, and we appreciate the work you’ve done to make your apps compatible with today’s release. Your support and contributions are what make Android a great platform for everyone!
What’s in Android 13 for developers?
Here’s a look at some of what’s new in Android 13 - make sure to check out the Android 13 developer site for details on all of the new features.
Developer productivity and tools
Themed app icons - Android 13 extends Material You dynamic color to all app icons, letting users opt-in to icons that inherit the tint of their wallpaper and other theme preferences. All your app needs to supply is a monochromatic app icon and a tweak to the adaptive icon XML. More here.
Themed app icons adapting to wallpapers colors and dark theme (left).
Per-app language preferences- Android 13 makes it easier to support multilingual users who want to use your apps in a language that’s different from the system language. Android now provides a standard “App language” Settings panel for apps that have opted-in, and you can call a new platform API to get or set the user’s preferred locale at runtime, helping to reduce boilerplate code and improve compatibility. More here.
Per-app languages in Settings
Improved text support - Android 13 includes text and language improvements that help you deliver a more polished experience. Faster hyphenation optimizes hyphenation performance by as much as 200% so you can now enable it in your TextViews with almost no impact on rendering performance. Text conversion APIs make searching and autocompletion faster when using phonetic lettering input for languages like Japanese, Chinese, and others. Android 13 also improves line heights for non-latin scripts (such as Tamil, Burmese, Telugu, and Tibetan), eliminating clipping and making them easier to read. More here.
Improved line height for non-Latin scripts in apps targeting Android 13 (bottom).
Color vector fonts - Android 13 adds rendering support for COLR version 1 (spec, intro video) fonts and updates the system emoji to the COLRv1 format. COLRv1 is a new, highly compact, font format that renders quickly and crisply at any size. For most apps this will just work, and the system handles everything. More here.
COLRv1 vector emoji (left) and bitmap emoji.
Quick Settings Placement API - For apps that provide custom Quick Settings tiles, Android 13 makes it easier for users to discover and add your tiles. Using a new tile placement API, your app can now prompt the user to directly add your custom Quick Settings tile in a single step, without leaving your app. More here.
Media controls derived from PlaybackState - For apps targeting Android 13, the system now derives media controls from PlaybackState actions, providing a richer set of controls that are consistent across phones and tablet devices and align with other Android platforms such as Android Auto and Android TV. More here.
Android 13 media controls are consistent on phones and tablets.
Bluetooth LE Audio -Low Energy (LE) Audio is the next-generation wireless audio built to enable new use cases like sharing and broadcasting audio to friends and family, or subscribing to public broadcasts for information, entertainment, or accessibility. It’s designed to ensure that users can receive high fidelity audio without sacrificing battery life, and lets them seamlessly switch between different use cases. Android 13 adds built-in support for LE Audio, so developers can use the new capabilities on compatible devices. More here.
MIDI 2.0 - Android 13 adds support for the new MIDI 2.0 standard, including the ability to connect MIDI 2.0 hardware through USB. This updated standard offers features such as increased resolution for controllers, better support for non-Western intonation, and more expressive performance using per-note controllers. More here.
OpenJDK 11 updates - Android 13 Core Libraries now align with the OpenJDK 11 LTS release, with both library updates and Java 11 programming language support for app and platform developers. We plan to bring these Core Library changes to more devices through Google Play system updates, as part of an ART module update for devices running Android 12 and higher. More here.
Predictive back gesture - Android 13 introduces new APIs that let your app tell the system that it will handle back events in advance, a practice we call the "ahead-of-time" model. This new approach is part of a multi-year effort to help you prepare your app to support the predictive back gesture, which is available for testing in this release through a developer option. More here.
Built for tablets
Android 13 extends the 12L update that we released earlier this year, and it delivers an even better experience on tablets. You’ll find features like an enhanced multitasking taskbar, more large-screen layouts and optimizations in system UI and apps, improved compatibility modes for apps, and more. We’re continuing to invest to give you the tools you need to build great experiences for tablets as well as Chromebooks and foldables. You can learn more about how to get started optimizing for large screens, and be sure to check out our large screens developer resources.
Multitasking on tablets with Android 13.
Privacy and security
Photo picker and APIs - A new system photo picker now gives users a standard, privacy-protecting way to share local and cloud-based photos. Photo picker extends Android’s long-standing document picker and makes it easy for users to share specific photos and videos with an app, without giving the app permission to view all media files on the device. Photo picker provides a dedicated experience for photos and videos and includes APIs for apps to access the shared media files. The photo picker experience is now available to users who receive Google Play system updates, on devices (excepting Go devices) running Android 11 and higher. More here.
Photo picker lets users share specific photos and videos with an app.
Notification permission - To help users focus on the notifications that are most important to them, Android 13 introduces a new notifications runtime permission. Apps now need to request the notification permission from the user before posting notifications. For apps targeting Android 12 or lower, the system will handle the upgrade flow on your behalf. More here.
Notification permission dialog in Android 13.
Nearby device permission for Wi-Fi - Android 13 introduces the NEARBY_WIFI_DEVICES runtime permission for apps that manage a device's connections to nearby access points over Wi-Fi. The new permission is required for many commonly-used Wi-Fi APIs and enables apps to discover and connect to nearby devices over Wi-Fi without also needing to acquire the location permission. More here.
Granular permissions for media file access - Photo picker is our recommended solution for user-friendly, permissionless sharing of photos and videos, but for apps that haven’t moved to photo picker yet or for audio use cases, Android 13 adds new granular media permissions. These new permissions replace the READ_EXTERNAL_STORAGE permission and provide access to specific types of media files, including images, video, or audio. We highly recommend moving your app to photo picker if possible; otherwise, use the granular media permissions when targeting Android 13. More here.
Requesting permission to access audio files.
Developer downgradable permissions - Starting in Android 13, apps that no longer require permissions previously granted by the user can use a new API to downgrade the permissions. By removing unused permissions, your app can show that it’s using the minimum permissions needed, which can improve user trust. More here.
Safer exported Intent filters - Android 13 applies stricter rules when delivering explicit intents to exported intent filters in another app that’s targeting Android 13. For intents that specify actions, the system now delivers the intents to the exported component only if the intent matches the receiver’s declared <intent-filter> elements. More here.
Performance for apps
Android 13 improves performance and efficiency for all apps through updates to the ART runtime. We plan to bring these improvements to more Android users through Google Play system updates, as part of our ongoing ART module updates for devices running Android 12 and higher.
Improved garbage collection - A new garbage collector based on the Linux kernel feature userfaultfd is coming to ART on Android 13 devices in an upcoming Google Play system update. The new garbage collector eliminates the read barrier and its fixed overhead per object loaded, reducing memory pressure and leading to as much as ~10% reduction in compiled code size. It’s more efficient at GC-time as well, since pages are freed as compaction progresses. Overall, the new garbage collector helps to save battery, avoid jank during GC operations, and protect apps from low-memory kills.
Optimizations throughout ART - In Android 13, ART makes switching to and from native code much faster, with JNI calls now up to 2.5x faster. We’ve also reworked the runtime’s reference processing to make it mostly non-blocking, which further reduces jank. We’ve exposed a new public API, Reference.refersTo(), which is useful in reclaiming unreachable objects sooner, and we’ve made the interpreter faster by optimizing class/method lookups. Lastly, ART now performs more byte-code verification at install time, avoiding the expense of verification at runtime and keeping app startup times fast. More here.
Get your apps ready!
Now with today’s public release of Android 13 to AOSP, we’re asking all Android developers to finish your compatibility testing and publish your updates as soon as possible, to give your users a smooth transition to Android 13.
To test your app for compatibility, just install it on a device running Android 13 and work through the app flows looking for any functional or UI issues. Review the Android 13 behavior changes for all apps first, to focus on areas where your current app could be affected. Here are some of the top changes to test:
Notifications runtime permission - Make sure you understand how this new permission works with your app’s notifications, and plan on targeting Android 13 (API 33) as soon as possible to help support users. More here.
Clipboard preview - Make sure your app hides sensitive data in Android 13’s new clipboard preview, such as passwords or credit card information. More here.
JobScheduler prefetch -JobScheduler now tries to anticipate the next time your app will be launched and will run any associated prefetch jobs ahead of that time. If you use prefetch jobs, test that they are working as expected. More here.
Remember to test the libraries and SDKs in your app for compatibility. If you find any SDK issues, try updating to the latest version of the SDK or reaching out to the developer for help.
With Android 13 bringing a better experience to tablets, make sure your apps look their best. You can test large-screen features by setting up an Android emulator in Android Studio, or you can use a large screen device from our Android 13 Beta partners. Here are some areas to watch for:
Taskbar interaction - Check how your app responds when viewed with the new taskbar on large screens. Make sure your app's UI isn't cut off or blocked by the taskbar. More here.
Multi-window mode - Multi-window mode is now enabled by default for all apps, regardless of app configuration, so make sure the app handles split-screen appropriately. You can test by dragging and dropping your app into split-screen mode and adjusting the window size. More here.
Improved compatibility experience - if your app isn’t optimized for tablets yet, such as using a fixed orientation or not being resizable, check how your app responds to compatibility mode adjustments such as letterboxing. More here.
Media projection - If your app uses media projection, check how your app responds while playing back, streaming, or casting media on large screens. Be sure to account for device posture changes on foldable devices as well. More here.
Camera preview - For camera apps, check how your camera preview UI responds on large screens when your app is constrained to a portion of the screen in multi-window or split-screen mode. Also check how your app responds when a foldable device's posture changes. More here.
You can read more about the tablet features in Android 13 and what to test here.
What’s next?
Android 13 is rolling out to Pixel devices starting today.
If you’re currently enrolled in the Android Beta program, you’ll get the Android 13 final release and remain enrolled to receive ongoing Beta updates for Android 13 feature drops, starting later this year. If you’d like to opt out of ongoing Beta updates without needing to wipe your device, just visit the Android Beta site and opt out after you get the Android 13 final release and before taking the first beta for Android 13 feature drops.
System images for Pixel devices are available here for manual download and flash, and you can get the latest Android Emulator system images via the SDK Manager in Android Studio. If you're looking for the Android 13 source, you'll find it here in the Android Open Source Project repository under the Android 13 branches.
Thanks again for participating in our program of early previews and Betas! We're looking forward to seeing your apps on Android 13!
Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Posted by Anna Bernbaum, Product Manager, Ataul Munim, Developer Relations Engineer
We are excited to announce the launch of the Tiles Material library! Now, instead of building buttons, progress arcs and more from scratch, you can use our pre-built Material components and layouts to create tiles that embrace the latest Material design for Wear OS. You can use these together with the Tiles Design Kit to easily follow the Tiles Design Guidelines.
Tiles provide Wear OS users glanceable access to the information and actions they need in order to get things done quickly. They also are one of the most used surfaces on Wear OS. Just one swipe away from the watch face, users can quickly access the most important information or actions from an app, like starting a timer or getting the latest weather forecast.
Tiles carousel on Wear OS
We have built the following components for elements commonly used in tiles:
These components also make it faster to build tiles. For example, creating a button for your tile takes just a few lines of code:
val clickable:Clickable= generateClickable()
val button:Button=Button.Builder(this, clickable) .setIconContent("icon_exercise")
.setContentDescription("Start workout")
.build()
We have also created some predefined layouts to kickstart your tiles development. These already follow our design guidelines on how your tile layout should be formatted.
For example, we can build this tile using a predefined layout:
This library contains components and layouts that are in-line with Material guidelines and easy to use. The included components are:
Button - clickable, circular-shaped object, with either icon, text or image with three predefined sizes.
Chip - clickable, stadium-shaped object that can contain an icon, primary and secondary labels, and has fixed height and customizable width.
CompactChip & TitleChip - two variations of the standard Chip that have smaller and larger heights, respectively, and can contain one line of text.
CircularProgressIndicator - colored arc around the edge of the screen with the given start and end angles, which can describe a full or partial circle with the full progress arc behind it.
Text - styled text which uses the recommended Wear Material typography styles.
All these components have their own colors object that can be built with the main Colors class to easily apply the same theme over all components. In addition to colors, there is a Typography class to easily get FontStyle objects using the typography name.
In addition to components, there are recommended tile layouts:
PrimaryLayout - a layout which can be customized by adding primary or secondary labels, content in the middle, and a primary chip at the bottom. The main content within this layout could be added as a MultiSlotLayout or MultiButtonLayout object.
EdgeContentLayout - a layout for hosting CircularProgressIndicator around the edge with main content inside and primary or secondary label around it.
MultiButtonLayout - a layout that can contain between 1 - 7 buttons, arranged in line with the Material guidelines depending on their number.
MultiSlotLayout - a row-like style layout with horizontally aligned and spaced slots (for icons or other small content).
All layouts have recommended padding and styles applied that are within Material guidelines.
Tools for tiles
Android Studio Dolphin includes the Direct Surface Launch feature. This lets developers install and launch a tile directly from Android Studio, instead of having to manually add it from the tile selector on the target device. Get started with Direct Surface Launch by creating a new Run Configuration and selecting Wear OS Tile, then choosing the module and TileService class.
Horologist Tiles is also recommended to save time during tile development. This library gives you the ability to preview a tile UI straight from Android Studio, making the write-test loop a lot shorter. Horologist Tiles also includes Kotlin friendly abstractions, like CoroutinesTileService so you can use what you're already familiar with.
Posted by Patricia Correa, Director, Global Developer Marketing
The Indie Games Festival shines a spotlight on some of the best games on Google Play, and celebrates the passion and creativity that small games studios bring to gamers worldwide. This year we are hosting Festival in South Korea, Japan and Europe, for local developers and gamers from all over the world.
Earlier this summer, we opened submissions, and today we’re revealing the finalists. Scroll down to see the shortlisted games!
Join the finals
September 3rd will be a jam packed day for indie games fans. Everyone is invited to attend the finals for the three Festivals, starting with South Korea at 2pm KST, followed shortly after by Japan at 3pm JST, and wrapping up with Europe at 11am CET.
The finals will be held in a custom virtual world where you can meet the people behind the finalist games, explore the titles, have fun with gamers from around the world, and be the first to discover the winners.
At the European finals we will also reveal the class of 2022 of the Indie Games Accelerator, a program that helps small game studios take their game to the next level by providing them training and mentorship.
Without further ado, please meet the finalists and join us in congratulating them!
More about the Indie Games Festival and the Indie Games Accelerator
At Google Play we’re committed to helping developers of all sizes succeed on our platform. Programs like the Festival and the Accelerator are here to help small games studios:
Festival | Promotions & prizes that put your game in the spotlight: This contest is your chance to showcase your game to industry experts and players worldwide, and win prizes that will celebrate your art and promote your game.
Accelerator | Training and mentorship to supercharge your growth: Over a period of 10 weeks, you will get tailored online training sessions and mentorship from industry and Google experts to help you polish your game and scale with Google Play.
Posted by Jason Tang, Product Management, Diego Zuluaga, Developer Relations, and Michael Mauzy, Developer Documentation
Since we introduced gesture navigation in Android 10, users have signaled they want to understand where a back gesture will take them before they complete it.
As the first step to addressing this need, we've been developing a predictive back gesture. When a user starts their gesture by swiping back, we’ll show an animated preview of the destination UI, and the user can complete the gesture to navigate to that UI if they want – as shown in the following example.
Although the predictive back gesture won’t be visible to users in Android 13, we’re making an early version of the UI available as a developer option for testing starting in Beta 4. We plan to make the UI available to users in a future Android release, and we’d like all apps to be ready. We’re also working with partners to ensure it’s consistent across devices.
Read on for details on how to try out the new gesture and support it in your apps. Adding support for predictive back gesture is straightforward for most apps, and you can get started today.
To try out the early version of the predictive back gesture available through the developer option, you’ll need to first update your app to support the predictive back gesture, and then enable the developer option.
Update your app to support predictive back gesture
To help make predictive back gesture helpful and consistent for users, we're moving to an ahead-of-time model for back event handling by adding new APIs and deprecating existing APIs.
The new platform APIs and updates to AndroidX Activity 1.6+ are designed to make your transition from unsupported APIs (KeyEvent#KEYCODE_BACK and OnBackPressed) to the predictive back gesture as smooth as possible.
You can start testing this feature in two to four steps, depending on your existing implementation.
To begin testing this feature:
1. Upgrade to AndroidX Activity 1.6.0-alpha05. By upgrading your dependency on AndroidX Activity, APIs that are already using the OnBackPressedDispatcherAPIs such as Fragments and the Navigation Component will seamlessly work when you opt-in for the predictive back gesture.
// In your build.gradle file: dependencies {
// Add this in addition to your other dependencies implementation "androidx.activity:activity:1.6.0-alpha05"
2. Opt-in for the predictive back gesture. Opt-in your app by setting the EnableOnBackInvokedCallback flag to true at the application level in the AndroidManifest.xml.
<application
...
android:enableOnBackInvokedCallback="true"
... >
...
</application>
If your app doesn’t intercept the back event, you're done at this step.
Note:Opt-in is optional in Android 13, and it will be ignored after this version.
3. Create a callback to intercept the system Back button/event. If possible, we recommend using the AndroidX APIs as shown below. For non-AndroidX use cases, check the platform API mentioned above.
This snippet implements handleOnBackPressed and adds the OnBackPressedCallback to the OnBackPressedDispatcher at the activity level.
val onBackPressedCallback = object: OnBackPressedCallback(true) {
overridefun handleOnBackPressed() {
// Your business logic to handle the back pressed event
}
}
requireActivity().onBackPressedDispatcher
.addCallback(onBackPressedCallback)
4. When your app is ready to stop intercepting the system Back event, disable the onBackPressedCallback callback.
Note:Your app may require using the platform APIs (OnBackInvokedCallback and OnBackPressedDispatcher) to implement the predictive back gesture. Read our documentation for details.
Enable the developer option to test the predictive back gesture
Once you’ve updated your app to support the predictive back gesture, you can enable a developer option (supported in Android 13 Beta 4 and higher) to see it for yourself.
To test this animation, complete the following steps:
On your device, go to Settings > System > Developer options.
Select Predictive back animations.
Launch your updated app, and use the back gesture to see it in action.
If you need a refresher on system back and predictive back gesture on Android, we recommend watching Basics for System Back.
Thank you again for all the feedback and being a part of the Android Community - we love collaborating together to provide the best experience for our users.
Posted by Jolanda Verhoef, Android Developer Relations Engineer
Today, we’re releasing version 1.2 of Jetpack Compose, Android's modern, native UI toolkit, continuing to build out our roadmap. This release contains new features like downloadable fonts, lazy grids, and improvements for tablets and Chrome OS with better focus, mouse, and input handling.
Compose is our recommended way to build new Android apps for phone, tablets and foldables. Today we also released Compose for Wear OS 1.0 - making Compose the best way to build a Wear OS app as well.
“Compose increased our productivity dramatically. It’s much easier and faster to write a Composable function than to create a custom view, and it’s also made it much easier to fulfill our designers’ requirements.”
Compose 1.2 includes a number of updates for Compose on Phones, Tablets and Foldables - it contains new stable APIs graduated from being experimental, and supports newer versions of Kotlin. We've already updated our samples, codelabs, Accompanist library and MDC-Android Compose Theme Adapter to work with Compose 1.2.
Note: Updating the Compose Compiler library to 1.2 requires using Kotlin 1.7.0. From this point forward the Compiler releases will be decoupled from the releases of other Compose libraries. Read more about the rationale for this in our blog post on independent versioning of Jetpack Compose libraries.
New stable features and APIs
Several features and APIs were added as stable. Highlights include:
The APIs LazyHorizontalGrid and LazyVerticalGrid let you place lists of items in a grid. These APIs already existed in Compose 1.1 but were marked as @Experimental.
We’re continuing to bring new features to Compose. Here are a few highlights:
Create your own custom efficient scrollable layouts with LazyLayout. Add custom overscroll effects to your scrollable container using Modifier.overscroll.
Improved test APIs. For example, the performKeyInput action mimics keyboard input in your tests. The new testTagsAsResourceId semantics property allows integration with UI Automator.
Make the back button behavior in TextField identical to the behavior in EditText.
We’re grateful for all of the bug reports and feature requests submitted to our issue tracker - they help us to improve Compose and build the APIs you need. Do continue providing your feedback and help us make Compose better!
Wondering what’s next? Check out our updated roadmap to see the features we’re currently thinking about and working on, such as animations for lazy item additions and removals, flow layouts, text editing improvements and more!
Jetpack Compose continues to evolve with the features you’ve been asking for. We’ve been thrilled to see tens of thousands of apps using Jetpack Compose in production already, and many of you shared how it’s improved your app development. We can’t wait to see what you’ll build next!
Today we’re launching version 1.0 of Compose for Wear OS, the first stable release of our modern declarative UI toolkit designed to help developers create beautiful, responsive apps for Google’s smartwatch platform.
Compose for Wear OS was built from the bottom up in Kotlin with assumptions of modern app architecture. It makes building apps for Wear OS easier, faster, and more intuitive by following the declarative approach and offering powerful Kotlin syntax.
The toolkit not only simplifies UI development, but also provides a rich set of UI components optimized for the watch experience with built-in support of Material design for Wear OS, and it’s accompanied by many powerful tools in Android Studio to streamline UI iteration.
What this means
The Compose for Wear OS 1.0 release means that the API is stable and has what you need to build production-ready apps. Moving forward, Compose for Wear OS is our recommended approach for building user interfaces for Wear OS apps.
Your feedback has helped shape the development of Compose for Wear OS; our developer community has been with us each step of the way, engaging with us on Slack and providing feedback on the APIs, components, and tooling. As we are working on bringing new features to future versions of Compose for Wear OS, we will continue to welcome developer feedback and suggestions.
We are also excited to share how developers have already adopted Compose in their Wear OS apps and what they like about it.
What developers are saying
Todoist helps people organize, plan and collaborate on projects. They are one of the first companies to completely rebuild their Wear OS app using Compose and redesign all screens and interactions:
“When the new Wear design language and Compose for Wear OS were announced, we were thrilled. It gave us new motivation and opportunity to invest into the platform.”
Todoist application
Relying on Compose for Wear OS has improved both developer and user experience for Todoist:
“Compose for Wear OS helped us tremendously both on the development side and the design side. The guides and documentation made it easy for our product designers to prepare mockups matching the new design language of the platform. And the libraries made it very easy for us to implement these, providing all the necessary widgets and customizations. Swipe to dismiss, TimeText, ScalingLazyList were all components that worked very well out-of-the-box for us, while still allowing us to make a recognizable and distinct app.”
Outdooractive helps people plan routes for hiking, cycling, running, and other outdoor adventures. As wearables are a key aspect of their product strategy, they have been quick to update their offering with an app for the user's wrist.
Outdooractive application
Outdooractive has already embraced Wear OS 3, and by migrating to Compose for Wear OS they aimed for developer-side benefits such as having a modern code base and increased development productivity:
“Huge improvement is how lists are created. Thanks to ScalingLazyColumn it is easier (compared to RecyclerView) to create scrolling screens without wasting resources. Availability of standard components like Chip helps saving time by being able to use pre-fabricated design-/view-components. What would have taken us days now takes us hours.”
The Outdooractive team also highlighted that Compose for Wear OS usage help them to strive for better app quality:
“Improved animations were a nice surprise, allowing smoothly hiding/revealing components by just wrapping components in “AnimatedVisibility” for example, which we used in places where we would normally not have invested any time in implementing animations.”
Another developer we’ve been working with, Period Tracker helps keep track of period cycles, ovulation, and the chance of conception.
Period Tracker application
They have taken advantage of our UI toolkit to significantly improve user interface and quickly develop new features available exclusively on Wear OS:
“Compose for Wear OS provided us with many kits to help us bring our designs to life. For example, we used Chips to design the main buttons for period recording, water drinking, and taking medication, and it also helped us create a unique look for the latest version of Kegel workout.”
Similarly to other developers, Period Tracker noted that Compose for Wear OS helped them to achieve better developer experience and improved collaboration with design and development teams:
“For example, before Chips components were available, we had to use a custom way to load images on buttons which caused a lot of adaptation work. Yes, Compose for Wear OS improved our productivity and made our designers more willing to design a better user experience on wearables.”
Check out the in-depth case studies to learn more about how other developers are using Jetpack Compose.
1.0 release
Let’s look into the key features available with 1.0 release:
Material: The Compose Material catalog for Wear OS already offers more components than are available with View-based layouts. The components follow material styling and also implement material theming, which allows you to customize the design for your brand.
Declarative: Compose for Wear OS leverages Modern Android Development and works seamlessly with other Jetpack libraries. Compose-based UIs in most cases result in less code and accelerate the development process as a whole, read more.
Interoperable: If you have an existing Wear OS app with a large View-based codebase, it's possible to gradually adopt Compose for Wear OS by using the Compose Interoperability APIs rather than having to rewrite the whole codebase.
Handles different watch shapes: Compose for Wear OS extends the foundation of Compose, adding a DSL for all curved elements to make it easy to develop for all Wear OS device shapes: round, square, or rectangular with minimal code.
Performance: Each Compose for Wear OS library ships with its own baseline profiles that are automatically merged and distributed with your app’s APK and are compiled ahead of time on device. In most cases, this achieves app performance for production builds that is on-par with View-based apps. However, it’s important to know how to configure, develop, and test your app’s performance for the best results. Learn more.
Note that using version 1.0 of Compose for Wear OS requires using the version 1.2 of androidx.compose libraries and therefore Kotlin 1.7.0. Read more about Jetpack Compose 1.2 release here.
Tools and libraries
Android Studio
The declarative paradigm shift also alters the development workflow. The Compose tooling available in Android Studio will help you build apps more productively.
Android Studio Dolphin includes a new project template with Compose for Wear OS to help you get started.
The Composable Preview annotation allows you to instantly verify how your app’s layout behaves on different watch shapes and sizes. You can configure the device preview to show different Wear OS device types (round, rectangle, etc):
importandroidx.compose.ui.tooling.preview
@Preview(
device=Devices.WEAR_OS_LARGE_ROUND,
showSystemUi=true,
backgroundColor=0xff000000,
showBackground=true
)
@Composable
funPreviewCustomComposable() {
CustomComposable(...)
}
Starting with Android Studio Electric Eel, Live Edit supports iterative code development for Wear OS, providing quick feedback as you make changes in the editor and immediately reflecting UI in the Preview or running app on the device.
Horologist
Horologist is a group of open-source libraries from Google that supplement Wear OS development, which we announced with the beta release of Compose for Wear OS. Horologist has graduated a number of experimental APIs to stable including TimeText fadeAway modifiers, WearNavScaffold, the Date and Time pickers.
Date and Time pickers from Horologist library
Learning Compose
If you are unfamiliar with using Jetpack Compose, we recommend starting with the tutorial. Many of the development principles there also apply to Compose for Wear OS.
To learn more about Compose for Wear OS check out:
Posted by Purnima Kochikar, VP of Partnerships, Google Play
This week we are celebrating ten years of Google Play. Over the past decade, your creativity combined with our investment in a global platform has created a thriving app ecosystem. 2.5 billion people in over 190 countries visit Play every month to connect with your apps and games, and Play has generated over $120 billion in earnings for developers to date. We’re so proud of this amazing milestone, and grateful for your partnership.
Looking back
I joined the team in 2012, only a few months after Google Play launched. At that time, active users on Android had just grown from 100 million to 400 million. Android was the new kid on the block, with the audacious goal of making mobile computing accessible to everyone, everywhere. You were understandably skeptical about our chances for success - we were so far behind competing platforms in most aspects, from platform features and tools to design guidelines and commercial capabilities. Our belief in the immense potential of a fair and open ecosystem - and, even more importantly, our belief in your limitless potential - made us push forward. We were and continue to be driven by our commitment to your success.
Back then, our tiny partnerships team of just six people was figuring out how we could best support you in navigating the opportunities and challenges of the mobile economy. There were so many uncertainties: would we be able to deliver the apps you were envisioning to a global audience on devices they can afford? Would people watch videos on the small smartphone screens, given the high cost of mobile data and low device capabilities? Would they be happy paying for mobile games, and feel safe doing so? Would people subscribe to in-app content in the same way that they did to physical goods like magazines and newspapers?
We were with you every step of the way, taking the time to understand your needs and find ways to help you build beautiful apps and games. We also invited our global community of users to help us evolve your apps and games together, supported by features like beta testing and staged rollouts, and the ability to reply to user reviews.
Some of my fondest memories from those early days are of working with companies who inspired us by dreaming up novel ways to harness the magic of mobile phones. They broadened our perspective of what is possible. Smule is one of those early partners who kicked off their success in the first couple of years of Play. They became one of the first of many to inspire my team, and share their story with the community:
As your apps gained traction and you aspired to convert them into sustainable global businesses, we bolstered our investments in our commerce platform to help you grow and manage your business. We added the most popular and effective forms of payment from around the world to ensure people could pay for your apps and games frictionlessly. We removed complexities associated with finding and integrating local payment, including access to 300+ local payment methods supported in 70 countries. We also evolved our platform to anticipate and support your business needs - going from premium to free-to-play and subscriptions business models - and now Google Play helps consumers transact safely and seamlessly in more than 170 markets.
We provided industry leading insights through our Play Console on the entire lifecycle of your app, from installs to Vitals and more, to help you manage your business effectively. I remember my entire team tearing up when Vincenzo Colucci, the founder of Smart Launcher, described how Play enabled him to live where he wanted to live - in Manfredonia, in the South of Italy, with his loved ones - and do what he loves to do - build apps that impact people around the world. His company also turned 10 years old this year.
At every step, you demanded more from us and inspired us to think more expansively. In response, our product and engineering teams built tools and capabilities that could support all the great things that you were doing. Your feedback has helped to shape the launch of new features, resources and programs to support your success on the platform. With your help, we have evolved:
We’ve also worked in partnership with several of you to create new features that would benefit the entire ecosystem. For example, in 2015, we worked with Supercell to help prevent fraud, leading to the launch of the Voided Purchases API, which drove industry-wide improvements to fraud and refund abuse. Similarly, our Japanese and Korean partners like GungHo Online Entertainment and NCSOFT helped us grow from a platform that supported pay-and-download games, like Rovio’s early Angry Birds, to becoming a LiveOps platform that supports games as a live service. Our media partners helped us evolve our subscriptions platform to include features such as Account Hold and Grace Period. Interestingly, we used these features to help our sports apps partners to hold on to their subscribers when the world went into lockdown.
While there are countless such examples in our decade-long partnerships, here are 10 of our most memorable launches from the last 10 years:
As your businesses matured, we invested in product capabilities such as Play Points to help you retain and re-engage your most loyal users. We are so proud that this program has over 100 million members in 28 countries, with further expansion scheduled for later this year. We also created a consulting service to provide business and technical insights to help you make more data driven decisions about your product roadmap and global expansion plans. You have told us that these insights have helped to drive millions in incremental revenues for you, and informed not only your product direction, but also your M&A strategies.
Above all, our partnership has brought meaningful apps and games to global audiences, and built successful businesses that have created new jobs and helped local economies. In the US alone, Play and Android have helped to create more than 2M jobs. We are truly proud of the economic impact we have had together on local communities and small businesses around the world.
Looking forward
As we look towards our next decade, it is useful to pause and reflect on the last two unprecedented years we have experienced together, and the overwhelmingly positive impact our partnership has had on the lives of so many people. Android and Play - powered by your businesses - have connected families and loved ones together, helped to keep people safe by supporting daily needs, sped up access to telemedicine, created employment, and enabled kids to learn and grow. Let’s take a moment to let that sink in.
These years have taught us important lessons about our joint responsibility to foster a safe and trusted ecosystem, and how much more needs to be done to make mobile accessible to everyone. As we think about the future, there are three areas which are top of mind of us:
Continuing to evolve our tools to support your business decision making, evolve our business models, and to help you safely grow your businesses and deliver the best quality experiences for your users in the evolving privacy and security landscape.
Building an ecosystem for everyone by investing in initiatives that improve representation in the apps and games industry, and by empowering more underrepresented founders to build successful businesses. Last year we moved beyond a “one size fits all” service fee model to ensure all types of businesses can be successful, and we will continue to have multiple programs designed to support our diverse app ecosystem.
The success of the founders who have gone through our Indie Game Festival and Accelerator programs, and the meaningful impact of our Change the Game initiative and of our accessibility efforts, make us optimistic about our ecosystem. We look forward to the next decade where we welcome many more founders like nine year old Alyssa and her mother who created Frobelles, a dress-up game increasing representation of African and Caribbean hair styles, to our #WeArePlay family.
Thank you for being an integral part of our audacious goal to make mobile accessible to everyone, everywhere. We have come a long way and we have a long way to go. We are inspired by and grateful for each one of you, and remain singularly committed to your success. We can’t wait to see what you will create next, and the new horizons you will drive us to explore and enable.
Posted by Maru Ahues Bouza, Director, Android Developer Relations
We’re just a few weeks away from the official release of Android 13! As we put the finishing touches on the next version of Android, today we’re bringing you Beta 4, a final update for your testing and development. Now is the time to make sure your apps are ready!
There’s a lot to explore in Android 13, from privacy features like the new notification permission and photo picker, to productivity features like themed app icons and per-app language support, as well as modern standards like HDR video, Bluetooth LE Audio, and MIDI 2.0 over USB. We’ve also extended the updates we made in 12L, giving you better tools to take advantage of tablet and large screen devices.
You can try Beta 4 today on your Pixel device by enrolling here for over-the-air updates. If you previously enrolled, you’ll automatically get today’s update. You can also get Android 13 Beta on select devices from several of our partners. Visit the Android 13 developer site for details.
Watch for more information on the official Android 13 release coming soon!
What’s in Beta 4?
Today’s update includes a release candidate build of Android 13 for Pixel devices and the Android Emulator. We reached Platform Stability at Beta 3, so all app-facing surfaces are final, including SDK and NDK APIs, app-facing system behaviors, and restrictions on non-SDK interfaces. With these and the latest fixes and optimizations, Beta 4 gives you everything you need to complete your testing.
Get your apps ready!
With the official Android 13 release just ahead, we’re asking all app and game developers to complete your final compatibility testing and publish your compatibility updates ahead of the final release. For SDK, library, tools, and game engine developers, it’s important to release your compatible updates as soon as possible -- your downstream app and game developers may be blocked until they receive your updates.
To test your app for compatibility, just install it on a device running Android 13 Beta 4 and work through the app flows, looking for any functional or UI issues. Review the Android 13 behavior changes for all apps to focus on areas where your app could be affected. Here are some of the top changes to test:
Runtime permission for notifications - Android 13 introduces a new runtime permission for sending notifications from an app. Make sure you understand how the new permission works, and plan on targeting Android 13 (API 33) as soon as possible. More here.
Clipboard preview - Make sure your app hides sensitive data in Android 13’s new clipboard preview, such as passwords or credit card information. More here.
JobScheduler prefetch - JobScheduler now tries to anticipate the next time your app will be launched and will run any associated prefetch jobs ahead of that time. If you use prefetch jobs, test that they are working as expected. More here.
Remember to test the libraries and SDKs in your app for compatibility. If you find any SDK issues, try updating to the latest version of the SDK or reaching out to the developer for help.
Android 13 builds on the tablet optimizations introduced in 12L, so as part of your testing, make sure your apps look their best on tablets and other large-screen devices. You can test large-screen features by setting up an Android emulator in Android Studio, or you can use a large screen device from our Android 13 Beta partners. Here are some areas to watch for:
Taskbar interaction - Check how your app responds when viewed with the new taskbar on large screens. Make sure your app's UI isn't cut off or blocked by the taskbar. More here.
Multi-window mode - Multi-window mode is now enabled by default for all apps, regardless of app configuration, so make sure the app handles split-screen appropriately. You can test by dragging and dropping your app into split-screen mode and adjusting the window size. More here.
Improved compatibility experience - if your app isn’t optimized for tablets yet, such as using a fixed orientation or not being resizable, check how your app responds to compatibility mode adjustments such as letterboxing. More here.
Media projection - If your app uses media projection, check how your app responds while playing back, streaming, or casting media on large screens. Be sure to account for device posture changes on foldable devices as well. More here.
Camera preview - For camera apps, check how your camera preview UI responds on large screens when your app is constrained to a portion of the screen in multi-window or split-screen mode. Also check how your app responds when a foldable device's posture changes. More here.
You can read more about the tablet features in Android 13 and what to test here.
Get started with Android 13
Today’s Beta 4 release has everything you need to test your app and try the Android 13 features. Just enroll your Pixel device to get the update over-the-air. To get started, set up the Android 13 SDK.
You can also test your app with Android 13 Beta on devices from several of our partners. Visit android.com/beta to see the full list of partners, with links to their sites for details on their supported devices and Beta builds, starting with Beta 1. Each partner will handle their own enrollments and support, and provide the Beta updates to you directly. For even broader testing, you can try Beta 4 on Android GSI images, and if you don’t have a device, you can test on the Android Emulator. For complete details on Android 13, visit the Android 13 developer site.
A huge thank you to our developer community for helping shape the Android 13 release! You’ve given us thousands of bug reports and shared insights that have helped us optimize APIs, improve features, fix significant bugs, and in general make the platform better for users and developers.
We’re looking forward to seeing your apps on Android 13!
We’re back with more #WeArePlay stories to celebrate you: the global community of people behind apps and games businesses.
Following last week’s “virtual roadtrip” of all of the US, today we’re kicking off with Melissa from Greenville, South Carolina. She’s on a mission to make the world a more pet-friendly place. Her app, BringFido, helps people find somewhere to stay, eat or visit with their furry friends. In this film you will meet her, her dogs Ace and Roxy, and hear how she went from idea, to website, to growing app and thriving business.
This week we are also introducing you to game founders from other parts of the world:
Arnaud, an AI-enthusiast from Chartres in France, who founded Elokence. This 12-people team created Akinator, which has been downloaded over 260 million times on Google Play.
Daigo, a creative indie from Japan, founder of Odencat, whose games have won multiple accolades.
Keerti and Kashyap, a cricket-loving couple from Hyderabad in India, who used their life savings to start Hitwicket Cricket Games. Millions of fans worldwide enjoy their games.
Check out all the stories now at g.co/play/weareplay and stay tuned for even more coming soon.
Posted by Jolanda Verhoef, Android Developer Relations Engineer
Starting today, the various Jetpack Compose libraries will move to independent versioning schemes. This creates the possibility for sub-groups such as androidx.compose.compiler or androidx.compose.animation to follow their own release cycles.
Allowing these libraries to be versioned independently will decouple dependencies which were previously implicitly coupled, thereby making it easier to incrementally upgrade your application and therefore stay up-to-date with the latest Compose features.
The first library to break away from the single Compose version is the Compose Compiler. Today we’re releasing the 1.2.0 stable version that brings support for Kotlin 1.7.0! The release is both backwards and forwards compatible with the Compose UI libraries and the Compose Runtime library. This means you can upgrade your Compose Compiler to 1.2.0 stable and use Kotlin 1.7.0, while leaving your other Compose libraries on their current version, for example 1.1.0 stable.
To upgrade the version of the Compose Compiler in your app, specify the kotlinCompilerExtensionVersion in your build.gradle file.
Compose and Kotlin are highly coupled, and we’ve heard your feedback that Compose compiler updates are needed to allow you to upgrade your Kotlin version. We want to make sure that you can use the latest and greatest features (and bug fixes) from both Compose and Kotlin, which is why we plan to release stable versions of the Compose Compiler on a much more regular basis. This means the Compose Compiler version numbers will progress at a faster pace than most other Compose libraries. Since the Compose Compiler is both forwards and backwards compatible, you will be able to upgrade it as soon as a new version is released.
The Compose Compiler is built as a Kotlin Compiler Plugin, and so you must use a version of the Compose Compiler which is compatible with the version of Kotlin that you have chosen. To help you choose the version that matches your project, check out the Compose-Kotlin compatibility map.
Moving the Compiler library to a different versioning scheme is the first step in decoupling versioning for the different Compose library groups. You’ll see new stable releases for the other Compose libraries in the next few weeks, and then they will then start following their own release cycles independent of the Compose Compiler.
Prepare your build for individual versioning and start using the latest Compose Compiler and Kotlin versions now!
We look forward to seeing what you build with Compose!
Posted by Sachiyo Sugimoto, Android Partner Engineering
A strength of Android is its diverse ecosystem of devices, brought to market by more than 24K distinct devices, and used by billions of people around the world. Since the early releases of Android, we’ve invested in our Android Compatibility Program as a way to ensure that devices continue to provide a stable, consistent environment for apps.
The Compatibility Test Suite (CTS) is a key part of the program - it is a collection of more than two million test cases that check Android device implementations to ensure developer applications run on a variety of devices and enable a consistent application experience for users.
Device makers run CTS on their devices throughout the development process, and use it to identify and fix bugs early. Over the years we have constantly expanded the suite by adding new test cases, and today CTS includes more than 2 million tests. It is still growing - as Android evolves, there are new areas to cover and there are also gaps where we are constantly working to create additional tests.
While most CTS tests are written by Android engineers, we know that app developers have a unique perspective on actual device compatibility issues. So to enhance CTS with better input from app developers, we are adding a new test suite called CTS-D that is built and run by developers like you.
What is CTS-D?
CTS-D is a new CTS module that is powered by app developers with a focus on pain points that they are seeing in the field. Developers can build and contribute test cases to CTS-D to help catch those issues, and they can run the CTS-D suite to verify compatibility. Longer term, our plan is to work closely with the Android developer community to expand the CTS-D suite.
We know that many of you have already created your own tests to verify compatibility on various devices. We want to work with you to bring those tests into AOSP, and you can see the first tests contributed by the community in the initial CTS-D commit here.
So with CTS-D, we are helping to make those kinds of tests available widely, to help device manufacturers and app developers identify and share issues more effectively.
How is CTS-D used?
CTS-D is open-sourced and available on AOSP, so any app developer can use it as a verification tool. Using CTS-D helps to minimize the communication overhead among app developers, device manufacturers and Google, helping to resolve issues effectively.
If a certain device does not pass a CTS-D test, please report the problem using this issue tracker template. After we verify the issue on the reported device, we will work with our partners to resolve it. We're also strongly advising device manufacturers to use CTS-D to discover and mitigate issues.
Get Started with CTS-D!
If you have an idea for CTS-D, please file a test proposal using this issue tracker template before contributing your test code to AOSP. The Android team will review your proposal and verify your test’s eligibility. We’re currently most interested in adding more test cases in the area of Power Management.
Just like with CTS, new CTS-D test cases must meet eligibility requirements and can only enforce the following:
Test cases that have not been covered by existing CTS test cases in AOSP
If you are interested in learning more about CTS-D, check out tutorials here on how to contribute to and utilize CTS-D. Note that the review process for new CTS-D test cases can take some time, so thanks for your patience. We hope you will give CTS-D a try soon. Let’s collaboratively make the Android experience even better!
As Apps Partnerships lead for Google Play, I have the amazing opportunity of meeting with many companies who share great ideas and feedback on how we can support you creating and growing successful businesses.
In this latest edition of Notes from Google Play, I want to share some of your work that has inspired us, alongside what is top of mind for me and our team. What sums it up for me is our focus on making Google Play work for everyone. It’s about making Play work better for all of you - the people behind apps and games - making it easier for you to grow apps and games business, and helping you better serve everyone, everywhere.
I will kick us off by sharing the story of OLIO, one of the many apps that has inspired me this year. OLIO is a community-driven app that is fighting to reduce food waste. The app provides a way for people to easily give away food to neighbors. Founders, Tessa Clarke and Saasha Celestial-One, had a goal to create local food sharing networks across the world and ensure nothing of value goes to waste. Having first launched the app in the UK, Tessa and Saasha’s belief in their core mission helped them expand the app to 62 countries and counting, partnering with global stores to help them reach zero waste along the way.
The success of the OLIO app is a tale of two women from different backgrounds, with the same dream, made for the benefit of everyone and our planet. For me, this is what it’s all about: ensuring that everyone is empowered to build a successful business that can benefit people around the globe.
So let me share more about some of my favorite tools and programs that we recently launched with this goal in mind.
Apps and games by everyone
Regardless of the size of your company, we want to make sure you have the insights and tools that enable you to make more informed decisions, and ultimately make it easy for you to build and improve your app or game business. Let’s take a look at privacy and security as an example, as this is a critical topic.
We have various tools andprograms to help you build safe and secure experiences for everyone and protect your business, including the Play Integrity API, Data Safety section, Privacy Sandbox on Android, and also the newly launched Google Play SDK Index.The index provides data and insights about more than 100 of the most widely used commercial SDKs. This can help you navigate third-party SDKs and align with Google Play policies, so that you make more informed decisions for your business and your users.
We also have programs designed for companies with various needs, from media companies building experiences across devices, to startups solving local problems in the first cohort of Appscale Academy in India. These 100 promising app innovators have already inspired us with their drive and creativity to build high-quality apps that serve and help people across India, and the world.
We’re also excited to continue investing in programs designed to help grow businesses both big and small. These include the Google Play Partner Program which launched in March and is designed to help larger games businesses reach their growth and performance goals. We also just opened submissions for the Indie Games Accelerator and Indie Games Festival programs. We were particularly inspired by the alumni of the 2021 edition, and you can hear directly from Jimjum Studios in Israel, who create games that encourage kindness, community building, and generosity, in the first episode of Google Play Coffee breaks:
Beyond the size of the company, apps and games are built and run by people. So we are continuously investing in programs to drive diversity in the ecosystem and empower the next generations of app and game makers. Programs like Change the Game and our investment in organizations driving positive change in the games industry are just a couple of the programs I’m particularly proud of.
Apps and games for everyone
We believe everyone should have easy access to great app and game experiences. This enables people to lead better lives, and it helps you grow your businesses.
In order to help with this, we’ve made some updates that make it easier for everyone to access apps and games at a price that is right for them, which in turn helps you better monetise your apps or games. For example, you asked for more flexibility and less complexity in how you sell your subscriptions, so we launched new subscription capabilities. You can now create multiple base plans and offers for each subscription, all while significantly reducing the cost and complexity of managing an ever-increasing number of SKUs. Whether your aim is to better connect with people that are new to your business, or to retain your loyal users, you have the ability to create offers for everyone.
We’ve also invested in new tools that help people pay for your apps and games using the methods that suit them best, helping to improve your monetisation. Google Play Commerce provides buyer support in over 170 countries, and we’ve further increased access by adding to our payment method library, which now includes over 300 local payment methods in 70 countries. We also made changes to help you better adapt to local purchasing power by adding the option to lower prices, starting at the equivalent of 5 US cents in any market.
Serving people better doesn’t only mean adapting pricing, but also optimizing your apps and games for the devices they are using, so they can get the best experience. Whether it’s phones, wearables, tablets or TVs. We introduced new tools and resources to help you create better experiences on large screens and launched Google Play Games beta, to help you expand your game’s reach to PCs.
Celebrating you
I started by highlighting OLIO as a business that was brought into existence by newcomers to the apps space, and yet managed to have a positive impact across the world. This is only one of so many inspiring examples out there. We’ve just launched #WeArePlay, a new campaign that celebrates you, the global community of people behind apps and games, and your unique stories. It represents teams of all sizes — some founded by longtime coders and others by tech newcomers, some based in big cities and others in smaller towns. These are short stories that tell personal journeys of making apps or games that are solving a problem or bringing joy to people everywhere.
I look forward to watching you all continue to build amazing app and game experiences, grow your businesses, and enthrall your users. Here’s to you and your achievements - let’s continue to celebrate every step forward and each small win. That’s what makes us all grow.
Posted by Patricia Correa, Director, Global Developer Marketing
Over 2.5 billion people come to Google Play every month to find apps and games created by millions of businesses from all over the world.
#WeArePlay celebrates you: the global community of people behind these businesses.
Each one of you creating an app or game has a different story to tell. Some of you have been coders since childhood, others are newbies who got into tech later in life. Some of you are based in busy cities, others in smaller towns. No matter who you are or how different your story is, you all have one thing in common - you have the passion to turn an idea into a business impacting people all over the world.
Now, and over the coming months, #WeArePlay celebrates you by sharing your stories.
We are kicking off the series with the story of Yvonne and Alyssa, the London-based mother and daughter duo who created Frobelles - a dress up game increasing representation of African and Caribbean hair styles.
You can now also discover the stories of friends Ronaldo, Carlos and Thadeu from Hand Talk Translator (Brazil - my home country!), art lover Zuzanna from DailyArt (Poland) and travel-loving couple Ina & Jonas from TravelSpend (Germany).
To all apps and games businesses - thank you for being a part of the Google Play community. Your dedication and ambition is helping millions of people learn, connect, relax, exercise, find jobs, give back, laugh, have fun, escape to fantasy lands, and so much more.
The Privacy Sandbox on Android aims to develop new solutions that preserve user privacy and enable effective, personalized advertising experiences for apps. Since our first developer preview, we've shared progress updates and continue to engage the industry on everything from the Developer Preview timeline, to Topics taxonomy, to SDK version management. We appreciate your feedback!
Today, we’re releasing Developer Preview 3, which includes APIs and developer resources for conversion measurement and remarketing use cases. In addition to the preview of SDK Runtime and Topics APIs released earlier, you can for the first time begin testing and evaluating impact on all key APIs for Privacy Sandbox on Android.
Event-Level and Aggregate Attribution Reporting APIs
These APIs allow developers to measure when an ad click or view event leads to a conversion, such as the download of a new game. They support key use cases for attribution across apps and the web, and improve user privacy by removing reliance on cross-party user identifiers.
This release includes a developer guide and sample apps to help you understand client- and server-side set up and interactions for key parts of the attribution reporting workflow, including:
Registering attribution source and trigger events.
Receiving event reports and unencrypted aggregatable reports.
(Note that aggregatable report encryption is not yet implemented. See the release notes for details.)
To help facilitate testing, the release also supports ADB commands to override reporting time windows. Refer to the API reference to learn more about the Android client APIs.
Custom Audience and Ad Selection APIs
Part of FLEDGE for Android, these APIs provide the building blocks to serve customized ads to users based on previous app engagement, without third-party data sharing. You’ll be able to:
Manage Custom Audience membership and observe how its parameter values may affect auction outcomes
Fetch JavaScript auction code from remote endpoints
If you’re just starting to explore the Developer Preview, please also review the supported features described in the SDK Runtime and Topics API developer guides.
If you need a refresher on key technologies for the Privacy Sandbox on Android, we recommend watching this overview video and reviewing the design proposals.
Get started with the Developer Preview
Today’s Developer Preview release provides the resources you need to begin early testing of features and share feedback. To get started developing, see instructions to set up the SDK and system images on the emulator or supported Pixel devices.
At Google Play we’re committed to helping developers of all sizes reach their full potential, and go further, faster. Today we’re opening submissions for our two annual programs supporting the indie game community, as they bring some of the most innovative titles to players worldwide.
If you are an indie games developer, check out our Accelerator and Festival programs, where you have the chance to boost your game’s visibility, get training, and tap into our community of gaming experts.
These programs are designed to help you grow no matter what stage you are in:
If you are a small games studio looking for help to launch or grow a new title, enter the Accelerator to get exclusive training by mentors and industry experts;
Or, if you have already created and launched a high quality game that is ready for the spotlight, enter the Festival in selected European countries, Japan or South Korea. for a chance to win promotions and reach new players.
After being selected as a Festival finalist and participating in the Accelerator in 2021, Co-founder of Jimjum Studios, Nimrod Kimhi said "being in the Accelerator probably saved us two years worth of mistakes." Read below to learn more about the programs.
Submissions are open until July 1st.
Supercharge your growth with mentorship & live masterclasses
If you’re an indie developer who is early in your journey - either close to launching a new game or have recently launched a title - this high-impact program is designed for you.
With the help of our network of gaming experts, the Indie Games Accelerator provides education and mentorship to help you build, launch and grow successfully.
Selected game studios will be invited to take part in the 10-week acceleration program starting in September 2022. This is a highly-tailored program for small game developers from across 70+ eligible countries. It includes a series of online masterclasses, talks and gaming workshops, hosted by some of the best in the industry.
You’ll also get the chance to meet and connect with other passionate developers from around the world who are looking to take their games to the next level.
Win promotions that put your indie game in the spotlight
If you have recently launched a new, high quality game on Google Play, enter your game to be showcased at the Indie Games Festival and win promotions.
Once again, we are hosting three international competitions for indie game developers from selected European countries, Japan or South Korea.
The Festival jury consists of both gaming experts and Googlers, who are charged with selecting creative indie games that are ready for the spotlight.
Top indie games will be featured during the online Festival finals, where you can get your game discovered by game industry experts and players worldwide. The winners will also get featured on Google Play, prizes and additional promotions such as campaigns worth 100,000 EUR.
Today we’re releasing the third Beta of Android 13, taking us into the final phase of our cycle where we’re focusing on polish and performance. With Android 13, we’ve built on our core themes of privacy and security, developer productivity, and tablet and large screen support.
There’s a lot to explore in Android 13, from privacy features like the new notification permission and photo picker, to productivity features like themed app icons and per-app language support, as well as modern standards like HDR video, Bluetooth LE Audio, and MIDI 2.0 over USB. We’ve also extended the newer updates we made in 12L, giving you better tools to take advantage of the 270+ million tablet and large screen devices in active use.
Beta 3 takes Android 13 to Platform Stability, which means that the developer APIs and all app-facing behaviors are now final. We’re thankful for all the feedback you’ve shared to help us get to this point! For developers, the focus is now on compatibility testing and quality as you prepare your apps for the official release later in the year!
You can get Beta 3 on your Pixel device by enrolling here for over-the-air updates. If you previously enrolled, you’ll automatically get today’s update. You can also try Android 13 Beta on select devices from several of our partners - learn more at android.com/beta. Read on for a quick look at how to get your app ready, and visit the Android 13 developer site for details.
Platform Stability
With Beta 3, Android 13 reaches Platform Stability, a milestone that means all app-facing behaviors and APIs, including the official API Level 33 SDK and NDK APIs, are now final. So from Beta 3, you can confidently develop and release your compatibility updates knowing that the platform won’t change.
We’re asking all app and game developers to start your final compatibility testing now and prepare to publish your compatibility updates as soon as possible ahead of the final release.
For all SDK, library, tools, and game engine developers, it’s even more important to start testing now and release your compatible updates as soon as possible -- your downstream app and game developers may be blocked until they receive your updates. So when you’ve released a compatible update, be vocal and let your developers know!
App compatibility
App compatibility means that your app runs as intended on a new version of the platform. With each release, we make integral changes to the platform that improve privacy and security and the overall user experience across the OS. These can affect your apps, so it’s important to test your app now, make any updates needed, and publish a compatible update to your users ahead of the final release. It’s a basic but critical level of quality that your users will appreciate as they explore what’s new in Android 13.
To test your app for compatibility, just install your production app from Google Play or other source onto a device running Android 13 Beta 3. Work through all of the app’s flows and watch for functional or UI issues. Review the behavior changes to focus your testing. Here are some changes to watch for:
Runtime permission for notifications - Android 13 introduces a new runtime permission for sending notifications from an app. Make sure you understand how the new permission works, and plan on targeting Android 13 (API 33) as soon as possible. More here.
Clipboard preview - Make sure your app hides sensitive data in Android 13’s new clipboard preview, such as passwords or credit card information. More here.
JobScheduler prefetch - JobScheduler now tries to anticipate the next time your app will be launched and will run any associated prefetch jobs ahead of that time. If you use prefetch jobs, test that they are working as expected. More here.
Also remember to test the libraries and SDKs in your app for compatibility. If you find any issues, try updating to the latest version of the library or SDK or reaching out to the developer for help.
Nearby device permission for Wi-Fi - Apps that manage a device's connections to nearby access points should use a new NEARBY_WIFI_DEVICES runtime permission for Wi-Fi operations like scanning, without needing access to device location. Some Wi-Fi APIs require your app to have this new permission. More here.
Granular media permissions - If your app targets Android 13 and reads media files from common data storage, you must request one or more of the new granular permissions instead of the READ_EXTERNAL_STORAGE permission. More here.
Permission changes for body sensors - Android 13 introduces "while in use" access for body sensors. If your app needs to access body sensor information from the background, it must declare a new BODY_SENSORS_BACKGROUND permission. More here.
Intent filters block non-matching intents - If your app sends an intent to an exported component of another app targeting Android 13 (API 33) or higher, it now needs to match an intent filter in the receiving app. More here.
Media controls derived from PlaybackState - Android 13 derives more media controls from PlaybackState actions, to show a richer set of controls that are consistent across device types. Make sure your app handles these changes. More here
Tablets and large-screens support
Android 13 builds on the tablet optimizations introduced in 12L, so as part of your testing, make sure your apps look their best on tablets and other large-screen devices. You can test with the large screens features by setting up an Android emulator in Android Studio, or you can use a large screen device from our Android 13 Beta partners. Here are some areas to watch for:
Taskbar interaction - Check how your app responds when viewed with the new taskbar on large screens. Make sure your app's UI isn't cut off or blocked by the taskbar. More here.
Multi-window mode - Multi-window mode is now enabled by default for all apps, regardless of app configuration, so make sure the app handles split-screen appropriately. You can test by dragging and dropping your app into split-screen mode and adjusting the window size. More here.
Improved compatibility experience - if your app isn’t optimized for tablets yet, such as using a fixed orientation or not being resizable, check how your app responds to compatibility mode adjustments such as letterboxing. More here.
Media projection - If your app uses media projection, check how your app responds while playing back, streaming, or casting media on large screens. Be sure to account for device posture changes on foldable devices as well. More here.
Camera preview - For camera apps, check how your camera preview UI responds on large screens when your app is constrained to a portion of the screen in multi-window or split-screen mode. Also check how your app responds when a foldable device's posture changes. More here.
You can read more about the tablet features in Android 13 and what to test here.
Get started with Android 13!
Today’s Beta release has everything you need to test your app and try the Android 13 features. Just enroll your Pixel device to get the update over-the-air. To get started, set up the Android 13 SDK.
You can also test your app with Android 13 Beta on devices from several of our partners. Visit android.com/beta to see the full list of partners, with links to their sites for details on their supported devices and Beta builds, starting with Beta 1. Each partner will handle their own enrollments and support, and provide the Beta updates to you directly. For even broader testing, you can try Android 13 Beta 3 on Android GSI images, and if you don’t have a device, you can test on the Android Emulator.
With close to half a billion cars, TVs, watches and laptops running on Android, it is more important than ever for apps to work seamlessly across every device. This year at I/O, we renewed our focus on form factors and announced major updates for Wear OS and Large Screens. To help you get to the bottom of what’s new, here are the three things you need to know about Form Factors at Google I/O:
#1: Building Wear OS and fitness apps is simpler than ever
At I/O we announced the Beta release of Compose for Wear OS, our modern declarative UI toolkit designed to help developers build exceptional user experiences for Wear OS. Compose for Wear OS shares the foundation and principles of Jetpack Compose, helping to simplify and accelerate UI development. Additionally, Compose for Wear OS offers the Material catalog with components that are optimized for the watch experience.
We’ve been developing Compose for Wear OS with open source community feedback and participation. Since the Developer Preview, we’ve added and improved a number of components such as navigation, scaling lazy lists, input and gesture support and many more. Compose for Wear OS is now feature complete for the 1.0 release coming soon and the API is stable - so you can begin building beautiful, production-ready apps.
Health Services—the power efficient and easy-to-use library for collecting real-time sensor data on smartwatches—will soon be available in beta and ready for production use. Health Services enables apps to take advantage of modern smartwatch architecture, thus helping conserve battery while still delivering high frequency data. Since the alpha release last year, we have been working hard to increase performance and improve the developer experience. We have also made some improvements to the API in response to your feedback.
If you have an existing health and fitness app for Wear OS you want to update, or have a completely new app in mind, we suggest you look at Health Service to provide the best experience for Wear 3 users and prepare your app for additional devices and sensors in the future. For example, this library will power all the Google- and Fitbit-branded health and fitness experiences on the recently announced Google Pixel Watch.
And, last but not least, we just launched Health Connect. With Health Connect, users will be able to securely store health and fitness data on their phone and connect and share that data with some of their favorite health and fitness apps. Samsung Health, Google Fit and Fitbit are integrating with Health Connect, along with many popular health and fitness apps. Health Connect is a common set of APIs for storing & sharing health data on Android phones. Developers can read from & write data to an on-device data store and we’ve standardized the schema and API behavior, making it easy for you to use the data. We know how important the privacy of each user’s health data is, so we centralized permissions and privacy controls - making it clear and simple for your users to manage and control this data.
#2: Google is all-in on tablets
Google is going big on large screens with innovations in hardware, optimizations in the operating system and a major investment in our app ecosystem. In the first quarter of this year, we saw active large screen users approaching 270 million, making it a great time to optimize for tablets, foldables and Chrome OS.
Since last I/O we launched Android 12L, a feature drop that makes Android 12 even better on large screens. With Android 13, we are including all of these improvements and more. Android 12L and 13 have a huge number of optimizations for large screens, including the task bar, multi-tasking, keyboard and mouse support, and a compatibility mode for applications. We also have exciting updates to guidance, testing and tools. To take the guesswork out of optimizing and testing your app for large screens, we created a set of Large Screen Quality guidelines and a number of Material Design Canonical Layouts. Our guidance is implemented in our Jetpack libraries, which bake in many of the most common tasks for Large Screen development, such as drag and drop.
Hardware innovation is a cornerstone of Google’s investment in large screens - this year and beyond. At I/O, we announced the Google Pixel tablet, coming in 2023. Plus, our partners are creating some amazing devices with tablets, Chromebooks, and foldables coming from companies like Samsung, Lenovo, and OPPO.
With the incredible hardware and operating system innovations, more apps than ever are optimizing for large screens. Apps like Facebook, TikTok, HBO Max and Zoom look great on large screens. Here at Google, we recognize the opportunity with large screens. Apps like YouTube, Google Maps, Google Photos, Chrome, and many of our most popular apps are rolling out large screen optimizations, with more to come.
These apps - and more - are available on the Play Store, where we have made some of our most impactful updates to date. We are committed to helping users find the best large-screen optimized apps in the Play Store with new large screens focused editorial content and separate reviews and ratings for large-screen applications. Plus, we are updating Google Play to look awesome on a tablet, Chromebook or foldable device.
#3: We’re here to support you!
To make your apps even better on large screens and Wear OS, we’ve created in-depth content for making your app work better across different types of inputs, screen sizes and devices.
In Android Studio Dolphin Beta and Electric Eel Canary we’ve added new features for Wear OS and Large screens to help you be more productive when developing and testing for different form factors. Read more
Looking to get started? Here’s all the amazing I/O content to help you on your way:
Posted by Krish Vitaldevara Director, Product Management, Play and Android Trust & Safety
We want to keep you updated on the privacy and security initiatives we shared earlier this year, so you can plan ahead and use new tools to safely build your business. In the past few months, we launched:
Google Play SDK Index to help you evaluate an SDK’s reliability and safety and make informed decisions about whether an SDK is right for your business and your users. See insights and usage data on over 100 of the most widely used commercial SDKs on Google Play.
The Data safety section on Google Play, helping users better understand your apps’ data safety practices. Developers have told us that this new feature helps them explain privacy practices with their users and build trust. If you haven't yet, complete your Data safety form by July 20th.
Enhancements to app integrity tools like Play App Signing to securely sign millions of apps on Google Play and help ensure that app updates can be trusted. Use Play App Signing to help protect your app signing key from loss or compromise with Google's secure key management service.
Play Integrity API to help protect your app, your IP, and your users from piracy and malicious activity. Use this API to help detect fraudulent and risky interactions, such as traffic from modified or pirated app versions and rooted or compromised devices.
And a new Target API Level policy to strengthen user security by protecting users from installing apps that may not have the expected privacy and security features.
What’s coming up
As part of our work with the industry to build more private advertising solutions, we’ve launched initial developer previews for Privacy Sandbox on Android. We have more developer previews coming soon and a beta later this year.
We continue to help developers update their apps before policy enforcement actions are taken. We’ve extended time to make changes, improved clarity of responses, and added new training materials. Recent tests of advanced Play Console warnings have also shown solid results. As we refine these features, we’ll expand them to more developers this year.
Thank you for your partnership in making Google Play a safe and trustworthy platform for everyone.
Posted by Dan Galpin, Developer Relations Engineer
Amidst the whirlwind of content at Google I/O, we shared huge announcements involving privacy, security, and the Androidplatform. Read on for the details, and don’t forget to watch the topic playlist on YouTube.
#1: Privacy Sandbox on Android
We recently released the first Privacy Sandbox on AndroidDeveloper Preview, so you can get an early look at the SDK Runtime and Topics API. This provides a path for new advertising solutions that improve user privacy without putting access to free content and services at risk.
You can conduct preliminary testing of these new technologies, evaluate how you might adopt them for your solutions, and share feedback with us. Learn more in the “Overview of the Privacy Sandbox in Android” session.
#2: Google Play SDK Index
The new Google Play SDK index is a public portal that lists over 100 of the most widely used commercial SDKs. It contains information like which app permissions the SDK requests, statistics on the apps that use them, and which version of the SDK is most popular, so you can evaluate if an SDK is right for your business and your users. Android Studio Electric Eel allows you to view dependency insights from Google Play SDK Index; if a specific version of a library has been marked as 'outdated' by its author, a corresponding Lint warning appears when viewing that dependency definition. Learn more on our blog post and watch the “What’s new in Google Play” and “What’s new in Android development tools” sessions.
The "What's new in Android Media" talk will help you build with modern standards like HDR video and Bluetooth LE Audio, while the "What's New in Android Camera" talk provides a … snapshot … of what we’re doing in CameraX, such as support for video capture and WYSIWYG camera controls.
Posted by Tom Grinsted - Group Product Manager, Google Play
Here at Google Play, we’re always working on new ways to help developers grow their businesses, whether that’s by increasing installs, improving engagement, or boosting monetization. So in case you missed it, here are the top 3 new ways to grow your business that we announced at this year’s Google I/O:
#1: Improved custom store listings
Custom store listingshave gotten a major update, giving you new ways to make a great first impression by showing the right message to each person.
You can now generate unique deep links to your custom listings, so you can show different listings to users depending on which channel or site they come from. And because Play Console provides analytics for each of your custom listings, you can see how effective each variation is and optimize them over time.
All developers can create up to 50 custom store listings, so you can create more tailored narratives for your users than ever before. With up to 5 experiments per listing, the opportunities for optimization are huge!
Custom store listings have gotten a major update, giving you new ways to improve your conversion rate.
#2: LiveOps open beta
LiveOps are self-service merchandising units in the Play Store that promote limited-time events, offers, and major updates for your game or app. Developers in our beta can submit content to help inspire installs, increase engagement, and drive sales.
Plus, they can now use deep links to drop users directly into the most relevant part of their app or game, then measure success with the new LiveOps reporting dashboard in Play Console. These reports give a granular view of the performance metrics of each event, displaying the results over time and by outcome – whether that’s acquisitions, opens, or updates.
Learn more about LiveOps and express interest in our beta program here.
Developers in our LiveOps beta can submit content to be featured on the Google Play Store.
#3: New flexible tools to grow your subscriptions
As subscription business models evolve, many developers have asked us for more flexibility and less complexity in how they sell subscriptions. In a major update, we launched new subscription capabilities, allowing you to configure multiple base plans and offers for each subscription. Acquire new subscribers, incentivize upgrades, and retain existing subscribers, by creating multiple offers supporting different stages of the subscription lifecycle, all while significantly reducing the cost and complexity of managing an ever-increasing number of SKUs.
For each subscription, you can now configure multiple base plans and offers, without needing to manage an ever-increasing number of SKUs.
Plus, you can now offer prepaid plans that give users access for a fixed amount of time, and make a great option for regions where pay-as-you-go is standard or for users not ready to commit to an auto-renewing plan. Users can easily extend their access period at any time before plan expiration, with a top-up in your app, or right on the Play Store subscription screen.
That was just three launches from a whole bunch of great updates to help you grow and thrive with Play. Want to see more? Be sure to catch the full playlist on Google Play from Google I/O.
Posted by Rebecca Gutteridge, Developer Relations Engineer on Android
Introduction
With the release of Android 12 and Material You, we provided documentation and guidance on dynamic color foundations, how to implement dynamic color in Jetpack Compose and a getting started codelab. But creating a scalable, personalized, and accessible app with dynamic color can feel like a daunting task. We talked to designers and developers on Google Chrome, and they offered to share some tips on how they approached it at scale for their Android app. Here’s what they suggest if you are considering adopting dynamic color in your app.
Where to start
Start by reviewing all your current screens in your app and identify your current colors, themes and surfaces. Chrome kicked off a design review and evaluated their color scheme. Material 3 encourages designers and developers to use color tokens which enable flexibility and consistency across an app by allowing designers to assign an element's color role in a UI, rather than a set value. This is particularly powerful when considering designing for light and dark themes and dynamic color.
Figure 1 : An example surface for Chrome, the Tab Switcher, identifying the color token for each element
Your app may already have a color token system, so reviewing how the new Material You dynamic color enabled color scheme matches your previous naming convention is an important exercise. Engineering should align with UX to review the new color token system with your mocks. This is also a good opportunity to review your current colors.xml, themes.xml and styles.xml.In particular check that your app correctly differentiates between Styles and Themes as well as correctly extending from base themes. It is also worth reviewing if there are redundant colors in your existing scheme or an opportunity to make a more consistent color scheme throughout your app. Dynamic color implementation with Compose is also available.
Accessibility
Ensuring your app’s color system is accessible is critical for designing for everyone and creating products that are inclusive to the widest possible audience. Dynamic color is committed to guaranteeing that the color selection model has accessibility requirements built in. Material 3 color schemes are defined by tonality rather than hue or hex value, this system of tonal palettes is central to making any color system accessible by default. Using a minimum 60 luminance spread in color pairings provides enough contrast to ensure accessibility standards.
Figure 2 : Combining color based on tonality, rather than hex value or hue, is one of the key systems that make any color output accessible.
Phase approach
When looking at implementation, consider this upgrade as a phased approach if needed, targeting the primary surfaces first and leveraging that dynamic color can be applied at a per activity level. This was how Chrome was able to update their app and used it as an opportunity to migrate some of their older UI app compat components to the modern Material 3 components, such as Top app bar.
How to support custom colors
Your app may have custom colors or brand colors that you do not want to change with the user’s preference. These can simply be added additionally as you are building out your color scheme. Alternatively you can import additional colors to extend your color scheme using the Material Theme Builder to create a unified color system. The theme builder includes a color harmonization feature that shifts the tone of a custom color to ensure that visual balance and accessible contrast is achieved when combined with user-generated colors.
Figure 3: Understand how to harmonize custom colors with the Material guidance.
For Chrome, here is a deep dive into two examples of where protected colors are important for them and how they approached it.
Publisher colors
It is important that Chrome allows for brands to keep their known colors and not impact that functionality when adopting dynamic color.
Publishers have the ability to set a publisher color using a metadata element in their html. The top toolbar is controlled using a decision tree to programmatically determine the toolbar color and icon color based on a series of cascading rules:
Incognito mode has the highest priority. If Incognito is enabled, the toolbar and icon colors follow the dark baseline palette.
For night theme, toolbar and icon colors follow the dark dynamic theme rather than the publisher color to ensure a consistently dark UI.
For day theme, the toolbar color is set to the publisher color, the icon color is either white or gray based on whether the publisher color is a dark or light color via util method.
If the publisher color is too bright or not specified, Chrome defaults to the light dynamic theme.
Incognito
In Incognito mode, the dark gray color scheme has a semantic importance and reassurance for users. Chrome decided to preserve and leverage their existing color system and not change it dynamically.
Figure 4: Incognito mode remains the same
To achieve this, Chrome defined non adaptive colors that map to hex values and adaptive colors that map to different non adaptive colors for day/night mode. For incognito mode, Chrome uses the dark non adaptive colors as they are easily recognized by the users as incognito. With these adaptive colors, Chrome created a baseline theme.
The table below shows what their background colors look like after applying dynamic colors:
Themes and Theme Overlays
One thing to consider for adhering to theme best practices, is to leverage Theme Overlays properly. The Chrome team used this opportunity to refactor their themes and leveraged the power of Theme Overlays for a given activity. At times Chrome saw that full themes were being used where a ThemeOverlay would be more appropriate. Dynamic color and Material3 encourages better code hygiene.
Take a look at this example, previously the theme for full screen dialogs inherited from a full theme. This overrode all the attributes from the activity theme, undoing the dynamic colors or any overrides that are applied at the activity level. With the dynamic color work, the team became more deliberate in how they define and use their theming.
This section shares some key lessons that Chrome’s designers applied to successfully create an intentional and unified theme
Create a unified design system: Material 3 and dynamic color gives the opportunity to reconcile your app’s themes. For Chrome that meant reconciling their light and dark theme and removing fragmentation based on elevation.
Identifying how to migrate existing color system: Understand the role of your current color system and tokens, if applicable, and how they map onto the M3 color tokens.
Use accent colors meaningfully: Material 3’s accented color tokens are incredibly powerful and useful, iterate on how best to use them.
Phased approach: Focus on a few surfaces first. Dynamic color is increasingly part of the user’s expectation of their device, so work out which surfaces make sense to adopt first and then iterate and expand to more surfaces.
Work closely with your engineers from the beginning: Share designs as soon as you have them with your engineers. Chrome designers asked questions to understand how Chrome was built so they could establish how color would be applied and which components might be affected. This will help you make better informed decisions on which surfaces/components are updated since there could be many dependencies in your app.
Create custom tokens: If you need to use dynamic colors that are not part of the out of the box color system, create a custom color token that extends your color theme.
Recommendations from Google Chrome developers
This section shares some key lessons that Chrome’s developers applied to successfully migrate
Have a rigorous theme code hygiene: Create a baseline set of colors without dynamic for instances where dynamic color is not applied, eg, incognito mode and then extend with theme and theme overlays.
Understand how to use surface colors: Surfaces are treated with “elevation” to allow differentiation from the background and layered elements like app bars, and other navigation elements; this may be a paradigm shift for some apps. Surface colors are calculated at runtime, so there is no resource/color/macro to retrieve them currently. Chrome decided to create a utility method to calculate surface colors using `ElevationOverlayProvider`. However, this is only available to use programmatically while we also needed to implement dynamic color for many layouts in bulk. For this purpose, they created a custom Drawable that can draw a surface color based on a provided elevation value. One drawback of this approach is that a legacy pre-dynamic colors version of each drawable must be maintained for compatibility with old Android versions.
Importance of using Activity context: It’s important to use the Activity context to inflate views as the Activity has the theme with the dynamic color overlay applied.
Choice of method to get colors: Usage of ‘Resources#getColor(int)’ was very common in Chrome’s codebase because they needed to support older Android versions. However, to support dynamic color, the `#getColor` method should be able to resolve the color resources against the theme. So, Chrome migrated the `Resources#getColor` calls to `Context#getColor`.
Macros: Chrome uses semantic color names to have a unified color system throughout the app. Before the dynamic color adoption, a semantic color would look something like this:
@color/default_text_color_light: Color used for primary text
→ @color/default_text_color_dark/@color/default_text_color_light (adaptive to night mode)
→ @color/modern_grey_900/@color/modern_white
→ #1F1F1F / #FFFFFF
Your app may already have a semantic color system and so migrating adds additional considerations. For Chrome they wanted to preserve their semantic colors. In collaboration with UX, they translated the existing color palette to the Material color roles/attributes. Their first idea was to point to these attributes from the existing semantic colors. For example, @color/default_text_color from the example above would look like this: <color name="default_text_color">?attr/colorOnSurface</color>. However, the @color resource cannot point to an ?attr. The next idea was to convert all semantic `@color`s to `?attr`s with the same names. This approach also caused issues as they needed to add all the attributes to their themes and there are many activities, themes and entry points to Chrome, so it would be challenging to maintain. Finally, they adopted the newly introduced <macro> tag. Macros are much like C/C++ macros but for Android resources: they are replaced with whatever they point to at build time. So semantic colors became semantic macros, for example, <macro name="default_text_color">?attr/colorOnSurface</macro>. This made it possible to implement dynamic colors at bulk. One limitation of macros is that they cannot be accessed programmatically, but Chrome added static utility methods to work around this. The macro tag is now available in Android Studio Canary.
Dynamic color is coming to more Android 12 phones globally, including devices by Samsung, OnePlus, Oppo, Vivo, realme, Xiaomi, Tecno, and more! As you work with dynamic color in your app, we’d love to get your feedback via the Material Android issue tracker. Happy coloring!
Posted by Nick Butcher, Developer Relations Engineer
Our goal is to make developing beautiful and engaging Android apps as fast and easy as possible. We want to take on the complex parts of building apps so that you can focus on your app’s features and deliver high quality experiences to your users.
We call this approach Modern Android Development (or MAD for short!) and deliver it through a suite of tools, libraries and guidance. At Google I/O we announced a number of updates and additions to our MAD offerings; here’s a recap of the three largest announcements.
#1 Compose 1.2 Beta
Jetpack Compose 1.2 reaches the first Beta, which means the API is stable. We continue to build out our roadmap, bringing the APIs you need to support more advanced use cases like downloadable fonts, LazyGrids, window insets, nested scrolling interop, and more tooling support with features like LiveEdit, Recomposition counts in the Layout Inspector and Animation Preview. Learn more about how developers like Airbnb are improving their productivity with Jetpack Compose, and check out what else is new in Compose.
#2 Baseline Profiles
Baseline profiles allow you to embed a profile to guide the Android Runtime about which code paths should be pre-compiled rather than interpreted, which could dramatically impact critical user journeys like app startup. This is especially significant when using unbundled libraries like Jetpack Compose which don’t benefit from optimizations in platform code.
Many Jetpack libraries (including Jetpack Compose) already ship baseline profiles, but you can learn how to add them to your own apps and libraries to boost their performance. We've seen up to 40% faster app startup times thanks to adding baseline profiles alone, no other code changes required!
#3 Live Edit
With Live Edit you can edit composables and view those changes in real time, on the Compose Preview or on physical devices or emulators, enabling rapid iteration. Live Edit is an opt-in experimental feature in Android Studio Electric Eel, with a number of limitations. Please try it out and provide your feedback.
Those were the top three announcements about Modern Android Development at Google I/O. To learn more, check out the full playlist of talks and workshops.
With the recent launch of the Play Integrity API, more developers are now taking action to protect their games and apps from potentially risky and fraudulent interactions.
In addition to useful signals on the integrity of the app, the integrity of the device, and licensing information, the Play Integrity API features a simple, yet very useful feature called “nonce” that, when correctly used, can further strengthen the existing protections the Play Integrity API offers, as well as mitigate certain types of attacks, such as person-in-the-middle (PITM) tampering attacks, and replay attacks.
In this blog post, we will take a deeper look at what the nonce is, how it works, and how it can be used to further protect your app.
What is a nonce?
In cryptography and security engineering, a nonce (number once) is a number that is used only once in a secure communication. There are many applications for nonces, such as in authentication, encryption and hashing.
In the Play Integrity API, the nonce is an opaque base-64 encoded binary blob that you set before invoking the API integrity check, and it will be returned as-is inside the signed response of the API. Depending on how you create and validate the nonce, it is possible to leverage it to further strengthen the existing protections the Play Integrity API offers, as well as mitigate certain types of attacks, such as person-in-the-middle (PITM) tampering attacks, and replay attacks.
Apart from returning the nonce as-is in the signed response, the Play Integrity API doesn’t perform any processing of the actual nonce data, so as long as it is a valid base-64 value, you can set any arbitrary value. That said, in order to digitally sign the response, the nonce is sent to Google’s servers, so it is very important not to set the nonce to any type of personally identifiable information (PII), such as the user’s name, phone or email address.
val nonce: String = ...
// Create an instance of a manager.
val integrityManager =
IntegrityManagerFactory.create(applicationContext)
// Request the integrity token by providing a nonce.
val integrityTokenResponse: Task<IntegrityTokenResponse> =
integrityManager.requestIntegrityToken(
IntegrityTokenRequest.builder()
.setNonce(nonce) // Set the nonce
.build())
Java:
String nonce = ...
// Create an instance of a manager.
IntegrityManager integrityManager =
IntegrityManagerFactory.create(getApplicationContext());
// Request the integrity token by providing a nonce.
Task<IntegrityTokenResponse> integrityTokenResponse =
integrityManager
.requestIntegrityToken(
IntegrityTokenRequest.builder()
.setNonce(nonce) // Set the nonce
.build());
Unity:
string nonce = ...
// Create an instance of a manager.
var integrityManager = new IntegrityManager();
// Request the integrity token by providing a nonce.
var tokenRequest = new IntegrityTokenRequest(nonce);
var requestIntegrityTokenOperation =
integrityManager.RequestIntegrityToken(tokenRequest);
Native:
/// Create an IntegrityTokenRequest object.
const char* nonce = ...
IntegrityTokenRequest* request;
IntegrityTokenRequest_create(&request);
IntegrityTokenRequest_setNonce(request, nonce); // Set the nonce
IntegrityTokenResponse* response;
IntegrityErrorCode error_code =
IntegrityManager_requestIntegrityToken(request, &response);
The value of the nonce field should exactly match the one you previously passed to the API. Furthermore, since the nonce is inside the cryptographically signed response of the Play Integrity API, it is not feasible to alter its value after the response is received. It is by leveraging these properties that it is possible to use the nonce to further protect your app.
Protecting high-value operations
Let us consider the scenario in which a malicious user is interacting with an online game that reports the player score to the game server. In this case, the device is not compromised, but the user can view and modify the network data flow between the game and the server with the help of a proxy server or a VPN, so the malicious user can report a higher score, while the real score is much lower.
Simply calling the Play Integrity API is not sufficient to protect the app in this case: the device is not compromised, and the app is legitimate, so all the checks done by the Play Integrity API will pass.
However, it is possible to leverage the nonce of the Play Integrity API to protect this particular high-value operation of reporting the game score, by encoding the value of the operation inside the nonce. The implementation is as follows:
The user initiates the high-value action.
Your app prepares a message it wants to protect, for example, in JSON format.
Your app calculates a cryptographic hash of the message it wants to protect. For example, with the SHA-256, or the SHA-3-256 hashing algorithms.
Your app calls the Play Integrity API, and calls setNonce() to set the nonce field to the cryptographic hash calculated in the previous step.
Your app sends both the message it wants to protect, and the signed result of the Play Integrity API to your server.
Your app server verifies that the cryptographic hash of the message that it received matches the value of the nonce field in the signed result, and rejects any results that don't match.
The following sequence diagram illustrates these steps:
As long as the original message to protect is sent along with the signed result, and both the server and client use the exact same mechanism for calculating the nonce, this offers a strong guarantee that the message has not been tampered with.
Notice that in this scenario, the security model works under the assumption that the attack is happening in the network, not the device or the app, so it is particularly important to also verify the device and app integrity signals that the Play Integrity API offers as well.
Preventing replay attacks
Let us consider another scenario in which a malicious user is trying to interact with a server-client app protected by the Play Integrity API, but wants to do so with a compromised device, in a way so the server doesn’t detect this.
To do so, the attacker first uses the app with a legitimate device, and gathers the signed response of the Play Integrity API. The attacker then uses the app with the compromised device, intercepts the Play Integrity API call, and instead of performing the integrity checks, it simply returns the previously recorded signed response.
Since the signed response has not been altered in any way, the digital signature will look okay, and the app server may be fooled into thinking it is communicating with a legitimate device. This is called a replay attack.
The first line of defense against such an attack is to verify the timestampMillis field in the signed response. This field contains the timestamp when the response was created, and can be useful in detecting suspiciously old responses, even when the digital signature is verified as authentic.
That said, it is also possible to leverage the nonce in the Play Integrity API, to assign a unique value to each response, and verifying that the response matches the previously set unique value. The implementation is as follows:
The server creates a globally unique value in a way that malicious users cannot predict. For example, a cryptographically-secure random number 128 bits or larger.
Your app calls the Play Integrity API, and sets the nonce field to the unique value received by your app server.
Your app sends the signed result of the Play Integrity API to your server.
Your server verifies that the nonce field in the signed result matches the unique value it previously generated, and rejects any results that don't match.
The following sequence diagram illustrates these steps:
With this implementation, each time the server asks the app to call the Play Integrity API, it does so with a different globally unique value, so as long as this value cannot be predicted by the attacker, it is not possible to reuse a previous response, as the nonce won’t match the expected value.
Combining both protections
While the two mechanisms described above work in very different ways, if an app requires both protections at the same time, it is possible to combine them in a single Play Integrity API call, for example, by appending the results of both protections into a larger base-64 nonce. An implementation that combines both approaches is as follows:
The user initiates the high-value action.
Your app asks the server for a unique value to identify the request
Your app server generates a globally unique value in a way that malicious users cannot predict. For example, you may use a cryptographically-secure random number generator to create such a value. We recommend creating values 128 bits or larger.
Your app server sends the globally unique value to the app.
Your app prepares a message it wants to protect, for example, in JSON format.
Your app calculates a cryptographic hash of the message it wants to protect. For example, with the SHA-256, or the SHA-3-256 hashing algorithms.
Your app creates a string by appending the unique value received from your app server, and the hash of the message it wants to protect.
Your app calls the Play Integrity API, and calls setNonce() to set the nonce field to the string created in the previous step.
Your app sends both the message it wants to protect, and the signed result of the Play Integrity API to your server.
Your app server splits the value of the nonce field, and verifies that the cryptographic hash of the message, as well as the unique value it previously generated match to the expected values, and rejects any results that don't match.
The following sequence diagram illustrates these steps:
These are some examples of ways you can use the nonce to further protect your app against malicious users. If your app handles sensitive data, or is vulnerable against abuse, we hope you consider taking action to mitigate these threats with the help of the Play Integrity API.
To learn more about using the Play Integrity API and to get started, visit the documentation at g.co/play/integrityapi.
How Compose enables Airbnb to create better host and guest experiences
Since 2007, Airbnb has grown to connect more than 4 million hosts with more than 1 billion guests across the globe. One of the reasons behind the app’s success is that its developers aim to achieve engineering excellence by focusing on two main principles: using technology that sparks innovative development and empowering the engineers behind the work.
Jetpack Compose, Android’s modern UI-building toolkit, directly supports both of Airbnb’s development principles. Compose provided a solid foundation for adaptable, quality engineering and reduced boilerplate code, so developers could focus on delivering a great user experience — and advance their two-fold pursuit of engineering excellence.
Airbnb started testing Compose in 2020 when it was in developer preview. As an early adopter, the Airbnb team was eager use the various new features and simplify their workflow. Now, having gained confidence using Compose in production, Airbnb engineers continue to be satisfied with how it improved their development process.
Equipping engineers for success
Compose’s deterministic testing helped ensure Airbnb’s engineers had tight control over the UI tests they ran and eliminated common flakiness, thereby strengthening their confidence in the quality of every part of their app and the user experiences they were creating. Engineers can now also use Compose to test animations they previously couldn't.
Similarly, Airbnb developers used Compose to add automated screenshot tests to their codebase. Because they didn’t need to write the code for screenshot testing, engineers could go straight into using it to catch bugs and regressions. This gave them more time to review and guarantee feature functionality and UI appearance across a variety of devices.
Compose is great to use alongside Views. This interoperability made it easy for Airbnb engineers to onboard and test the new UI toolkit at their own pace, so they were able to experience the benefits of Compose without having to migrate entire features.
These engineering improvements gave them the solid technical foundations they needed to serve users in fresh and improved ways.
Engineering efficiencies improve user experiences
Airbnb keeps hosts and guests at the heart of their decisions. The engineering team was excited to adopt Compose when they learned about how it would enable them to more easily and efficiently produce UI, resulting in better experiences for their end users.
Because Compose made Airbnb’s features require significantly less code to write and manage, the Airbnb team boosted their efficiency. All of this meant the team could focus its energy on executing the complex tasks involved in developing the innovative features that could best serve users.
Because their features now require less code, the Airbnb team will be able to slow the growth of their app size in the long run. Providing a smaller app is important to Airbnb as an organization with users across the globe that looks to ensure all hosts and guests can easily download and access their app — especially those with older devices or logging on from countries with high data costs.
Using Compose’s engineering enhancements, the Airbnb team was able to put user needs first.
Improve developer productivity with Compose
Compose simplified UI development to allow Airbnb engineers the freedom to focus on more dynamic and innovative features that benefit the app’s hosts and guests.
Learn how you can improve your team’s productivity with Jetpack Compose.
Posted by Paris Hsu, Product & Design, Android and
Don Turner, Developer Relations Engineer, Android
The Now in Android app is now on GitHub!
For two years, 'Now in Android' has been a popular blog and YouTube series, providing you with the latest and greatest developer news from the Android team. Starting today, you can check out the alpha version of the Now in Android app on GitHub! 🎉
The app has two goals:
Firstly, it showcases best practices, opinionated designs, and solutions to complex real-world problems which other sample apps don’t handle. It does so with an open source implementation of a real world app.
Secondly, it helps you (the developer) keep up to date with the areas of Android development which interest you most. It is a working app planned for publication on the Play Store.
Remote/local data synchronization scheduled using WorkManager with exponential backoff
As well as these features, we are also documenting the learning journeys we took to certain decisions with the app's design and implementation. Check out our first journey on the app's Architecture here.
The Now in Android screens adapt based on device screen size
Since this is an alpha release, we expect that there will be bugs and missing features, and we would greatly appreciate your feedback. We have some exciting features planned, such as user authentication and loading data from a real backend. We can’t wait for you to check out the app and let us know what you think!
Finally, if you want to learn about the tools we used to build the app and how we target multiple screen sizes, check out these talks from this year's Google I/O:
Shobana Radhakrishnan, Senior Director of Engineering - Google TV
Paul Lammertsma, Developer Relations Engineer
Today, there is more entertainment content available than ever before. In fact, our research shows a third of U.S. households now watch more than 25 hours of TV every week. As the role of TV continues to evolve, it’s our goal to build a tailored TV experience that gives users easy access to the entertainment they love.
We’re excited about the future of Android TV OS, now with over 110 million monthly active devices, including millions of Google TVs. Android TV and Google TV are available on over 300 partners worldwide, including 7 of the 10 largest smart TV OEMs and over 170 pay TV operators. And thanks to the hard work of our developer community, there are more than 10,000 apps available on TV, with more being added everyday.
Since last year’s I/O, we’ve continued our commitment to enable you to build better and more engaging experiences on Android TV OS. In addition to platform updates, new features, like expanded integrations with the Live tab, offer opportunities for users to better engage with your content. And if you haven’t begun using WatchNext API, take a moment to learn how to add it to your app to make your content more discoverable and accessible.
Today, we are introducing new features and tools on Android 13 that focus on overall performance & quality, improve accessibility, and enable multitasking.
Performance & quality: To help build for the next generation of TVs, we’re introducing new APIs to help you better detect a user’s settings and give them the best experience for their device. AudioManager allows your app to anticipate audio routes and precisely understand which playback mode is available. Integrating your app correctly with MessiaSession allows Android TV to react to HDMI state changes in order to save power and signal that content should be paused.
Accessibility: To improve how users interact with their TV, we’ve added support for different keyboard layouts in the InputDevice API. Game developers can also reference keys by their physical location to support different layouts of physical keyboards, such as QWERTZ and AZERTY keyboards. A new system-wide accessibility preference also allows users to enable audio descriptions across apps.
Multitasking: TVs are now used for more than just watching media content. In fact, we often see users taking calls or monitoring cameras in a smart home. To help with multitasking, an updated picture in picture API will be supported in Android 13 with the APIs from core Android. Picture in picture on the TV supports an expanded mode to show more videos from a group call, a docked mode to avoid overlaying content on other apps, and a keep-clear API to prevent overlays from concealing important content in full-screen apps.
Android 13 Beta for TV is available now, allowing you to test your apps and provide feedback on the latest release. Thank you for your continued support of Android TV OS. We can’t wait to see what amazing and innovative things you continue to build for the big screen.
Posted by Jennifer Chui, Technical Program Manager and Rod Lopez, Product Manager
At Google, our work in cars has always been guided by our vision of creating safe and seamless connected experiences. This work would not be possible without developers like you. We’re excited to share some of our combined accomplishments from this past year, and introduce new updates that will make it easier for you to provide users with an even better experience in the car.
Android Auto continues to grow and scale, with compatible vehicles now numbering over 150 million worldwide. An increasing number are also wirelessly compatible, and with the newly introduced Motorola MA1 adapter, even more drivers now have access to a wireless experience. In addition, our new design for Android Auto brings split-screen functionality to every screen, keeping navigation and media front and center while also providing room for prominent notification widgets.
Android Automotive OS with Google built-in also has exciting updates. Beyond the continued expansion of carmakers that are bringing more car models to the market, we’ve also been hard at work enabling more parked experiences to take advantage of the large screens that many AAOS cars offer. From more video streaming apps like Epix Now and Tubi to future features like browsing and cast, there’s much to look forward to, and given minimal effort is required to translate your large screen tablet apps into a parked car experience, it’s now easier than ever to reach users in the car.
We know that developing for cars can be complex, which is why we’re focused on making developing across Android for Cars as easy as possible. We’ve seen strong momentum with our Car App Library with over 200 apps published to date, and beyond enriching the navigation feature set with version 1.3, we’re also excited to share that all developers can now publish apps in supported categories directly to production for both Android Auto and Android Automotive OS. We’ve also created new templates and expanded our supported app categories, adding driver apps like Lyft to the navigation category, and replacing the parking and charging categories with a comprehensive point of interest (POI) category to include apps like MochiMochi and Fuelio.
We’re also introducing several new features to help you build more powerful media apps on Android Auto. Media recommendations working side by side with Google Assistant helps users easily discover and quickly play relevant content based on their preferred music provider at the click of a button. To surface recommendations from your app, integrate with this API.
For long form content such as podcasts and audiobooks, you can now introduce a progress bar that shows how much of the content the user has previously listened to, and with our new single item styling API, you can now assign content items individually as either list or grid as opposed to categorically, to easily combine them in the same content space.
We’re grateful to have you on the journey with us as we seek to create safer, more seamless connected experiences in cars. Be sure to check out our Google I/O technical session above, and as always, you can get help from the developer community at Stack Overflow using the android-automotive and android-auto tags. We can’t wait to see what you build next, and where the road takes you.
Posted by Kseniia Shumelchyk, Developer Relations Engineer, and John Nichol, Tech Lead of Compose for Wear OS
Today we’re launching the Beta release of Compose for Wear OS, our modern declarative UI toolkit designed to help developers create beautiful user experiences for Wear OS.
Compose for Wear OS adds support for watch optimized components that embrace the latest Material design for Wear OS. The components are built on top of core Compose libraries and the toolkit leverages Modern Android Development, helping accelerate the development process as a whole.
With this Beta release, Compose for Wear OS is feature complete for the 1.0 release coming later this year, and has what you need to build production-ready apps. It also means the API is stable; moving forward we'll focus on performance and polishing existing components for the 1.0 release.
In the Beta
We’ve been hard at work since last I/O to bring the best of Jetpack Compose to Wear OS, engaging with the community via Slack, gathering developer feedback on APIs, components and tooling. As a result, we’ve improved a number of components such as navigation, scaling lazy lists, input and gesture support and much more.
You asked for user input components, so we’ve added different composables that you can tailor for your watch app:
Picker lets the user select an item from a scrolling list. By default, the list of selectable items is repeated 'infinitely' in both directions, to give the impression of a rotating cylinder seen from the side. Interestingly, Picker uses ScalingLazyColumn implementation underneath and has helped to develop and hone a lot of advanced ScalingLazyColumn features.
Slider allows users to make a selection from a range of values and is ideal for adjusting settings like font size or brightness.
Stepper is a full-screen control component that allows users to make a selection from a range of values. For example, users can control the volume of their headphones.
🆕 Dialogs
We’ve added full-screen Alert and Confirmation composables that can be used as either navigation destinations or traditional full-screen Dialogs, which will be layered over any other content. Dialog supports swipe-to-dismiss and will reveal the parent content in the background during the swipe gesture.
We added CircularProgressIndicator, a progress indicator optimized for watch screens to display progress by animating an indicator along a circular track in a clockwise direction.
There are several options for how CircularProgressIndicator can be used: either to show infinite progress or to express the proportion of completion of an ongoing task. Progress Indicators allow a gap in the circular track which leaves room for other content, for instance TimeText if used in full-screen.
🆕 Page Indicator
To help you implement pagination, the UI toolkit provides a HorizontalPageIndicator component that represents the total number of pages and selected page.
Depending on the screen shape, the HorizontalPageIndicator will provide a form factor- specific visual indication of which page is active and how far through the pages it is.
Improvements
ScalingLazyColumn: improved the default behavior to be consistent with Material design for Wear OS, such as updating the scaling parameters, default extra padding and taking the size from the size of its contents.
Scaffold: added PageIndicator slot to guarantee correct positioning on the round screen.
Navigation: ensured feature parity with Compose Navigation and adding support for edge swiping to enable a great experience on full-screen and page scrolling.
Curved elements: added CurvedModifiers and a new DSL which enables developers to use concepts that make sense for a curved world like radial, angular, sweep, (anti-) clockwise, inner/outer. CurvedLayout is the bridge between the linear and curved worlds and curvedComposable can be used to introduce traditional composable components when it makes sense to do so.
With these recent additions, the Compose Material catalog for Wear OS now has more components than are available with View-based layouts and provides out-of-the-box implementation of the new Wear OS design guidelines.
Tools
Android Studio Electric Eel provides the latest features for the best experience developing with Compose for Wear OS:
Editor and tooling support improving autocomplete and editor actions
Wear OS-specific Composable Preview
🆕 Live edit for real-time debugging support
🆕 Compose for Wear OS project template
Horologist
Today we’re also announcing the release of Horologist, a Google open source project which provides a set of Wear libraries that supplement the functionality provided by Compose for Wear OS and other Wear OS APIs.
Media UI components including playback control and volume screens
Material date and time pickers
Navigation-aware Scaffold with TimeText and PositionIndicator that stay in sync with scrolling and navigation screen changes.
Horologist will grow to provide developers with additional tools for building great Wear OS apps across differentexperiences. Check out the Horologist on Github to provide feedback and contribute general functionality that could be useful for Wear developers - and stay tuned for upcoming releases!
Get Started
Many of the development principles for mobile Compose apply to Compose for Wear OS, so if you’re unfamiliar with the UI toolkit start with Jetpack Compose basics.
We’ve prepared a set of materials to help you get started with Compose for Wear OS:
Now that Compose for Wear OS has reached Beta it’s a great time to get started with Compose to quickly bring your app to life or refresh your existing UI. For more information about building apps for Wear OS, check out the developer site.
We’d love to hear from you about your experiences using Compose for Wear OS and what you are able to build! Join the discussion in the Kotlin Slack#compose-wear channel and please keep providing feedback on the issue tracker.
Posted by Yafit Becher, Product Manager and Ray Brusca, Strategic Partnerships Manager
App developers rely on SDKs to integrate key functionality and services for their apps and games. SDKs are essential building blocks, but developers have shared that it can be hard to figure out which SDKs are reliable and safe to use. So helping developers, like you, make informed decisions about SDKs is part of keeping Google Play a safe, trusted space for billions of people.
In 2020, we launched Google Play SDK Console to give SDK providers crash reporting, usage statistics, and a way to communicate critical issues to app developers through Google Play Console and Android Studio. Today, we’re taking another step to increase communication and transparency by launching Google Play SDK Index, a new public portal that lists over 100 of the most widely used commercial SDKs, and insights about each one.
Google Play SDK Index shows reliability and safety signals so you can decide if an SDK is right for your business and your users.
You can search for an SDK or look through a category, like Advertising and monetization or Analytics. For each SDK listing, Google Play SDK Index combines usage data from Google Play apps with SDK code detection to provide insights designed to help you decide if an SDK is right for your business and your users. You can see:
Which Android app permissions the SDK may request
If the SDK provider is committed to ensuring that their SDK’s code follows Google Play policies
Version adoption rates
Retention metrics, and more
SDK providers can also share key information with you for the SDKs that they registered on Google Play SDK Console, like:
Which SDK version is outdated or has critical issues
Links to data safety guidance on what data the SDK collects and why, to help you fill out your app’s Data safety form.
No matter where you’re at in your development lifecycle, we hope you find Google Play SDK Index useful in making informed SDK choices. Stay tuned for more updates as we add additional data points, categories, and volume of SDKs..
Posted by Amanda Alexander, Product Manager, Android
Android Jetpack is a key pillar of Modern Android Development. It is a suite of over 100 libraries, tools and guidance to help developers follow best practices, reduce boilerplate code, and write code that works consistently across Android versions and devices so that you can focus on building unique features for your app.
Most apps in Google Play use Jetpack for app architecture. Today, over 90% of the top 1000 apps use Jetpack.
Below we’ll cover updates in three major areas of Jetpack:
Architecture Libraries and Guidance
Performance Optimization of Applications
User Interface Libraries and Guidance
And then conclude with some additional key updates.
1. Architecture Libraries and Guidance
App architecture libraries and components ensure that apps are robust, testable, and maintainable.
Data Persistence
Room is the recommended data persistence layer which provides an abstraction layer over SQLite, allowing for increased usability and safety over the platform.
In Room 2.4, support for Kotlin Symbol Processing (KSP) moved to stable. KSP showed a 2x speed improvement over KAPT in our benchmarks of Kotlin code. Room 2.4 also adds built-in support for enums and RxJava3 and fully supports Kotlin 1.6.
Room 2.5 includes the beginning of a full Kotlin rewrite. This change sets the foundation for future Kotlin-related improvements while still being binary compatible with the previous version written in the Java programming language. There is also built-in support for Paging 3.0 via the room-paging artifact which allows Room queries to return PagingSource objects. Additionally, developers can now perform JOIN queries without the need to define additional data structures since Room now supports relational query methods using multimap (nested map and array) return types.
@Query("SELECT * FROM Artist
JOIN Song ON Artist.artistName =
Song.songArtistName")
fun getArtistToSongs(): Map<Artist, List<Song>>
Relational query methods using multimap return types
Database migrations are now simplified with updates to AutoMigrations, with added support for additional annotations and properties. A new AutoMigration property on the @Database annotation can be used to declare which versions to auto migrate to and from. And when Room needs additional information regarding table and column modifications, the @AutoMigration annotation can be used to specify the inputs.
Database(
version = MyDb.LATEST_VERSION,
autoMigrations = {
@AutoMigration(from = 1, to = 2,
spec = MyDb.MyMigration.class),
@AutoMigration(from = 2, to = 3)
}
)
public abstract class MyDb
extends RoomDatabase {
...
DataStore
The DataStore library is a robust data storage solution that addresses issues with SharedPreferences. To better understand how to use this powerful replacement for many SharedPreferences use cases, you can check out a series of videos and articles in Modern Android Development Skills: DataStore which includes guidance on testing your app’s usage of the library, using it with dependency injection, and migrating from SharedPreference to Proto DataStore.
Incremental Data Fetching
The Paging library allows you to load and display small chunks of data to improve network and system resource consumption. App data can be loaded gradually and gracefully within RecyclerViews or Compose lazy lists.
Paging 3.1 provides stable support for Rx and Guava integrations, which provide Java alternatives to Paging’s native use of Kotlin coroutines. This version also has improved handling of invalidation race conditions with a new return type, LoadResult.Invalid, to represent invalid or stale data. There is also improved handling of no-op loads and operations on empty pages with the new onPagesPresented and addOnPagesUpdatedListener APIs.
The Navigation library is a framework for moving between destinations in an app.
The Navigation component is now integrated into Jetpack Compose via the new navigation-compose artifact which allows for composable functions to be used as destinations in your app.
The Multiple Back Stacks feature has improved to make it easier to remember state. NavigationUI now automatically saves and restores the state of popped destinations, meaning developers can support multiple back stacks without any code changes.
Large screen support was enhanced with the navigation-fragment artifact providing a prebuilt implementation of a two-pane layout in AbstractListDetailFragment. This fragment uses a SlidingPaneLayout to manage a list pane – managed by your subclass – and a detail pane, which uses a NavHostFragment.
All Navigation artifacts have been rewritten in Kotlin and feature improved nullability of classes using generics – such as NavType subclasses.
Opinionated Architecture Guidance
To learn more about how our key architecture libraries work together, you can view a collection of videos and articles covering best practices for modern Android development in a series called Modern Android Development Skills: Architecture.
2. Performance Optimization of Applications
Using performance libraries allows you to build performant apps and identify optimizations to maintain high performance, resulting in better end-user experiences.
Improving Start-up Times
App speed can have a big impact on a user’s experience, particularly when using apps right after installation. To improve that first time experience, we created Baseline Profiles. Baseline Profiles allow apps and libraries to provide the Android run-time with metadata about code path usage, which it uses to prioritize ahead-of-time compilation. This profile data is aggregated across libraries and lands in an app’s APK as a baseline.prof file, which is then used at install time to partially pre-compile the app and its statically-linked library code. This can make your apps load faster and reduce dropped frames the first time a user interacts with an app.
We’ve already started leveraging Baseline Profiles at Google. The Play Store app saw a decrease in initial page rendering time on its search results page of 40% after adopting Baseline Profiles. Baseline profiles have also been added to popular libraries, such as Fragments and Compose, to help provide a better end-user experience. To create your own baseline profile, you need to use the Macrobenchmark library.
Instrumenting Your Application
The Macrobenchmark library helps developers better understand app performance by extending Jetpack’s benchmarking coverage to more complex use-cases, including app startup and integrated UI operations such as scrolling a RecyclerView or running animations. Macrobenchmark can also be used to generate Baseline Profiles.
Macrobenchmark has been updated to increase testing speed and has several new experimental features. It also now supports Custom trace-based timing measurements using TraceSectionMetric, which allows developers to benchmark specific sections of code. Additionally, the AudioUnderrunMetric now enables detection of audio buffer underruns to help understand audible jank.
BaselineProfileRule generates profiles to help with runtime optimizations. BaselineProfileRule works similarly to other macro benchmarks, where you represent user actions as code within lambdas. In the example below, the critical user journey that the compiler should optimize ahead of time is a cold start: opening the app’s landing activity from the launcher.
@ExperimentalBaselineProfilesApi
@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
@get:Rule
val baselineProfileRule = BaselineProfileRule()
@Test
fun startup() = baselineProfileRule.collectBaselineProfile(
packageName = "com.example.app"
) {
pressHome()
// This block defines the app's critical user journey. Here we are
// interested in optimizing for app startup, but you can also navigate
// and scroll through your most important UI.
startActivityAndWait()
}
}
For more details and a full guide on generating and using baseline profiles with Macrobenchmark, check our guidance on the Android Developers site.
Avoiding UI Stuttering / Jank
The new JankStats library helps you track and analyze performance problems in your app’s UI, including reports on dropped rendering frames – commonly referred to as “jank.” JankStats builds on top of existing Android platform APIs, such as FrameMetrics, but can be used back to API level 16.
The library also offers additional capabilities beyond those built into the platform: heuristics that help pinpoint causes of dropped frames, UI state that provides additional context in reports, and reporting callbacks that can be used to upload data for analysis.
Here’s a closer look at the three major aspects of JankStats:
Identifying Jank: This library uses internal heuristics to determine when jank has occurred, and uses that information to know when to issue jank reports so that developers have information on those problems to help analyze and fix the issues.
Providing UI Context: To make the jank reports more useful and actionable, the library provides a mechanism to help track the current state of the UI and user. This information is provided whenever reports are logged, so that developers can understand not only when problems occurred, but also what the user was doing at the time. This helps to identify problem areas in the application that can then be addressed. Some of this state is provided automatically by various Jetpack libraries, but developers are encouraged to provide their own app-specific state as well.
Reporting Results: On every frame, the JankStats client is notified via a listener with information about that frame, including how long the frame took to complete, whether it was considered jank, and what the UI context was during that frame. Clients are encouraged to aggregate and upload the data as they see fit for analysis that can help debug overall performance problems.
Adding Logging to your App
The Tracing library enables profiling of app performance by writing trace events to the system buffer. Tracing 1.1 supports profiling in non-debug builds back to API level 14, similar to the <profileable> manifest tag which was added in API level 29.
3. User Interface Libraries and Guidance
Several changes have been made to our UI libraries to provide better support for large-screen compatibility, foldables, and emojis.
Jetpack Compose
Jetpack Compose, Android’s modern toolkit for building native UI, has reached 1.2 beta today which has added several features to support more advanced use cases, including support for downloadable fonts, lazy layouts, and nested scrolling interoperability. Check out the What’s New in Jetpack Compose blog post to learn more.
Understanding Window State
The new WindowManager library helps developers adapt their apps to support multi-window environments and new device form factors by providing a common API surface with support back to API level 14.
The initial release targets foldable device use cases, including querying physical properties that affect how content should be displayed.
Jetpack’s SlidingPaneLayout component has been updated to use WindowManager’s smart layout APIs to avoid placing content in occluded areas, such as across a physical hinge.
Drag and Drop
The new DragAndDrop library also helps with new form factors and windowing modes by enabling developers to accept drag-and-drop data – both from inside and outside their app. DrapAndDrop includes a consistent drop target affordance and it supports back to API level 24.
Backporting New APIs to Older API Levels
The AppCompat library allows access to new APIs on older API versions of the platform, including backports of UI features such as dark mode.
AppCompat 1.4 integrates the Emoji2 library to bring default support for new emoji to all text-based views supported by AppCompat on API level 14 and above.
Custom locale selection is now supported back to API level 14. This feature enables manual persistence of locale settings across app starts, and supports automatic persistence via a service metadata flag. This tells the library to load the locales synchronously and recreate any running Activity as needed. On API level 33 and above, persistence is managed by the platform with no additional overhead.
Other key updates
Annotation
The Annotation library exposes metadata that helps tools and other developers understand your app's code. It provides familiar annotations like @NonNull that pair with lint checks to improve the correctness and usability of your code.
Annotation is migrating to Kotlin, so now developers using Kotlin will see more appropriate annotation targets, including @file.
Several highly-requested annotations have been added with corresponding lint checks. This includes annotations concerning method or function overrides, and the @DeprecatedSinceApi annotation which provides a corollary to @RequiresApi and discourages use beyond a certain API level.
Github
We now have over 100 projects in our GitHub! Several modules are open for developer contributions using the standard GitHub-based workflow:
Activity
AppCompat
Biometric
Collection
Compose Compiler
Compose Runtime
Core
DataStore
Fragment
Lifecycle
Navigation
Paging
Room
WorkManager
Check the landing page for more information on how we handle pull requests, and to get started building with Jetpack libraries.
This was a brief tour of all the changes in Jetpack over the past few months. For more details on each Jetpack library, check out the AndroidX release notes, quickly find relevant libraries with the API picker and watch the Google I/O talks for additional highlights.
Java is a trademark or registered trademark of Oracle and/or its affiliates.
At Google I/O, we talked about everything that’s new for developers, including the second Beta of Android 13, which we’re releasing today for your testing and feedback. Our program of Beta releases is driven by a philosophy of openness and collaboration with you, our community, and your input makes Android a better platform for everyone. Thank you for the feedback you’ve given so far!
In Android 13, we’re continuing to focus on our core themes of privacy and security as well as developer productivity. We’ve added a new permission for sending notifications, a privacy-protecting photo picker, and improved permissions when pairing with nearby devices and accessing media files. We’ve made it easier to support app-specific language settings, match your app’s icons to the user’s selected theme colors, and build with modern standards like HDR video, Bluetooth LE Audio, and MIDI 2.0 over USB. We’re also continuing to make Android an even better OS on tablets and large screens, giving you better tools to take advantage of the 270+ million of these devices in active use. You can read more about Android 13 in our Keyword blog post.
Beta 2 has everything you need to try the Android 13 features, test your apps, and give us your feedback. Just enroll any supported Pixel device here to get Beta 2 and future updates over-the-air. If you’ve already installed an Android 13 preview or Beta build, you’ll automatically get Beta updates.
You can also get Android 13 Beta on select phones, tablets, and foldables from our partners who are working to deliver quality from day one, including ASUS, HMD (Nokia phones), Lenovo, OnePlus, Oppo, Realme, Sharp, Tecno, Vivo, Xiaomi, and ZTE.
Visit android.com/beta to see the full list of partners, with links to their sites for details on their supported devices and Beta builds, starting with Beta 1. Each partner will handle their own enrollments and support, and provide the Beta updates to you directly.
With Beta 2 we’re just a step away from Platform Stability in June 2022, when we’ll have the final Android 13 SDK and NDK APIs as well as final app-facing system behaviors. Stay tuned, and for more on the timeline and how to get your apps ready for Android 13, visit the Android 13 developer site!
Posted by Alex Musil, Product Management at Google Play
At this year’s Google I/O, we focused on three major ways we can help you continue growing your business on Google Play:
Privacy and security initiatives to keep the ecosystem safe for users and developers, like the new Google Play SDK Index
Tools to help you improve your app quality across the app lifecycle
New ways to help you acquire users and engage with existing ones through features like LiveOps, as well as ways to drive revenue growth with new subscription capabilities
You can check out all the updates in our I/O session, or keep reading for a quick overview of the new features that will help take your business even further.
Privacy and security initiatives to protect developers and users
Over the last few years, we've been working on tools to help make SDKs better and safer for everyone, including SDK providers, app developers, and ultimately, our collective end users.
In 2020, we launched Google Play SDK Console, which provides usage statistics, crash reporting, and the ability for SDK providers to communicate to app developers through Play Console and Android Studio. Today, we launched Google Play SDK Index, a new public portal that lists the most widely used commercial SDKs, and provides data and insights about each one.
The index includes over 100 SDKs with information about which app permissions they use, statistics on the apps that use them, and if the SDK provider is committed to ensuring that their SDK’s code follows Google Play policies. You can use it to inform your decisions about which SDKs and specific versions to use in your app.
Google Play SDK Index shows reliability and safety signals so you can decide if an SDK is right for your business and your users.
We’re also protecting the work you put into your apps with Play’s app integrity tools. Play App Signing is used to securely sign millions of apps on Google Play and helps ensure that app updates can be trusted. From now on, Play App Signing will use Google Cloud Key Management to protect signing keys. This means you can review public documentation including the storage specifications and security practices that Google uses to protect your keys. We’ll soon be using Cloud Key Management for all newly generated keys, followed by securely migrating eligible existing keys.
Another new feature of Play App Signing rolling out soon is the ability for any app to perform an app signing key rotation. In the event of an incident or just as a security best practice, you’ll be able to trigger an annual key rotation from within Play Console. To maximize security, Google Play Protect will also verify your app updates using rotated keys for older Android releases that don’t support rotation, going all the way back to Android Nougat.
We also offer an API that you can use to help protect your app, your IP, and your users from abuse and attacks. The new Play Integrity API is now available to all apps and games to detect fraudulent and risky interactions, such as traffic from modified or pirated app versions and rooted or compromised devices.
In addition to protecting users, we also want them to feel safe when downloading apps and games from Google Play. The new Data safety section gives you a way to showcase your approach to privacy and security so that users can confidently download your app. If you haven't yet, please complete your Data safety form by July 20th. Check out our Help Center article for more information.
In other data privacy news, we’ve released the first developer preview of the Privacy Sandbox on Android, our initiative to build new technologies that improve user privacy while still enabling effective advertising. Check out our blog post to learn more and join our email newsletter for the latest updates.
More features to help you improve app quality across your app lifecycle
Your app quality affects everything from your ability to engage and retain users to your discoverability and promotability on the Play Store.
Android vitals is your definitive source of technical quality metrics on Play. Now, with the new Developer Reporting API, you can access Android vitals metrics and issues data outside of Play Console, including crash and ANR rates, counts, clusters, and stack traces and integrate them into your own tools and workflows.
You can also now viewAndroid vitals data at the country levelto help you troubleshoot and prioritize by location.
And we’ve made it easier to use Android vitals alongside Firebase Crashlytics by aligning issue names and enabling you to see Play Track information in Crashlytics when you link your Play app with your Crashlytics app.
Beyond Android vitals, there are other new features to help you across the development lifecycle:
Reach and devices makes it easier to plan for better quality by providing insights on your user and issue distribution. It now includes revenue and revenue growth metrics for apps that monetize on Play, so you can build revenue-based business cases for quality and reach.
We also overhauled the Device catalog to make it easier to understand and use. The Overview page now includes install data, and you can filter by new device attributes like shared libraries. You can also see device variants by RAM and Android version, which lets you quickly identify the most common variant.
It is now much easier to test your app on different form factors. You can independently run internal and open testing on many form factors including Android Automotive, and soon, Wear OS.
To help you keep users up to date, theIn-app Updates API will now let your app users know if there’s an update available within 15 minutes instead of up to 24 hours, including showing your “What’s new” text within the update screen.
To learn more about all these launches, check out our session on app quality.
Marketing and monetization features to help you grow your business
Google Play can help grow your business with new ways to acquire new users, engage your existing ones, and drive revenue growth.
Your store listing is often the first thing a prospective user sees about your app. To help you make the right first impression, you can now make up to 50 custom store listings, each with analytics and unique deep links, so you can show different listings to users depending on where they come from.
Developers can now create up to 50 custom store listings,
each with analytics and unique deep links.
We’ve also made some major improvements to Store Listing Experiments. You’ll now see results more quickly for most experiments, with more transparency and contrul to help you anticipate how long each experiment is likely to need.
Deep links are an important tool when trying to improve engagement with your in-app content, so we’re making it easier to keep your deep link setup complete and up-to-date. Soon, we’re launching a new Play Console page dedicated to deep links with all the information and tools related to your app’s deep links in one convenient place.
Another helpful tool is LiveOps, a feature that allows you to submit content to be considered for featuring on the Play Store. By surfacing limited-time offers, events, and major updates for your app or game, LiveOps drives 5% more 28-day active users and 4% higher revenue for developers using the feature than those that do not. If you’d like to join our beta program, you can learn more and express your interest here.
Since last year, we’ve made some big changes to Play Commerce to help you do business with users with regional payment method preferences, such as cash and prepaid. We’ve expanded our payment method library to include over 300 local payment methods in 70 countries, and added eWallet payment methods such as MerPay in Japan, KCP in Korea, and Mercado Pago in Mexico.
We also expanded pricing options with ultra-low price points to help you increase conversions and grow your revenue. Now you can price your products as low as the equivalent of 5 US cents in any market. This will allow you to adjust your prices to better reflect local purchasing power, run locally relevant sales and promotions, and support micro-transactions such as tipping.
We launched new subscription capabilities along with a reimagined developer experience, making it easier to sell subscriptions on Google Play. For each subscription, you can now configure multiple base plans and offers. This allows you to sell the subscription in multiple ways and reduces operational costs by removing the need to create and manage an ever-increasing number of SKUs.
Each base plan in a subscription defines a different billing period and renewal type - e.g a monthly auto-renewing plan, an annual auto-renewing plan, and a 1-month prepaid plan. A base plan can have multiple offers supporting different stages of the subscription lifecycle - e.g. an acquisition offer for limited time free trial, or an upgrade offer to incentivize subscribers to move from a prepaid plan to an auto-renewing plan. Offers are a great way to acquire new subscribers, incentivize upgrades, and retain existing subscribers.
For each subscription, you can now configure multiple base plans and offers.
New prepaid plans allow you to offer users access for a fixed amount of time. Users can easily extend their access period at any time before plan expiration. Users can purchase these top-ups in your app, or right on the Play Store subscription screen. They make a great option for regions where pay-as-you go is standard.
In-App Messaging is a new way to prevent you from losing subscribers due to a declined payment. Simply use the In-App Messaging API to check with Play when a user opens the app. If the user’s payment has been declined, a message will remind them to update their payment information.
Prevent subscriber loss due to declined payments with the In-App Messaging API.
These features are all available with the latest version of Play Billing Library 5.0. To learn more about these and other tools to help grow your business, check out “Power your Success with new acquisition, engagement and monetization tools.”
Thank you for continuing to be a part of the thriving Google Play ecosystem. We can’t wait to see what you build next.
Posted by Maru Ahues Bouza, Director of Android Developer Relations
There aren’t many platforms where you can build something and instantly reach billions of people around the world, not only on their phones—but their TVs, cars, tablets, watches, and more. Today, at Google I/O, we covered a number of ways Android helps you make the most of this opportunity, and how Modern Android Development brings as much commonality as possible, to make it faster and easier for you to create experiences that tailor to all the different screens we use in our daily lives.
#1: Jetpack Compose Beta 1.2, with support for more advanced use cases
Android’s modern UI toolkit, Jetpack Compose, continues to bring the APIs you need to support more advanced use cases like downloadable fonts, LazyGrids, window insets, nested scrolling interop and more tooling support with features like LiveEdit, Recomposition Debugging and Animation Preview. Check out the blog post for more details.
#2: Android Studio: introducing Live Edit
Get more done faster with Android Studio Dolphin Beta and Electric Eel Canary! Android Studio Dolphin includes new features and improvements for Jetpack Compose and Wear OS development and an updated Logcat experience. Android Studio Electric Eel comes with integrations with the new Google Play SDK Index and Firebase Crashlytics. It also offers a new resizable emulator to test your app on large screens and the new Live Edit feature to immediately deploy code changes made within composable functions. Watch the What’s new in Android Development Tools session and read the Android Studio I/O blog post here.
#3: Baseline Profiles - speed up your app load time!
The speed of your app right after installation can make a big difference on user retention. To improve that experience, we created Baseline Profiles. Baseline Profiles allow apps and libraries to provide the Android runtime with metadata about code path usage, which it uses to prioritize ahead-of-time compilation. We've seen up to 30% faster app startup times thanks to adding baseline profiles alone, no other code changes required! We’re already using baseline profiles within Jetpack: we’ve added baselines to popular libraries like Fragments and Compose – to help provide a better end-user experience. Watch the What’s new in app performance talk, and read the Jetpack blog post here.
BETTER TOGETHER
#4: Going big on Android tablets
Google is all in on tablets. Since last I/O we launched Android 12L, a release focused on large screen optimizations, and Android 13 includes all those improvements and more. We also announced the Pixel tablet, coming next year. With amazing new hardware, an updated operating system & Google apps, improved guidelines and libraries, and exciting changes to the Play store, there has never been a better time to review your apps and get them ready for large screens and Android 13. That’s why at this year’s I/O we have four talks and a workshop to take you from design to implementation for large screens.
#5: Wear OS: Compose + more!
With the latest updates to Wear OS, you can rethink what is possible when developing for wearables. Jetpack Compose for Wear OS is now in beta, so you can create beautiful Wear OS apps with fewer lines of code. Health Services is also now in beta, bringing a ton of innovation to the health and fitness developer community. And last, but certainly not least, we announced the launch of The Google Pixel Watch - coming this Fall - which brings together the best of Fitbit and Wear OS. You can learn more about all the most exciting updates for wearables by watching the Wear OS technical session and reading our Jetpack Compose for Wear OS announcement.
#6: Introducing Health Connect
Health Connect is a new platform built in close collaboration between Google and Samsung, that simplifies connectivity between apps making it easier to reach more users with less work, so you can securely access and share user health and fitness data across apps and devices. Today, we’re opening up access to Health Connect through Jetpack Health—read our announcement or watch the I/O session to find out more!
#7: Android for Cars & Android TV OS
Android for Cars and Android TV OS continue to grow in the US and abroad. As more users drive connected or tune-in, we’re introducing new features to make it even easier to develop apps for cars and TV this year. Catch the “What’s new with Android for Cars” and “What's new with Google TV and Android TV” sessions on Day 2 (May 12th) at 9:00 AM PT to learn more.
#8: Add Voice Across Devices
We’re making it easier for users to access your apps via voice across devices with Google Assistant, by expanding developer access to Shortcuts API for Android for Cars, with support for Wear OS apps coming later this year. We’re also making it easier to build those experiences with Smarter Custom Intents, enabling Assistant to better detect broader instances of user queries through ML, without any NLU training heavy lift. Additionally, we’re introducing improvements that drive discovery to your apps via voice on Mobile, first through Brandless Queries, that drive app usage even when the user hasn’t explicitly said your app’s name, and App Install Suggestions that appear if your isn’t installed yet–these are automatically enabled for existing App Actions today.
AND THE LATEST FROM ANDROID, PLAY, AND MORE:
#9: What’s new in Play!
Get the latest updates from Google Play, including new ways Play can help you grow your business. Highlights include the ability to deep-link and create up to 50 custom listings; our LiveOps beta, which will allow more developers to submit content to be considered for featuring on the Play Store; and even more flexibility in selling subscriptions. Learn about these updates and more in our blog post.
#10: Google Play SDK Index
Evaluate if an SDK is right for your app with the new Google Play SDK index. This new public portal lists over 100 of the most widely used commercial SDKs and information like which app permissions the SDK requests, statistics on the apps that use them, and which version of the SDK is most popular. Learn more on our blog post and watch “What’s new in Google Play” and “What’s new in Android development tools” sessions.
#11: Privacy Sandbox on Android
Privacy Sandbox on Android provides a path for new advertising solutions to improve user privacy without putting access to free content and services at risk. We recently released the first Privacy Sandbox on Android Developer Preview so you can get an early look at the SDK Runtime and Topics API. You can conduct preliminary testing of these new technologies, evaluate how you might adopt them for your solutions, and share feedback with us.
#12: The new Google Wallet API
The new Google Wallet gives users fast and secure access to everyday essentials across Android and Wear OS. We’re enhancing the Google Wallet API, previously called Google Pay Passes API, to support generic passes, grouping and mixing passes together, for example grouping an event ticket with a voucher, and launching a new Android SDK which allows you to save passes directly from your app without a backend integration. To learn more, read the full blog post, watch the session, or read the docs at developers.google.com/wallet.
#13: And of course, Android 13!
The second Beta of Android 13 is available today! Get your apps ready for the latest features for privacy and security, like the new notification permission, the privacy-protecting photo picker, and improved permissions for pairing with nearby devices and accessing media files. Enhance your app with features like app-specific language support and themed app icons. Build with modern standards like HDR video and Bluetooth LE Audio. You can get started by enrolling your Pixel device here, or try Android 13 Beta on select phones, tablets, and foldables from our partners - visit developer.android.com/13 to learn more.
That’s just a snapshot of some of the highlights for Android developers at this year’s Google I/O. Be sure to watch the What’s New in Android talk to get the landscape on the full Android technical track at Google I/O, which includes 26 talks and 4 workshops. Enjoy!
Posted by Steve Hartford, Product Manager, Google Play
Digital subscriptions continue to be one of the fastest growing ways for developers to monetize on Google Play. As the subscriptions business model evolves, many developers have asked us for more flexibility and less complexity in how they sell subscriptions.
To meet those needs, we've reimagined the developer experience for selling subscriptions on Play. Today, we’re launching new subscription capabilities and a new Console UI to help you grow your business. At its foundation, we’ve separated what the subscription benefits are from how you sell the subscription. For each subscription, you can now configure multiple base plans and offers. This allows you to sell your subscription in multiple ways, reducing operational costs by removing the need to create and manage an ever-increasing number of SKUs.
You may have already noticed the change in Play Console as we’ve taken existing subscription SKUs and separated them into subscriptions, base plans, and offers. The new subscriptions configuration behaves as before, with no immediate need to update your apps or backend integrations.
Example of a subscription configuration
More flexibility to improve reach, conversion, and retention
Each base plan in a subscription defines a different billing period and renewal type. For example, you can create a subscription with a monthly auto-renewing plan, an annual auto-renewing plan, and a 1-month prepaid plan.
Prepaid plans are an entirely new option that provides users with access to benefits for a fixed duration. Users can extend this access by purchasing top-ups in your app, or in the Play Store. Prepaid plans allow you to reach users in regions where pay-as-you-go is standard, including India and Southeast Asia. They can also provide an alternative for users not ready to purchase an auto-renewing subscription.
A base plan can have multiple offers supporting different stages of the subscription lifecycle — whether to acquire new subscribers, incentivize upgrades, or retain existing subscribers. Whenever users could benefit from the value your subscriptions provide, we want to help you reach them with an offer they find worthwhile and convenient.
Offers provide a wide range of pricing and eligibility options. While the base plan contains the price available to all users, offers provide alternate pricing to eligible users. You can make offers that are available everywhere their base plan is available, or you can create offers for specific regions. For example:
Acquisition offers allow users to try your subscription for free or at a discounted price
Upgrade and crossgrade offers incentivize users to benefit from longer billing periods or higher tiers of service
Upgrade offers can also help you move subscribers from a prepaid plan to an auto-renewing plan
If you want even more flexibility, you can create custom offers for which you decide the business logic, such as second-chance free trials, or win-back offers for lapsed subscribers.
Better metrics to understand your business
We’ve improved reporting by updating how metrics are calculated in Play Console. Metrics such as new subscription counts, conversion and retention rates, and cancellations are more consistent and calculated in line with financial metrics. You can now directly compare data between Play Console and the Real Time Developer Notifications API. Additionally, subscription metrics are now cumulative. This means that data reported for previous days won’t change over time.
Get started
Starting today, all these new subscription capabilities are available. To learn more please visit the Help Center. When you’re ready to integrate, check out this guide, documentation, and sample app.
Please let us know how we’re doing and contact us with any issues you may encounter.
Posted by Juan Sebastian Oviedo, Senior Product Manager
Today at Google I/O 2022, we announced an exciting set of new features available in Android Studio Dolphin Beta and Electric Eel Canary, both available for download. You told us that you want to be more productive while creating Android apps, so we focused on improvements that make the development experience faster and more informative.
In the Android Studio Dolphin release you will find the following features and improvements that you can start using in the Beta channel, which is close to stable quality:
View Compose animations and coordinate them with Animation Preview.
Define annotation classes to easily include and apply multiple Compose preview definitions at once.
Track recomposition counts for your composables in the Layout Inspector.
Easily pair and control Wear OS emulators and launch tiles, watch faces, and complications directly from Android Studio.
Diagnose app issues faster with Logcat V2.
For even more cutting edge features, you can take a sneak peek at the Android Studio Electric Eel release in the Canary channel:
View dependency insights from the new Google Play SDK Index, a public portal with information about popular dependencies/SDKs. If a specific version of a library has been marked as “outdated” by its author, a corresponding Lint warning will appear when viewing that dependency definition. This enables you to discover and update dependency issues during development instead of later when you go to publish your app on the Play Console. You can learn more about this new tool here.
See Firebase Crashlytics reports directly in Android Studio using the new App Quality Insights window. The App Quality Insights window allows you to navigate from stack traces into your code with a few simple clicks. The IDE also highlights lines of code in the editor as you're editing files containing recent crashes. This saves you time by presenting actionable crash information from users directly in the IDE, so you can focus on providing your users with the best app experience.
Test your app’s UI on representative reference devices using a single resizable Android Emulator. Instead of having to set up emulators specifically for tablets, phones, or desktops, you can use a single resizable emulator and change its configuration without needing to re-deploy to test your app.
With the experimental Live Edit feature, make code changes and have those immediately reflected in the Compose Preview and running app on an emulator or physical device.
These features will be promoted to more stable channels once we have your feedback and make improvements, so please try them out.
To see all the new features in action, watch the What’s new in Android Developer Tools session.
Below is a list of key new features and improvements in Android Studio Dolphin:
Jetpack Compose
Compose Animation Coordination - See all your animations at once and coordinate them in Animation Preview. You can also freeze a specific animation.
Compose Animation Coordination
Compose Multipreview Annotations - Define an annotation class that includes multiple Preview definitions and use that new annotation to generate those previews at once. Use this new annotation to preview multiple devices, fonts, and themes at the same time — without repeating those definitions for every single composable.
Multipreview annotations
Compose Recomposition Counts in Layout Inspector - View recomposition counts for a Compose app in the Layout Inspector. Recomposition counts and skip counts can optionally be shown in the Component Tree and Attributes panels. Learn more.
Compose Recomposition Counts
Wear OS
Wear OS Emulator Pairing Assistant - Using the Wear OS Emulator Pairing Assistant, you can now see Wear Devices in the Device Manager, and pair multiple watch emulators with a single phone. You also don't have to re-pair devices as often because Android Studio remembers pairings after being closed.
Wear OS Emulator Pairing Assistant
Wear OS Emulator Side Toolbar - Use Wear-specific emulator buttons that resemble and simulate physical buttons, including main buttons, palm buttons, and tilt buttons.
Wear OS Emulator Side Toolbar
Wear OS Direct Surface Launch - Create Run/Debug configurations for Wear OS tiles, watch faces, and complications, and launch them directly from Android Studio.
New Wear OS Run/Debug configuration types
Development tools
Logcat V2 - Rebuilt from the ground up, the new Logcat makes it easier to parse, query, and track logs. Logcat V2 includes new formatting that makes it easier to scan useful information, new split views to allow you to track more at a glance, and a brand new powerful syntax for filtering logs. Learn more.
Logcat V2
Gradle Managed Devices - Describe the virtual devices you need for your automated tests as a part of your build, and let Gradle take care of the rest. From SDK downloading, to device provisioning and setup, to test execution and teardown, Gradle manages the lifecycle of your virtual devices during instrumentation tests. Gradle is also able to apply intelligent functionality, such as snapshot management, test caching, and test sharding to ensure your tests run efficiently, quickly, and consistently. Gradle Managed Devices also introduces a completely new type of device, called the Automated Test Device, which optimizes devices for automated tests, resulting in significant reduction in CPU and memory usage during test execution. Learn more.
Gradle Managed Devices
Below is a list of key new features and improvements in Android Studio Electric Eel:
Jetpack Compose
Live Edit - Make code changes to Composables in Android Studio and see those changes reflected immediately in the Compose Preview and your emulator or physical device. Live Edit is an opt-in feature that you can enable in Android Studio settings. Learn more.
Live Edit on emulator
Live Edit on Preview
Google Play and Firebase
SDK Insights- Get Lint warnings for SDKs/libraries that have been marked as outdated by their authors in the Google Play SDK Index. Update outdated dependency versions during development to avoid issues when your app is submitted to the Play Console.
Google Play SDK Index insights
App Quality Insights from Firebase Crashlytics - Discover, investigate, and resolve issues reported by Crashlytics in Android Studio and within the context of your local source code. This integration helps reduce friction when navigating from crashes to code (and from code to crash), and surfaces important contextual data about each crash to help you reproduce issues locally.
App Quality Insights from Firebase Crashlytics
Large Screens
Resizable Emulator - Rapidly toggle between representative reference devices to quickly test various application layout states with a single running emulator instance. You can create these emulators by selecting the “Resizable” type in the Device Manager’s “Create device” flow.
Resizable Emulator
Visual Linting - Discover and fix your layout issues across different devices (for example, when a button is hidden out of bounds on a larger tablet) by opening the Layout Validation panel. We automatically run your layout to check for Visual Lint issues across different screen sizes.
Visual Linting
Development Tools
Emulated Bluetooth - You can now discover and connect two phone emulators using virtual Bluetooth. This feature is available on Android Emulator 31.3.8 and higher with system image T (API 33). We plan to add more support for creating sample virtual peripherals, such as beacons and heart rate monitors, and integration testing for your Bluetooth features!
Pairing two Android Emulators using Emulated Bluetooth
Device Mirroring - Minimize the number of interruptions when developing by streaming your device display directly to Android Studio. Device Mirroring gives you the ability to interact with a physical device using the Running Devices window in Studio. To enable this feature, go to Preferences > Experimental and select Device Mirroring. Once enabled, plug in your device and open the Running Devices window to begin streaming your display.
Device Mirroring
To recap, these new features and improvements are available in the Android Studio Dolphin Beta, near stable quality:
Jetpack Compose
Compose Animation Coordination
Compose Multipreview Annotations
Compose Recomposition Counts in Layout Inspector
Wear OS
Wear OS Emulator Pairing Assistant
Wear OS Emulator Side Toolbar
Wear OS Direct Surface Launch
Development tools
Logcat V2
Gradle Managed Devices
These brand new features and improvements are available in the Android Studio Electric Eel Canary:
Jetpack Compose
Live Edit
Google Play and Firebase
SDK Insights
App Quality Insights from Firebase Crashlytics
Large Screens
Resizable Emulator
Visual Linting
Development tools
Emulated Bluetooth
Device Mirroring
Getting started
Android Studio Dolphin Beta and Electric Eel Canary are both available for download. You can install them side by side with the current stable version of Android Studio following these instructions. The Beta release is near stable release quality, but bugs might still exist, so, if you do find an issue, please let us know so we can work to fix it. Likewise, if you find an issue or have feedback for the features in the Canary release, please let us know.
We really appreciate your feedback on issues and feature requests. You can follow us—the Android Studio development team—on Twitter and on Medium.
From helping you log your meals with MyFitnessPal to getting a holistic view of your health with Withings, apps and devices are a source for many kinds of useful health and fitness data. As Android developers, connecting and sharing this data between apps can help you provide more meaningful experiences and insights for your users. However, much of this information is spread across multiple experiences and different devices, making it difficult to bring together. Moreover, there are no centralized privacy controls for Android users.
Introducing Health Connect
This is why we’ve created Health Connect, a platform and API for Android app developers. With user permission, developers can use a single set of APIs to securely access and share health and fitness data across Android devices.
We're building this new unified platform in collaboration with Samsung to simplify connectivity between apps. We appreciate Samsung’s collaboration as we roll out Health Connect to foster richer app experiences while also providing centralized privacy controls for users.
We've been working with developers including MyFitnessPal, Leap Fitness and Withings as part of an early access program. In addition, Samsung Health, Google Fit and Fitbit are adopting Health Connect. Starting today, all developers can get access to Health Connect's common set of APIs for Android via Android Jetpack.
Health Connect fits in with Google’s wider efforts to help billions of people be healthier, using our platforms and technology to connect and bring more meaning to health information.
How does Health Connect work?
How Health Connect Works
Health Connect supports many common health and fitness data types and categories, including: activity, sleep, nutrition, body measurements and vitals like heart rate and blood pressure.
With user permission, developers can securely read from and write data to Health Connect, using standardized schema and API behavior. Users will have full control over their privacy settings, with granular controls to see which apps are requesting access to data at any given time. The data in Health Connect is all on-device and encrypted. Users will have the ability to shut off access or delete data they don’t want on their device, and the option to prioritize one data source over another when using multiple apps.
Getting started
It’s easy to get started with Health Connect. Health Connect’s single set of APIs makes it simple to manage permissions and read and write data. Here’s an example of how you can request permissions and then write some data.
First, build a set of the permissions you plan to request read or write access to. In this example we are reading and writing steps and heart rate.
private val permissions =
setOf(
Permission.createReadPermission(Steps::class),
Permission.createWritePermission(Steps::class),
Permission.createReadPermission(HeartRate::class),
Permission.createWritePermission(HeartRate::class),
)
// then, create a permissions request for this set of permissions
Then, launch the permissions request, which will bring the user to the Health Connect permissions UI to grant permissions.
Once the user grants permission, you are ready to read and write data. Here’s an example of how to write steps data over a period of time. Include the total number of steps, start and end time, and timezone information, and then insert the data into Health Connect.
private suspend fun writeSomeData(client: HealthConnectClient) {
val records = mutableListOf<Record>()
records.add(
Steps(
count = 888,
startTime = START_TIME,
endTime = END_TIME,
startZoneOffset = null,
endZoneOffset = null,
)
)
// add additional records as needed
}
It’s been almost a year since Jetpack Compose 1.0 was released, and during this time we've seen the community adopt it with enthusiasm. You’ve told us you’re appreciating the conciseness of the Kotlin syntax and the declarative approach that makes thinking about UI so much faster and easier.
Compose in the Community
We've seen many companies adopt Compose at scale for the newest and boldest features of their apps. For instance, we've worked closely with the Play Store team, who started experimenting with Compose in the very early days, and learned that not only is it more enjoyable, it is beneficial to their developer productivity. They told us that "All new Play Store features are built on top of this framework. Compose has been instrumental in unlocking better velocity and smoother landings for the app." The team at Twitter has been using Jetpack Compose across different parts of the app, and they are reaping the benefits, as "Compose makes it much easier to define our own components and to make their API contracts more explicit, flexible, and intuitive." The Airbnb team adopted Compose as well: "Jetpack Compose is a critical part of our technical strategy. The productivity gains are massive."
We're very glad to see that these teams, who have carefully evaluated Compose in large, complex production environments, are experiencing not just more fun and clarity in their UI development, but broader engineering benefits! And these are just a few examples, because over 100 of the top 1000 apps in the Play Store are now using Compose.
These close collaborations, and listening carefully to feedback from the broader Android community, are always at the heart of our development process and are key to advancing our roadmap. We're now focusing on supporting your more advanced use cases, with new APIs and feature improvements, all together with new tools to make building with Compose easier. We know that Compose fundamentally changes the way UI is built. To help you with the necessary mindset shift, we're publishing more guidance, talks and codelabs on advanced topics, and more in-depth videos so you can write apps that look great and perform great. Here's what is new:
We’ve addressed one of the top-voted bugs in our issue tracker by making includeFontPadding a customizable parameter. We recommend you set this value to false, as this will enable more precise alignment of text within layout. We aim to eventually make this the default value in a future release. Please let us know in the issue above if setting the value to false leads to issues with your app. Additionally, when includeFontPadding is set to false, you can adapt the line height of your Text composable by setting the lineHeightStyle parameter. Combined it can look like this:
Multi-line Text with includeFontPadding set to true (left, current default) vs false (right) and lineHeightStyle.
Compose 1.2 also introduces downloadable fonts in Compose. You can use the new APIs for Compose to access Google Fonts asynchronously, even defining fallback fonts, without any complex setup. With downloadable fonts, you can keep your APK size small and improve your user’s system health as multiple apps can share the same font through a provider.
Text Magnifier
Android text provides a magnifier widget, which makes selecting text easier. Compose now supports the text magnifier.
The magnifier is shown when dragging a selection handle to help you see what’s under your finger. Compose 1.1.0 brought the magnifier to selection within text fields, and now Compose 1.2.0 supports magnifier in both text fields and SelectionContainer. The magnifier has also been enhanced to match the precise behavior of the Android magnifier in Views.
Layout features and improvements
Lazy Layouts
Lazy layouts continue to evolve, with the grid APIs LazyVerticalGrid and LazyHorizontalGrid graduating out of experimental, and a new experimental API being added, called LazyLayout, that lets you implement your own custom lazy layouts. Learn more about these APIs in the I/O talk Lazy layouts in Compose.
Interop with CoordinatorLayout
When you embed a scrolling composable in a CoordinatorLayout from the view system, you can now make sure their scroll behaviors are interoperable. This makes the setup of a collapsible toolbar much easier. You can opt-in to this behavior by passing the result of calling the new experimental rememberNestedScrollInteropConnection method into the nestedScroll modifier. Here’s a sample demonstrating this new functionality.
To help you understand and improve your app’s performance, we focused a lot on new performance tooling and guidance. With this, it becomes much easier to understand why and where your app might be lagging.
Starting from Android Studio Dolphin, you can inspect how often composables recompose using the Layout Inspector. Unexpectedly high numbers of recomposition can point you to a composable that could be optimized. In addition, Android Studio Electric Eel now includes a recomposition highlighter, a visual aid to see which composables recompose when. Read more about this new tooling in the What’s new in Android Studio blog.
Layout Inspector showing recomposition count and recomposition highlighter.
Compose changes the way you write your UI at a fundamental level, so there are some best practices that you can adopt to make sure your app is performant. The newly released documentation page suggests how to write and configure your Compose app for best performance. In the I/O talk Common performance gotchas in Jetpack Compose, the Compose team describe common performance mistakes and how to fix them.
Performance is an ongoing area of focus and we’re working hard on improving and extending tooling and guidance. In the meantime, we’d really appreciate your feedback on the work we’ve done so far. Please raise your bugs in the issue tracker or ask your questions on the KotlinLang Slack group.
New tools
On top of improvements, there are also new tooling updates to help you use Compose more effectively. Android Studio Dolphin, now in Beta, brings exciting features for Compose development. Beyond recomposition counts, new tools include Animation Coordination so you can see and scrub through all your animations at once, and the MultiPreview annotation to help you build for multiple screen sizes. To enable you to iterate faster Android Studio Electric Eel (in Canary) brings LiveEdit.
Check out What's new in Android Development Tools for all the details, and make sure you share your feedback to help shape the tooling support you need for Compose.
Compose for Wear OS
If there is something better than Compose, it is more Compose! So we're very excited to see Compose for Wear OS moving to Beta! Following the same principle as any other Jetpack library, Beta means that it's feature complete and API stable, and you can start building your production-ready apps. Go ahead and watch the talk, and read the blog post!
New and improved guidance
We’ve added and revamped a lot of the guidance on Compose:
We hope that you find these new features as exciting as we do. If you haven't started yet, it's time to learn Jetpack Compose and see how it will fit in your team and development process, so that you can experience all the benefits of improved velocity and developer productivity. Happy Composing!
Posted by Paris Hsu, Product & Design, Android; Takeshi Hagikura, Developer Relations Engineer, Android
Today, we are thrilled to announce the stable release of Android Studio Chipmunk 🐿: The official IDE for building Android applications! This release is a smaller feature release, but we included the latest IntelliJ update and devoted more time to quality and stability. In this release alone, we address over 175+ quality issues.
If you want to be on the latest stable version of Android Studio you can download it today!
What’s in Android Studio Chipmunk
Below is a full list of new features in Android Studio Chipmunk:
Compose Animation Preview
This previously experimental feature is now available to allow Jetpack Compose developers to inspect and debug their animations built with Compose. If an animation is described in a composable preview, you can inspect the exact value of each animated value at a given time, pause the animation, loop it, fast-forward it, or slow it down. It is especially useful to compare animations with their design specs frame by frame.
Compose Animation Preview currently supports AnimatedVisibility and updateTransition. It will support more animation types in the future.
Compose Animation Shrine Cart
CPU Profiler
Android Studio Chipmunk now shows updated jank information, including jank types, and expected and actual deadlines that help you spot the actual cause of the jank. This jank information is available when you use the Android Emulator or physical devices with API level 31 (Android 12) or higher. Learn more here.
Showing Jank Information in CPU Profiler
Build Analyzer: Check Jetifier
In Chipmunk we have introduced a new Jetifier check in Build Analyzer that will notify you if you can remove the Jetifier flag to improve performance during build.
The Jetifier flag was designed to automatically migrate third-party libraries to use AndroidX, and the vast majority of Android Studio projects still have it enabled. However, the library ecosystem has mostly moved to support AndroidX natively, and having the flag now usually adds unnecessary build overhead -- turning it off will typically save 5-10% on build times.
Showing Jetifier Check in Build Analyzer
IntelliJ Platform Update
Although the number of Android specific features is light for Android Studio Chipmunk, it however includes the IntelliJ 2021.2 platform major release 😎, which has many new features such as project-wide analysis, a new powerful Package Search UI, and IDE actions enhancements to speed up your workflow. Learn more.
Getting Started
In short, Android Studio Chipmunk 🐿 is the update you don’t want to miss! Even though it was a shorter release, with the new version for IntelliJ, our continual efforts to improve quality, performance, and stability of the IDE, and the features listed earlier, we can’t wait for you to download and try it today!
As always, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, please file an issue. To stay up-to-date with the latest features, follow us -- the Android Studio development team ‐ on Twitter and on Medium.
For eBay, the massive online marketplace used by millions of buyers and sellers around the world, providing an optimal user experience is key to driving sales. So when the Android engineers on eBay’s architecture team recognized they could further improve the eBay app by optimizing it for large screens such as tablets and foldables, they knew they had to act fast to provide a seamless experience across devices. Their efforts paid off—the eBay app quickly earned 4.7 stars out of 5 on Google Play.
After combing through user stats, the team discovered that there was a surprisingly large subset of tablet users who accessed the eBay app on large screen Android devices. Encouraging new data shows that an eBay user will likely spend more time using the app if they’re using a tablet rather than a phone.
“The benefits of investing development time into large form factor screens is apparent in our public feedback channels,” said Matthew Mossman, an Android engineer on eBay’s mobile architecture team. By optimizing the app for large screens, eBay’s developers built a better user experience and boosted user satisfaction.
Creating a better tablet app
The eBay app is extremely information-dense, so being able to show users a full picture and description of available items was crucial to maintaining its popularity among buyers and sellers. Realizing that the extra screen space afforded by tablets would enhance users’ browsing and search experiences, eBay’s Android engineers improved the UX flow using list-detail patterns.
Mossman used Android’s powerful resource qualifier mechanisms to configure the best layouts for various devices, and updated the library of user interface components from eBay’s phone app for use on laptops and tablets. Additionally, by adopting industry guidelines for Android standardization, eBay’s architecture and feature teams aligned their processes for customizing apps, enabling them to deliver a better experience to users faster than before.
Higher engagement, greater satisfaction
After improving the eBay experience for tablet users, Mossman and the developer team saw a spike in positive reviews on Google Play, raising the eBay Android app’s rating to 4.7 out of 5 stars. The developers also reported a definitive increase in user satisfaction after incorporating Material Design Components, dark theme support, and other eye-catching, intuitive features into the app.
What’s more, eBay’s Trust and Search feature teams each saw increased user engagement across sales activities. Since enabling App Bundles and Dynamic Features to better serve specific devices, eBay has seen 20% higher engagement with its community support network, signaling new interest from tablet users.
In upcoming releases, the developers expect to fully utilize the rich functionality of Jetpack Compose, a UI building tool kit that was recently enabled for eBay’s Android app. Metrics and reporting from Firebase helped the team pinpoint further opportunities for growth and improvement that will additionally benefit eBay app users.
With its large screen optimization plan, eBay clearly showed why investing in device-specific experiences benefits users and developers alike.
Learn more about optimizing across devices
Learn about the unique experiences being created for bigger screens on Android and Chrome OS devices.
There are many fulfilling opportunities found in Android development: from launching a career, expressing yourself in fun ways, working on an app that makes a difference, or starting a business. At Google, we’re committed to increasing opportunities for anyone to learn Android development, so more people can experience this. As the next evolution of our journey to make Android development accessible to all, we released the first two units of Android Basics with Compose. This is the first free course that teaches Android development with Jetpack Compose to everyone. Compose simplifies and accelerates Android UI development, bringing your app to life faster with less code, powerful tools, and intuitive Kotlin APIs. If you are curious about learning Android development with Android's latest offering for building native UI, this is a great place to start!
Similar to the Android Basics in Kotlin course, Android Basics with Compose teaches the fundamentals of programming in Kotlin; you do not need any prior programming experience other than basic computer literacy to get started with this course. Not only does the course cover the most recent Android app building techniques, it is also designed to make it easier and more fun for you to learn Android. We built this course from scratch, taking into account feedback we received from learners, instructors, and designers from previous Android development courses.
The course contains learning pathways that teach you the basics of programming along with how to use the Kotlin programming language, with additional development topics introduced during your learning journey! If you are familiar with programming or the Kotlin programming language, you can skip ahead and focus on learning how to develop with Jetpack Compose.
The Android Basics with Compose and Android Basics in Kotlin courses will co-exist as our latest Android training offerings. Android Basics with Compose shares a similar course structure with Android Basics in Kotlin; in many cases they share the same sample apps, but are written using different UI toolkits. This allows you to see, compare, and learn the differences between Views and Compose, you can even work with both courses simultaneously.
This course also introduces new content formats such as code-along videos for Codelabs, practice problems to give you more hands-on coding experience, and open-ended projects to unleash your creativity. These two units are just the beginning; more will be coming soon. Check out Android Basics with Compose to get started on your Android development journey!
It’s already April and we’ve been making steady progress refining the features and stability of Android 13, building around our core themes of privacy and security, developer productivity, as well as tablet and large screen support. Today we’re moving into the next phase of our cycle and releasing the first Beta of Android 13.
For developers, there’s a lot to explore in Android 13, from privacy features like the new notification permission and photo picker, to APIs that help you build great experiences, like themed app icons, quick settings tile placement, and per-app language support, as well as capabilities like Bluetooth LE audio and MIDI 2.0 over USB. In Beta 1, we’ve added new permissions for more granular access to media files, improved audio routing APIs, and more. We’ll have more to share at Google I/O, coming up on May 11-12, so please save the date!
We’re inviting you to give Beta 1 a try as we welcome more early adopters to give us feedback on this release. You can try Android 13 Beta 1 today on supported Pixel devices by enrolling here to get the update over-the-air. If you’re already running a developer preview of Android 13, your device will automatically get this and future updates over the air. As always, downloads for Pixel and the Android Emulator are also available. Visit the Android 13 developer site for details on how to get started developing and testing your app.
What’s new in Beta 1?
We’re continuing to focus on privacy and security, while giving you new APIs to help you build great experiences for your users. Beta 1 includes the latest updates to features we announced earlier, like the new notification permission, photo picker, themed app icons, improved localization and language support, and more. Beta 1 also introduces a small number of new features, so give these a try and let us know what you think!
More granular permissions for media file access - Previously, when an app wanted to read shared media files in local storage, it needed to request the READ_EXTERNAL_STORAGE permission, which gave access to all types of media files. To bring more transparency and control to users, we’re introducing a new set of permissions with more granular scope for accessing shared media files.
With the new permissions, apps now request access to a specific type of file in shared storage:
When the permissions are granted by the user, apps will have read access to the respective media file types. To simplify the experience for users, If an app requests READ_MEDIA_IMAGE and READ_MEDIA_VIDEO at the same time, the system displays a single dialog for granting both permissions. If your app accesses shared media files, you’ll need to migrate to the new permissions when your app targets Android 13. More here.
Better error reporting in Keystore and KeyMint - For apps that generate keys, Keystore and KeyMint now provide more detailed and accurate error indicators. We’ve added an exception class hierarchy under java.security.ProviderException, with Android-specific exceptions that include Keystore/KeyMint error codes, and whether the error is retryable. You can also modify the methods for key generation, signing, and encryption to throw the new exceptions. The improved error reporting should now give you what you need to retry key generation.
Anticipatory audio routing - To help media apps identify how their audio is going to be routed, we’ve added new audio route APIs in the AudioManager class. The new getAudioDevicesForAttributes() API allows you to retrieve a list of devices that may be used to play the specified audio, and we added the getDirectProfilesForAttributes() API to help you understand whether your audio stream can be played directly. Use these new APIs to determine the best AudioFormat to use for your audio track.
App compatibility
If you haven’t tested your app for compatibility with Android 13 yet, now is the time to do it! With Android 13 now in Beta, we’re opening up access to early-adopter users as well as developers. This means that in the weeks ahead, you can expect more users to be trying your app on Android 13 and raising any issues that they find.
To test for compatibility, install your published app from Google Play or other source on a device or emulator running Android 13 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.
With Beta we’re getting closer to Platform Stability in June 2022. Starting then, app-facing system behaviors, SDK/NDK APIs, and non-SDK lists will be finalized. At that time, you should finish up your final compatibility testing and release a fully compatible version of your app, SDK, or library. More on the timeline for developers is here.
Get started with Android 13!
Today’s Beta release has everything you need to try the Android 13 features, test your apps, and give us feedback. Just enroll any supported Pixel device here to get this and future Android 13 Beta and feature drop Beta updates over-the-air. If you’ve already installed a developer preview build, you’ll automatically get these updates. To get started developing, set up the SDK.
For even broader testing on supported devices, try Android 13 Beta on Android GSI images, and if you don’t have a device you can test on the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.
Posted by Haoran Man, Niv Govindaraju, Rohit Sampathi, and Antriksh Saxena
A new Photos widget featuring Memories
As the home for your memories, Google Photos is loved by hundreds of millions of people around the world. One key focus area for us is how we continue to create truly helpful and compelling experiences for our users to cherish memories with their friends and family. We recently brought our Memories feature to Android widgets, enabling users to easily enjoy an ambient stream of photos right on their phone’s home screen. To increase the widget’s awareness, we experimented with a notification campaign that ended up increasing widget DAUs by 10x. Read on for more on how we accomplished this...
Photos’ widget usage was initially low
Despite our belief that the Memories widget was a helpful and requested feature from our users, initial adoption was relatively low, with tapering organic growth in the weeks following launch. There was clearly plenty of headroom to grow awareness of this feature so we started brainstorming ways to make it easier for users to learn about and try out the widget.
Leveraging notifications to increase feature discovery
We decided to experiment with notifications given Photos’ past success in using them as a helpful nudge for feature discovery. We quickly put together a notification campaign that targeted eligible Photos Android users with Memories content. They each received a notification informing them of the widget, and on tap-through would be dropped directly into the Memories widget install flow. In just a couple seconds, they could have the widget set up and start seeing their special moments featured on screen.
Users took advantage of the streamlined flow, which drove installs 10x
The notification campaign proved highly successful: we achieved a 15% conversion rate, ultimately resulting in 10x widget DAUs compared to before the campaign.
Here are a few reasons why we believe this campaign was so effective:
1. A clear value proposition
We believe notifications, like our features, should be helpful, not a nuisance. That means always having a clear and concise value proposition. Keeping the copy length short, highlighting contextual information, and being clear on the value-add has often resonated better with users and resulted in higher click-through & conversion rates.
With this in mind, we ran a quick experiment to test 3 candidate copies for the widget in order to determine which had the highest conversion. The best-performing copy ended up yielding a +12% improvement on widget installs compared to the worst-performing copy.
2. A streamlined post-click flow
We configured the notification to open directly into the widget install picker, making it really easy for users to install and start playing with the widget right away. A similar campaign from earlier this year to promote our iOS widget lacked this streamlining and we unsurprisingly saw lower conversion, likely from the extra friction.
We hope these tips prove helpful to you as you design your next notification campaign.
Creating a consistent and intuitive user experience is more important than ever to grow your audience and scale your business. To help you, Google Play, Android, and Firebase shared the latest insights and best practices on building high quality Android apps, improving developer productivity, and creating the best possible experience across all Android devices at the 2022 Android App Excellence Summit.
If you missed any sessions, we have you covered! You can watch all the content from the summit on our #AppExcellenceSummit playlist here.
Hear directly from Headspace and Duolingo on how they achieved a better user experience and improved developer productivity by revamping their Android Architecture from scratch.
Learn how to use the Play Console to build a business case for quality. Get a better understanding of the Play Console’s reach and devices dashboard, including new features for apps that monetize on Play.
We are committed to empowering the developer ecosystem to build high quality experiences across all Android devices. We greatly appreciate all that joined us during our App Excellence Summit and we’re looking forward to hearing your feedback. Keep in touch with us on Twitter with #AppExcellenceSummit.
Posted by Janelle Kuhlman, Developer Relations Program Manager
For Women’s History Month, we’re celebrating a few of our Google Developer Experts. Meet Maryam Alhutayfi, Android GDE. The GDE program team encourages qualified candidates that identify as women or non-binary to express interest in joining the community by completing this form.
Android GDE Maryam Alhuthayfi has loved programming since high school, when she learned programming in Visual Studio and basic website development.
“We didn't get much beyond that because there weren’t many Arabic resources,” she says. “That experience got me excited to dig deeper into technology. I wanted to know how the web functions, how software is made, and more about programming languages.”
Maryam studied computer science at university and majored in information systems. For her senior year graduation project, she and her team decided to build an Android application, her first experience with Android. She graduated with honors and landed a job as a web developer, but she kept thinking about getting back to being an Android developer.
She joined Women Techmakers in Saudi Arabia in 2019, when the group launched, to connect with other women in tech to help and support. She got a job as an Android robotics developer and became a co-organizer of GDG Cloud Saudi, her local Google Developer Group. Now Maryam is a senior Android development specialist at Zain KSA, one of Saudi Arabia’s largest telecommunications companies, which she describes as “a dream come true,” and in January 2022, she became an Android GDE.
Maryam is the first Android GDE in the Middle East and the second in MENA. She contributes to the Android community by speaking about Android and Kotlin development in detail, and software development more generally. She maintains a blog and GitHub repository and gives numerous talks about Android development. She encourages Android developers to use Kotlin and Jetpack Compose, and she describes both as causing a major shift in her Android development path. She started the Kotlin Saudi User Group in 2020.
Maryam regularly mentors new Android developers and gives talks on Android for Women Techmakers and Women Who Code. She encourages Android developers at big companies like Accenture and Careem to join and contribute to the Android community.
Remembering how few Arabic resources she had as a high school student, Maryam creates both Arabic and English content to enrich Android learning resources. “I made sure those resources would be available to anyone who wants to learn Android development,” she says. “Locally, in collaboration with GDGs in Saudi Arabia, we host sessions throughout each month that cover Android, Flutter, and software development in general, and other exciting topics, like data analytics, cyber security, and machine learning.”
She regularly attends the Android developer hangouts led by Android GDE Madona Wambua and Android developer Matt McKenna to learn more and get inspired by other Android developers in the community.
In her full-time job, Maryam is immersed in her work on the official Zain KSA app.
“It’s my job and my team’s job to give our millions of customers the best experience they can have, and I’m pushing myself to the limit to achieve that” she says. “I hope they like it.”
Maryam encourages other new developers, especially women, to share their knowledge.
“Communicate your knowledge–that makes you an expert because people will ask you follow-up questions that might give you different perspectives on certain things and shift your focus on learning new things constantly ” she says. “You serve others by sharing your knowledge.”
Follow Maryam on Twitter at @Mal7othify | Learn more about Maryam on LinkedIn.
The Google Developers Experts program is a global network of highly experienced technology experts, influencers, and thought leaders who actively support developers, companies, and tech communities by speaking at events and publishing content.
The GDE program team encourages qualified candidates that identify as women or non-binary to express interest in joining the community by completing this form.
Posted by Mauricio Vergara, Product Marketing Manager, with contibutions by Thousand Ant.
Lyft is singularly committed to app excellence. As a rideshare company — providing a vital, time-sensitive service to tens of millions of riders and hundreds of thousands of drivers — they have to be. At that scale, every slowdown, frozen frame, or crash of their app can waste thousands of users’ time. Even a minor hiccup can mean a flood of people riding with (or driving for) the competition. Luckily, Lyft’s development team keeps a close eye on their app’s performance. That’s how they first noticed a slowdown in the startup time of their drivers’ Android app.
They needed to get to the bottom of the problem quickly — figure out what it would take to resolve and then justify such an investment to their leadership. That meant answering a number of tough questions. Where was the bottleneck? How was it affecting user experience? How great a priority should it be for their team at that moment? Luckily, they had a powerful tool at their disposal that could help them find answers. With the help of Android vitals, a Google Play tool for improving app stability and performance on Android devices, they located the problem, made a case for prioritizing it to their leadership, and dedicated the right amount of resources to solving it. Here’s how they did it.
New priorities
The first thing Lyft’s development team needed to do was figure out whether this was a pressing enough problem to convince their leadership to dedicate resources to it. Like any proposal to improve app quality, speeding up Lyft Driver’s start-up time had to be weighed out against other competing demands on developer bandwidth: introducing new product features, making architectural improvements, and improving data science. Generally, one of the challenges to convincing leadership to invest in app quality is that it can be difficult to correlate performance improvements with business metrics.
They turned to Android vitals to get an exact picture of what was at stake. Vitals gives developers access to data about the performance of their app, including app-not-responding errors, battery drainage, rendering, and app startup time. The current and historical performance of each metric is tracked on real devices and can be compared to the performance of other apps in the category. With the help of this powerful tool, the development team discovered that the Lyft Driver app startup time was 15–20% slower than 10 other apps in their category — a pressing issue.
Next, the team needed to establish the right scope for the project, one that would be commensurate with the slowdown’s impact on business goals and user experience. The data from Android vitals made the case clear, especially because it provided a direct comparison to competitors in the rideshare space. The development team estimated that a single developer working on the problem for one month would be enough to make a measurable improvement to app startup time.
Drawing on this wealth of data, and appealing to Lyft’s commitment to app excellence, the team made the case to their leadership. Demonstrating a clear opportunity to improve customer experience, a reasonably scoped and achievable goal, and clear-cut competitive intelligence, they got the go-ahead.
How They Did It
Lyft uses “Time to interact” as a primary startup metric (also known as Time to full display). To understand the factors that impact it, the Lyft team profiled each of their app’s launch stages, looking for the impasse. The Lyft Driver app starts up in four stages: 1) First, start the application process 2) “Activity” kicks off the UI rendering. 3) “Bootstrap” sends network requests for the data necessary to render the home screen. 4) Finally, “Display” opens the driver’s interface. Rigorous profiling revealed that the slowdown occurred in the third, bootstrapping, phase. With the bottleneck identified, the team took several steps to resolve it.
First, they reduced unneeded network calls on the critical launch path. After decomposing their backend services, they could safely remove some network calls in the launch path entirely. When possible, they also chose to execute network calls asynchronously. If some data was still required for the application to function, but was not needed during app launch, these calls were made non-blocking to allow the launch to proceed without them. Blocking network calls were able to be safely moved to the background. Finally, they chose to cache data between sessions.
These may sound like relatively small changes, but they resulted in a dramatic 21% reduction in app startup time. This led to a 5% increase in driver sessions in Lyft Driver. With the results in hand, the team had enough buy-in from leadership to create a dedicated mobile performance workstream and add an engineer to the effort as they continued to make improvements. The success of the initiative caught on across the organization, with several managers reaching out to explore how they could make further investments in app quality.
Learnings
The success of these efforts contains several broader lessons, applicable to any organization.
As an app grows and the team grows with it, app excellence becomes more important than ever. Developers are often the first to recognize performance issues as they work closely on an app, but can find it difficult to raise awareness across an entire organization. Android vitals offers a powerful tool to do this. It provides a straightforward way to back up developer observations with data, making it easier to square performance metrics with business cases.
When starting your own app excellence initiative, it pays to first aim for small wins and build from there. Carefully pick actionable projects, which deliver significant results through an appropriate resource investment.
It’s also important to communicate early and often to involve the rest of the organization in the development team’s quality efforts. These constant updates about goals, plans, and results will help you keep your whole team on board.
Further Resources
Android vitals is just one of the many tools in the Android ecosystem designed to help understand and improve app startup time and overall performance. Another complementary tool, Jetpack Macrobenchmark, can help provide intelligence during development and testing on a variety of metrics. In contrast to Android vitals, which provides data from real users’ devices, Macrobenchmark allows you to benchmark and test specific areas of your code locally, including app startup time.
The Jetpack App startup library provides a straightforward, performant way to initialize components at application startup. Developers can use this library to streamline startup sequences and explicitly set the order of initialization. Meanwhile, Reach and devices can help you understand your user and issue distribution to make better decisions about which specs to build for, where to launch, and what to test. The data from the tool allows your team to prioritize quality efforts and determine where improvements will have the greatest impact for the most users. Perfetto is another invaluable asset: an open-source system tracing tool which you can use to instrument your code and diagnose startup problems. In concert, these tools can help you keep your app running smoothly, your users happy, and your whole organization supportive of your quality efforts.
If you’re interested in getting your own team on board for the pursuit of App Excellence (or join Lyft), check out our condensed case study for product owners and executives linked here.
Posted by Krish Vitaldevara, Director, Product Management
Google Play helps our developer community distribute the world's most innovative and trusted apps to billions of people. This is an ongoing process and we're always working on ways to improve app safety across the ecosystem.
In addition to the Google Play features and policies that are central to providing a safe experience for users, each Android OS update brings privacy, security, and user experience improvements. To ensure users realize the full benefits of these advances—and to maintain the trusted experience people expect on Google Play—we collaborate with developers to ensure their apps work seamlessly on newer Android versions.
We currently require new apps and app updates to target an Android API level within one year of the latest major Android OS version release. New apps and app updates that don’t meet this requirement cannot be published on Google Play. For exact timelines, please refer to this Help Center article.
Current target API Level requirements for new apps and app updates
Today, as part of Google Play’s latest policy updates, we are taking additional steps to protect users from installing apps that may not have the latest privacy and security features by expanding our target level API requirements.
Starting on November 1, 2022, existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level. As new Android OS versions launch in the future, the requirement window will adjust accordingly.
Target API Level requirements for existing apps, starting November 1
The rationale behind this is simple. Users with the latest devices or those who are fully caught up on Android updates expect to realize the full potential of all the privacy and security protections Android has to offer. Expanding our target level API requirements will protect users from installing older apps that may not have these protections in place.
The good news is that the vast majority of apps on Google Play already abide by these standards. For other apps, we know this will require additional attention, which is why we are notifying developers well in advance and providing resourcesfor those who need them.
We encourage you to:
Review our technical guide on migrating your app to meet Google Play's target API level requirements.
Review our Help Center article on the target API level requirements by Android OS.
Request an optional 6 month extension if you need more time for migration. The form will be available in your Developer Play Console later this year.
Current users of older apps who have previously installed the app from Google Play will continue to be able to discover, re-install, and use the app on any device running any Android OS version that the app supports.
This strengthened Target Level API policy is just one of the policy updates we announced today to expand user protections and improve user experiences on Google Play. We’ll continue to share updates about this important work that will help raise the bar for app privacy and security across the board, making Google Play and Android a safer place for everyone.
We recently announced the Privacy Sandbox on Android to enable new advertising solutions that improve user privacy, and provide developers and businesses with the tools to succeed on mobile. Since the announcement, we've heard from developers across the ecosystem on our initial design proposals. Your feedback is critical to ensure we build solutions that work for everyone, so please continue to share it through the Android developer site.
Today, we're releasing the first developer preview for the Privacy Sandbox on Android, which provides an early look at the SDK Runtime and Topics API. You'll be able to do preliminary testing of these new technologies and evaluate how you might adopt them for your solutions. This is a preview, so some features may not be implemented just yet, and functionality is subject to change. See the release notes for more details on what's included in the release.
Android SDK and 64-bit Android Emulator system images that include the Privacy Sandbox APIs. See the setup guide.
Device system images for Pixel 6 Pro, Pixel 6, Pixel 5a (5G), Pixel 5, Pixel 4, and Pixel 4a. This preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download only.
Topics API: Invoke the API and retrieve test values, representing a user's coarse-grained interests. See the documentation for detail.
SDK Runtime: Build and install a runtime-enabled SDK on a test device or emulator. Create a test app to load the SDK in the runtime and request the SDK to remotely render a WebView-based ad in the app. See the documentation for detail.
Now that our MAD Skills series on Architecture is complete, let’s do a quick wrap up of all the things we’ve covered in each episode!
Episode 1 — The data layer
Learn about the data layer and its two basic components: repositories and data sources. We'll also cover data immutability, error handling, threading, testing and more tricks and recommendations with Jose Alcérreca.
Episode 2 — The UI layer
Learn about the UI layer and its state. Tunji Dahunsi covers UI state representation, production and consumption all within the context of a unidirectional data flow app!
Episode 3 — Handling UI events
Learn all about UI events. I—Manuel Vivo—cover the different types of UI events, the best practices for handling them, and more!
Episode 4 — The domain layer
The Domain layer is an optional layer which sits between the UI and Data layers. Don Turner explains how the domain layer can simplify your app architecture, making it easier to understand and test.
Episode 5 — Organizing modules
Emily Kager shares a tip around organizing modules in Android apps.
Episode 6 — Entities
Garima Jain shares a tip about creating separate data models based on various Architecture layers in your project.
As one of the most widely used social media platforms, Twitter is always hunting for ways to better connect its users. At the same time, in order to efficiently build new features while maintaining existing ones, developers need supportive infrastructure. The Twitter engineering team turned to Jetpack Compose to kick-start a much needed overhaul of the app’s UI foundation. With Compose, developers can easily find and use the right APIs, fluidly style and modularize components, and ultimately build more with less code.
Twitter launches UI overhaul
A handful of teams such as the Android Client UI team, Customer Acquisition, Twitter Blue, and Communities teams revamped their development processes, inspiring excitement among Twitter’s engineers. “Several teams at Twitter have adopted Compose in their daily workflows,” said Sneha Patil, senior software engineer and technical lead on the Communities team for Twitter for Android. By removing the work of creating and setting up custom theming and attributes, Compose made writing functions and implementing design requirements significantly faster and more simple than what they experienced with Views. Jetpack Compose enabled these teams to work faster and more effectively, ensure reusability in their code, and easily onboard new engineers.
Revitalizing the development process
Creating dynamic content is straightforward with Compose. The Twitter team used the LazyColumn composable to build UI without the need for an Adapter or ViewHolder, simplifying the process of writing code that seamlessly brings layouts, themes, and styles to life. With fewer lines to write, development teams at Twitter decreased their boilerplate, experienced less bugs during development and releases, enabled UI experimentation, and sped up the testing processes. These improvements heightened productivity so developers could spend more time building what makes Twitter unique.
They also used Compose to build stateless components that are reusable across the app. The flexibility of Compose made it easier and faster to meet design requirements, making the setup of theming and styling easier for both new and experienced engineers to work with.
Building new features using Compose
Given the improvements experienced, they decided to build an entire new feature using Compose. They built the Communities feature, Twitter's dedicated space where users can engage in discussions they care about most, from the ground up using Compose. Based on the teams’ previous experience using Views for other features, building with Compose was much faster and they had less bugs. “It was like magic,” said Sneha, “It’s a game changer for how we can develop on Android with Compose.”
Compose boosts development output
Compose boosted the velocity and efficiency of Twitter engineers’ UI development. Developers easily incorporated and built with Compose, which made it easier for them to modularize code, reuse components, and break down dependencies. The team regularly utilizes UI experimentation, and Compose helped increase their confidence in knowing what the components that react to user interactions, data updates, and different screen sizes will look like in production.
These teams’ initial success with Compose inspired other development teams at Twitter to follow suit. Now, even engineers working on complex legacy components are looking into adopting it.
Overall, Compose has not only removed many of the obstacles the team experienced in Views — it also added enjoyment into the workflow, with some developers ready to abandon old methods for good. “I’m excited to write more Compose and never touch an XML layout again,” said Yoali Sotomayor Baqueiro, software engineer for Android Client UI at Twitter. “It makes developing UI not just easier but also much more fun and intuitive.”
Posted by Leo Olebe, Managing Director, Games Partnerships, Google Play
Today we are launching Google Play Coffee breaks, a new series where members of our partnerships team get together with apps and games companies to exchange tips and personal lessons gained from the industry, as well as insights gained from participating in some of our Play programs. All in enough time to fit into your coffee break!
To kick it all off, I enjoyed a virtual coffee with Nimrod Kimhi, Co-founder & CEO, at Jimjum Studios, a small games company from Israel. They participated in the 2021 edition of the Indie Games Festival, making it into the top 10 finalists, and later took part in the Indie Games Accelerator. We felt it was time for us to check back in on the growth they’ve been achieving.
Watch the full Coffee breaks episode and read my reflections below:
Launching their first game, Froglike: The Frog Roguelike, just one year ago in 2021, the team of five friends have already made an impact on the mobile game ecosystem early on in their business journey.
Nim described how their studio is composed of two brothers, two childhood friends, and a musician who they convinced to get onboard their team. Each has a mix of talents and expertise which compliment each other and fit together. And I think this is one of the most important parts of succeeding in this industry. A great team is able to challenge each other and put new ideas on the table, but also come together and agree on those big decisions that are going to move your business forward.
I really enjoyed catching up with Nim during our first Google Play Coffee breaks. What I found most rewarding was to hear directly from Nim about his experience of the Indie Games Accelerator and Festival. It was actually Jimjum’s chief game designer who initially convinced Nim to sign up for the contest. Despite his initial hesitations of how the competition might interrupt their progress with building the game, Nim says now that the learnings they got from the program saved their teamthree years worth of mistakes.
Lessons learned in the game industry
The first? Test early. Nim couldn’t have said it better - make the MVP of your product and get feedback from the gaming community as soon as possible. This is even more important with games because you do have that abstract and subjective layer of what it means to be ‘fun’. You must go through that constant loop of feedback from players and iterations of your game, even though it can be tempting to just push forward with your artistic vision.
I think this is a really important insight to highlight. From my own experiences here at Google Play and in the mobile gaming industry, one of the most exciting parts about growing a games business is handing your game to the players and discovering ideas that you hadn’t considered yourself. It’s about being flexible, rolling with the punches, and being open to the learning journey rather than rigidly sticking to your original blueprint. Learning from others is what is going to take your game from good to great.
The second? Don’t lose the core heart of your game. Nim described how every team should know and agree on their Northstar when designing the game, and stick to it. It is easy to get distracted by all the analytics and feedback - and also just through the noise that is the mobile industry and the commercial pressures of making a game. But I agree with Nim, it is so important to never lose the heart of what you are building, and your passion behind it, in order to create a truly unique experience for your users.
Success for small Indie studios
After participating in our Indie Games Accelerator, I was interested to hear from Jimjum about the learnings they had gained, and how they were able to use them to build such a solid foundation on Google Play and beyond.
One of the main areas that Nim raised was the need for every game to have a solid marketing strategy. Nim’s key focus is to work on a distribution plan, using channels like online communities to drive awareness of their title. A big part of the strategy is to find key influencers in the field and get them involved with their game. It is also about having a launch phase that allows them to take it step-by-step, rather than one big launch. This meant waiting until they were confident their game was ready, prioritizing certain geographical locations before others, and - of course - testing every step of the way.
As well as a marketing strategy, I’d add that it’s also about being open to the learning journey. Absorb as much knowledge as you can. There are so many others out there who have been down this road before, so learn from their successes and (perhaps more importantly) their mistakes. As you grow, use your unique perspectives and ideas to then share what you know with others and help build that circle of reciprocity.
Finally, in a world of millions of gamers, you can find your audience. It may take longer than you imagine, it may be harder, but they are there.
It was a genuine pleasure to chat to Nim about his experiences. I can’t wait to see Jimjum’s continued growth and new gaming adventures. It is studios like Jimjum that inspire me and my team to keep supporting indies in all ways that we can - whether that’s through programs like the Indie Games Accelerator and the Indie Games Festival (you can sign up now to hear when submissions open for the 2022 editions) or through more resources and tools to help them grow even further.
We are looking forward to continuing to learn from more businesses, and see what you all do next. Stay tuned for the next episode of Coffee Breaks.
Do you have any questions for Jimjum? What are your own tips for other indie studios? Let us know on Twitter.
We also realize that it can be challenging for developers to keep up with the pace of change in this evolving privacy and security landscape. We’ve been mindful to give developers clearer updates, more time for substantial changes, and more helpful information through Inbox Console Messages, global webinars, and additional education resources. Today, we’re excited to share more about what’s ahead in 2022 to give you plenty of time to prepare.
What we look forward to this year
Giving everyone a clear way to understand an app’s data safety practices
Developers want to explain data safety to users in a clear and simple way. In the upcomingData safety section in your app’s Play store listing, you can share how your app collects, shares, and protects user data. Users told us that they value having this information to help them decide if an app is right for them. They’ll start to see the Data safety section in Google Play store in late April, so make sure to submit your Data safety form soon. Completed Data Safety forms will be required for all app updates starting July 20.
Building a more privacy-friendly approach to advertising
We recently announced that we’re expanding the Privacy Sandbox initiative to Android. We’re working on innovative solutions to improve user privacy, while continuing to support key mechanisms that developers rely on to build their businesses and provide access to free apps for everyone. We’re building this technology in close collaboration with developers. Join our email newsletter to stay updated.
Protecting developers' apps from privacy and fraudulent activity
Last fall, we started rolling out the new Play Integrity API to help you protect their games and apps and ensure that users have the intended experience that you designed. Now, everyone has access to this new API, making it easier to detect suspicious traffic and respond faster to issues like fraud and cheating. We've built this in a future-forward way so that you can easily get new features with little build time required to upgrade. Learn how to set it up for your apps here.
Helping developers navigate SDKs
Developers shared that they want faster communication from SDK providers about critical updates, so last year we gave SDK providers a way to notify you about urgent issues in your Google Play Console. You’ve also shared that you want to learn more about an SDK’s safety and reliability to avoid wasting build time or exposing users to unsafe practices. In a few months, we’ll start sharing information like an SDK’s adoption levels, its retention rate, and the runtime permission it uses to help you choose the right SDK for your business and users.
Enhancing protections for kids and families
Last year, we continued to refine our advertising restrictions and parental control requirements to further enhance privacy and safety for kids. Eligible developers can now add a badge to their upcoming Data safety section, highlighting that they’re committed to following our Families policy. You’ll also see continued policy updates this year designed to help protect kids' safety and privacy. Join our policy webinars or watch our PolicyBytes to stay updated.
Responsible Data Collection and Use
Developers should only collect and use the data required for app functionality and improvement. For practical tips on this front, you can view our best practices guide. This year, we’re continuing to align permissions more closely with the appropriate use cases. We’re also in active conversations with developers about ways to mitigate risks from apps that leverage APIs in older Android OS versions. Stay tuned to our policy update emails, as we’ll share more soon.
Thank you for your partnership in making Google Play a safe and trustworthy platform for everyone.
Posted by Greg Hartrell, Product Director, Games on Play/Android
With over three billion players showing strong engagement worldwide, the games market continues to remain resilient and grow beyond expectations. As we look ahead this year, the influx of new and returning players creates a great opportunity for developers to scale their games businesses.
The Google for Games Developer Summit returns virtually on March 15, 2022 at 9AM Pacific. From mobile to cloud, learn about our new solutions for game developers that make it easier to build high-quality games and reach audiences around the world.
Join us for the keynote at 9AM Pacific followed by over 20 developer sessions on-demand. We’ll share deep-dives and updates on the Android Game Development Kit, Google Play Games beta on PC, Play Asset Delivery, Play Console, and more. The summit is open for all. Check out the full agenda today at g.co/gamedevsummit.
In November 2020, we announced that this plugin has been deprecated in favor of better solutions, and we recommended removing the plugin from your projects. We know many developers still depend on this plugin’s features, and we’ve extended the support timeframe so you have more time to complete your migrations.
We are now setting a deadline for these migrations: the plugin will be removed in Kotlin 1.8, which is expected to be released by the end of 2022. At that time, you won’t be able to update your project to newer Kotlin versions if it still depends on the Kotlin Android Extensions plugin. This means that now is the time to perform the necessary migrations in your projects.
Instead of synthetics, we recommend using View Binding, which generates type-safe binding classes from XML layout files. These bindings provide convenient access to view references and they work safely for layouts with multiple configurations. See the migration guide for detailed instructions on how to adopt View Binding. If you encounter any issues, you can report a bug on the Issue Tracker.
When building new features, consider using Jetpack Compose, Android's modern UI toolkit. Layouts built with Compose are declarative Kotlin code, eliminating the need to work with view references.
Another feature included in the plugin is Parcelize, which helps you create parcelable classes. Parcelize is now available in the standalone kotlin-parcelize plugin with unchanged functionality. To get up and running with the new plugin, check out the Parcelize documentation page.
If you’re still using the Kotlin Android Extensions Gradle plugin, kick off your migration in time so that you can keep upgrading to new Kotlin releases in the future. This will enable you to use the latest language features and take advantage of tooling and compiler improvements.
Posted by Jose Alcérreca, Android Developer Relations Engineer
As apps increase in functionality and complexity, manually testing them to verify behavior becomes tedious, expensive, or impossible. Modern apps, even simple ones, require you to verify an ever-growing list of test points such as UI flows, localization, or database migrations. Having a QA team whose job is to manually verify that the app works is an option, but fixing bugs at that stage is expensive. The sooner you fix a problem in the development process the better.
Automating tests is the best approach to catching bugs early. Automated testing (from now on, testing) is a broad domain and Android offers many tools and libraries that can overlap. For this reason, beginners often find testing challenging.
In response to this feedback, and to accommodate for Compose and new architecture guidelines, we revamped two testing sections on d.android.com:
Training
Firstly, there is the new Testing training, which includes the fundamentals of testing in Android with two new articles: What to test, an opinionated guide for beginners, and a detailed guide on Test doubles.
Faking dependencies in unit tests
After providing an overview of the theory, the guide focuses on practical examples of the two main types of tests.
Local tests that run on a workstation and are typically unit tests.
We included an article that describes Advanced test setup features such as working with different variants, the instrumentation manifest options, or the Android Gradle Plugin settings.
These two new sections should give you a general notion of how and where to test your Android app. To learn more about testing specific features and libraries, you should check out their respective documentation pages. For example: Testing Kotlin flows, Test Navigation, or the Hilt testing guide.
Sadly, machines can't automatically verify the correctness of our documentation, so if you find errors or have suggestions, please file a bug on our documentation issue tracker.
Every day, billions of people around the world pull out their Android device to help them get things done. That Android works well for each and every one of them is ensured in part through a collaborative process with you, our developer community, sharing feedback to help us make Android stronger.
Today, we’re sharing a first look at the next release of Android, with the Android 13 Developer Preview 1. With Android 13 we’re continuing some important themes: privacy and security, as well as developer productivity. We’ll also build on some of the newer updates we made in 12L to help you take advantage of the 250+ million large screen Android devices currently running.
This is just the start for Android 13, and we’ll have lots more to share as we move through the release. Read on for a taste of what’s new, and visit the Android 13 developer site for details on downloads for Pixel and the release timeline. As always, it’s crucial to get your feedback early, to help us include it in the final release. We’re looking forward to hearing what you think, and thanks in advance for your continued help in making Android a platform that works for everyone!
Privacy & security at the core
People want an OS and apps that they can trust with their most personal and sensitive information. Privacy is core to Android’s product principles, and Android 13 focuses on building a responsible and high quality platform for all by providing a safer environment on the device and more controls to the user. In today’s release, we’re introducing a photo picker that allows users to share photos and videos securely with apps, and a new Wi-Fi permission to further minimize the need for apps to have the location permission. We recommend trying out the new APIs and testing how the changes may affect your app.
Photo picker and APIs - To help protect photo and video privacy of users, Android 13 adds a system photo picker — a standard and optimized way for users to share both local and cloud-based photos securely. Android’s long standing document picker allows a user to share specific documents of any type with an app, without that app needing permission to view all media files on the device. The photo picker extends this capability with a dedicated experience for picking photos and videos. Apps can use the photo picker APIs to access the shared photos and videos without needing permission to view all media files on the device. We plan to bring the photo picker experience to more Android users through Google Play system updates, as part of a MediaProvider module update for devices (excepting Go devices) running Android 11 and higher. Give photo picker APIs a try and let us know your feedback!
Photo picker provides a consistent, secure way for users to give apps access to specific photos and videos.
Nearby device permission for Wi-Fi - Android 13 introduces the NEARBY_WIFI_DEVICES runtime permission (part of the NEARBY_DEVICES permission group) for apps that manage a device's connections to nearby access points over Wi-Fi. The new permission will be required for apps that call many commonly-used Wi-Fi APIs, and enables apps to discover and connect to nearby devices over Wi-Fi without needing location permission. Previously, the location permission requirements were a challenge for apps that needed to connect to nearby Wi-Fi devices but didn’t actually need the device location. Apps targeting Android 13 will be now able to request the NEARBY_WIFI_DEVICES permission with the “neverForLocation” flag instead, which should help promote a privacy-friendly app design while reducing friction for developers. Learn more.
Developer productivity and tools
Android 13 also brings new features and tools for developer productivity. Helping you create beautiful apps that run on billions of devices is one of our core missions – whether it’s in Android 13 or through our tools for modern Android development, like a language you love in Kotlin or opinionated APIs with Jetpack. By helping you work more productively, we aim to lower your cost of development so you can focus on continuing to build amazing experiences. Here’s some of what’s new in today’s release.
Quick Settings Placement API - Quick Settings in the notification shade is a convenient way for users to change settings or take quick actions without leaving the context of an app. For apps that provide custom tiles, we’re making it easier for users to discover and add your tiles to Quick Settings. Using a new tile placement API, your app can now prompt the user to directly add your custom tile to the set of active Quick Settings tiles. A new system dialog lets the user add the tile in one step, without leaving your app, rather than having to go to Quick Settings to add the tile.
Themed app icons - In Android 13 we’re extending Material You dynamic color beyond Google apps to all app icons, letting users opt into icons that inherit the tint of their wallpaper and other theme preferences. All your app needs to supply is a monochromatic app icon and a tweak to the adaptive icon XML. We’re encouraging all developers to provide compatible icons to help provide a consistent experience for users who have opted in. Themed app icons are initially supported on Pixel devices and we’re working with our device manufacturer partners to bring them to more devices. Learn more.
Per-app language preferences - Some apps let users choose a language that differs from the system language, to meet the needs of multilingual users. Such apps can now call a new platform API to set or get the user’s preferred language, helping to reduce boilerplate code and improve compatibility when setting the app’s runtime language. For broader compatibility, we'll be adding a similar API in an upcoming Jetpack library. Learn more.
Faster hyphenation - Hyphenation makes wrapped text easier to read and helps make your UI more adaptive. In Android 13 we’ve optimized hyphenation performance by as much as 200% so you can now enable it in your TextViews with almost no impact on rendering performance. To enable faster hyphenation, use the new fullFast or normalFast frequencies in setHyphenationFrequency(). Give faster hyphenation a try and let us know what you think!
Programmable shaders - Android 13 adds support for programmable RuntimeShader objects, with behavior defined using the Android Graphics Shading Language (AGSL). AGSL shares much of its syntax with GLSL, but works within the Android rendering engine to customize painting within Android's canvas as well as filtering of View content. Android internally uses these shaders to implement ripple effects, blur, and stretch overscroll, and Android 13 enables you to create similar advanced effects for your app.
OpenJDK 11 updates - In Android 13 we’ve started the work of refreshing Android's Core Libraries to align with the OpenJDK 11 LTS release, with both library updates and Java 11 programming language support for app and platform developers. We also plan to bring these Core Library changes to more devices through Google Play system updates, as part of an ART module update for devices running Android 12 and higher. Learn more.
App compatibility
With each platform release we’re working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 13 we’ve made most app-facing changes opt-in to give you more time, and we’ve updated our tools and processes to help you get ready sooner.
More of Android updated through Google Play - In Android 13 we’re continuing to expand our investment in Google Play system updates (Project Mainline) to give apps a more consistent, secure environment across devices, and to deliver new features and capabilities to users. We can now push new features like photo picker and OpenJDK 11 directly to users on older versions of Android through updates to existing modules. We’ve also added new modules, such as the Bluetooth and Ultra wideband modules, to further expand the scope of Android’s updatable core functionality.
Optimizing for tablets, foldables, and Chromebooks - With all the momentum in large screen devices like tablets, foldables, and Chromebooks, now is the time to get your apps ready for these devices and design fully adaptive apps that fit any screen. You can get started using our guidance on optimizing for tablets, then learn how to build for large screens and develop for foldables.
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 not only final SDK/NDK APIs, but also final internal APIs and app-facing system behaviors. This year we’re expecting to reach Platform Stability in June 2022, 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 13
The Developer Preview has everything you need to try the Android 13 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 - complete setup instructions are here. For phones, you can get started on a device today by flashing a system image to a Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5, Pixel 4a (5G), Pixel 4a, Pixel 4 XL, or Pixel 4 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 even broader testing, GSI images are available.
When 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 or give us direct feedback by survey for selected features from the feedback and requests page.
Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 13. Just install your current published app onto a device or emulator running Android 13 and test.
Test your app with opt-in changes - Android 13 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s extremely 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 13 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. More here.
As we reach our Beta releases, we'll be inviting consumers to try Android 13 as well, and we'll open up enrollments for the Android Beta program at that time. For now, please note that Android Beta is not yet available for Android 13.
We’re excited to announce that Material You, specifically dynamic color, will soon be available on more Android 12 phones globally, including devices by Samsung, OnePlus, Oppo, Vivo, realme, Xiaomi, Tecno, and more!
With the release of Android 12 and the introduction of Material You, we made the Android experience more fluid and personal than ever for our users. The gorgeous new design brought to life experiences such as a more dynamic touch ripple, a silky-smooth scroll, and a spacious layout. But the star of the show was, and continues to be, dynamic color – pick your favorite wallpaper and the entire phone experience transforms to better express you, from your home screen to some of your favorite apps.
With Material You, personalization is now a defining trait of Android that our ecosystem will continue building on for years to come. We want to make sure that you, our developers, have the confidence to join us on the journey and bring a more personal look and feel to users through your apps.
A Gmail rainbow with different wallpaper-based themes, shown on some of the Android device experiences that will support Material You
As more Android 12 devices land in the next couple months, our OEM partners are working with us to ensure that key design APIs, especially around dynamic color, work consistently across the Android ecosystem so developers can have peace of mind and users can benefit from a cohesive experience.
To better help you understand how to implement dynamic color and fit it into your overall brand story, the Material team has published the comprehensive Customizing Material article with codelabs and guides to get started with Views or Jetpack Compose. Watch for ongoing updates to Material Theme Builder and Material Color Utilities in the coming months to provide you with the tools you need for design and implementation.
Visualize dynamic color in your app with the Material Theme Builder
Google apps (Gmail, Photos, Chrome, and many more) have used the very same tools and guidance to bring the color story to life on their branded experiences, and we’re excited for you to hop on board as well. As you learn more about how color can harmonize with user choice and work with dynamic color in your app, we’d love to get your feedback via the Material Android issue tracker. Happy coloring!
Today, we’re releasing version 1.1 of Jetpack Compose, Android's modern, native UI toolkit, continuing to build out our roadmap. This release contains new features like improved focus handling, touch target sizing, ImageVector caching, and support for Android 12 stretch overscroll. Compose 1.1 also graduates a number of previously experimental APIs to stable and supports newer versions of Kotlin. We've already updated our samples, codelabs, and Accompanist library to work with Compose 1.1.
New stable features and APIs
Image vector caching
Compose 1.1 introduces image vector caching bringing big performance improvements. We’ve added a caching mechanism to painterResource API to cache all instances of ImageVectors that are parsed with a given resource id and theme. The cache will be invalidated on configuration changes.
Touch target sizing
With respect to Compose 1.0, Material components will expand their layout space to meet Material accessibility guidelinestouch target size. For instance, a RadioButton's touch target will expand to a minimum size of 48x48dp, even if you set the RadioButton's size to be smaller. This aligns Compose Material to the same behavior of Material Design Components, providing consistent behavior if you mix Views and Compose. This change also ensures that when you create your UI using Compose Material components, minimum requirements for touch target accessibility will be met.
If you find this change breaks existing layout logic, set LocalMinimumTouchTargetEnforcement to false to disable this behavior, but please be mindful this might reduce the usability of your app, and should be used with caution.
Wondering what’s next? Check out our updated roadmap to see the features we’re currently thinking about and working on, such as lazy item animations, downloadable fonts, moveable content, and more!
Jetpack Compose is stable, ready for production, and continues to add the features you’ve been asking us for. We’ve been thrilled to see tens of thousands of apps start using Jetpack Compose in production already and we can’t wait to see what you’ll build!
We’re grateful for all of the bug reports and feature requests submitted to our issue tracker over the Alphas and Betas - they help us to improve Compose and build the APIs you need. Do continue providing your feedback and help us make Compose better!
Google Chrome is the most widely used browser globally, and the Chrome team wants to ensure their users have a great experience across all devices. Many Chrome users have been requesting more productivity features on their mobile, tablet, and foldable devices to better match the capabilities of Chrome on desktop. To meet these needs, the team decided to invest in building features that encourage multitasking capabilities. While the team built this for phones as well, they wanted to especially focus on implementing these features where people would use them the most: large screen devices such as tablets and foldables.
What they did
The team first decided to focus on building a way for people to open multiple Chrome windows (instances) side by side. They took advantage of 12L features such as the taskbar and also took advantage of the Samsung edge panel.
They utilized the singleInstancePerTask launch mode to build the side-by-side functionality. They wanted to balance allowing people to use many windows at once with making sure the feature was still usable. The team researched usability best practices, observed other multi-window experiences on large screen devices, and thought through limitations to ensure optimal device memory usage. They determined people could comfortably use up to five windows side by side on large screen devices, and the team updated their app to support this functionality.
The team wanted to make it easier for their users to take advantage of this feature, so they added a “New Window” shortcut in the menu. They used the new capability of intent flag combo LAUNCH_ADJACENT|NEW_TASK to create this shortcut. Having this feature be more prominently displayed in the product greatly improved the usage. They saw multi-window usage improve by 18x.
Results
This is a new feature, and the Chrome team has already seen that multi-instance for the Chrome app is used 42% more on tablets and foldables than on phones that support the feature. This usage demonstrates the functionality resonated well with Chrome users on large screen devices, and that it was worth investing in building these features to enhance the experience for Chrome users on large screens.
They also had very positive feedback from their large screen users in the form of app reviews. “This app is fabulous 👌! You can split screen, change tabs, and much more. You can also play a lot of games in it. I prefer to five star this app.”
The team has future plans to further improve the Chrome experience on large screens to help their users be more productive.
Get started
Learn more about how you can get started with optimizing your app for large screens.
Posted by the Smule Engineering team: David Gayle, Chris Manchester, Mark Gills, Trayko Traykov, Randal Leistikow, Mariya Ivanova.
Executive Summary
As the most downloaded singing app of all time, Smule Inc. has been investing on Android to improve the overall audio quality audio and more specifically to improve the lower latency, i.e. allowing singers to hear their voices in the headset as they perform. The teams specialized in Audio and Video allocated a significant part of 2021 into making the necessary changes to convert the Smule application used by over ten million Android users from using the OpenSL audio API to the Oboe audio library, enabling roughly a 10%+ increase in recording completion rate.
Introduction
Smule Inc. is a leader in karaoke, with an app that helps millions of people sing their favorite songs and share performances daily. The Smule application goes beyond traditional karaoke by focusing on co-creation, offering users the unique opportunity to share music and collaborate with friends, other singers on the platform, and their favorite music artists. Audio quality is paramount, and, in 2020, the Smule team saw potential to enhance the experience on Android.
Smule’s legacy OpenSL implementation wasn’t well-suited to leverage the blazing-fast hardware of new devices while supporting the diverse devices across its world-wide market. Smule’s development team determined that upgrading the audio system was a necessary and a logical improvement.
Oboe Rollout Strategy
Smule was faced with two possible routes for improvement: directly targeting AAudio, a high-performance Android C audio API introduced in Android O designed for applications that require low latency, or Oboe, which wraps both AAudio and OpenSL internally. After careful evaluation, Smule’s development team opted for Oboe’s easy-to-use code base, and broad device compatibility, and robust community support, which achieved the lowest latency and made the best use of the available native audio.
The conversion to Oboe represented a significant architectural and technologicaltechnology evolution. As a result, Smule approached the rollout process conservatively, with a planned, gradual release that started with a small selection of device models to d validate quality. Week after week, the team enabled more devices (reverting a limited number of devices exhibiting problems in Oboe back to OpenSL). This incremental, methodical approach helped to minimize risk and allowed the engineering team to handle device-specific issues as they occurred.
Improving the Audio Quality Experience
Smule switched to Oboe to help improve the app experience. They hoped to reduce dramatically audio playback crashes, eliminate issues such as echo and crackling during recording, and reduce audio latency. A recent article in the Android Developers blog shows that the average latency of the twenty most popular devices decreased from 109 ms in 2017 to 39ms today using Oboe. Whereas a monitoring delay of 109ms is heard as a distinct echo which interferes with live singing, 39ms is beneath the acceptable threshold for real-time applications. The latencies of top devices today are all within 22ms of one another, and this consistency is a big plus.
The lift in recording completion rate Smule has seen using Oboe is likely due to this lower latency, allowing singers to hear their voices in the headset as they perform with Smule’s world-class audio effects applied, but without an echo.
Using an effective collaborative GitHub portal dedicated to Oboe, the Google team played a significant role in Smule’s Oboe integration, providing them with key insights and support. Working together, the two teams were able to launch the largest Oboe deployment to date, reaching millions of active users. The Smule team contributed to addressing some Oboe code issues, and the Google team coordinated with certain mobile device makers to further improve Oboe's compatibility.
Audio quality is of the utmost importance to our community of singers, and we're thankful for our shared commitment to delivering the best possible experience as well as empowering musical creation on Smule. - Eric Dumas, Smule CTO.
Given the massive scale of the operation, it was only natural to face device-specific issues. One notable example was an OS built-in functionality that injected echo sound effects in the raw audio stream, which prevented Smule from correctly applying its own patented DSP algorithms and audio filters. Google’s team came to the rescue, providing lightning fast updates and patches to the library. The process of reporting Oboe issues was straightforward, well defined, and handled in a timely manner by the Google team.
Smule overcame other device-specific roadblocks together, including errors with specific chipsets. As an example, when Oboe was asking for mono microphone input, a few devices provided stereo inputs mixed into one fake mono microphone input. Smule created a ticket in Oboe’s GitHub, providing examples and reproducing the issue using the Oboe tester app.
The Google-developed Oboe tester app was a helpful tool in solving and identifying issues throughout the implementation. It proved especially useful in testing many of the features of Oboe, AAudio, and OpenSL ES, as well as testing Android devices, measuring latency and glitches, and much more. The application offers a myriad of features that can help to simulate almost any audio setup. The Oboe tester can also be used in automated testing, by launching it from a shell script using an Android Intent. Smule relied heavily on the automation testing, given the large number of devices covered in the integration.
Once Smule was confident the device-specific issues were resolved and the Oboe audio was stable enough, Smule switched to a wider split testing rollout approach. In just a few weeks, Smule increased the population using Oboe from 10% to 100% percent of the successful devices, which was only possible due to the positive feedback and green KPI metrics Oboe received continuously throughout the release journey.
The results speak for themselves. Smule users on Oboe are singing more - it’s as simple as that. Unique karaoke recordings and performance joins, or duets, increased by a whopping 8.07%, Unique uploads by 3.84%, and song performances were completed by 4.10% more. Smule has observed in Q3 and Q4 2021 an increase of the recording completion rate by 10%+.
Using the Firebase Crashlytics tool by Google, Smule has seen a decline in audio-related crashes since the full Oboe release, making the app more stable - even on lower-end devices. Smule’s dedicated customer support team was thrilled to report a 33% reduction in audio-related complaints, including issues like (unintended) robot voice and echo.
The decision to switch to Oboe has paid off in spades. The application is functioning better than ever and Smule is well-equipped to face further advancements in audio and hardware with the updated technology. Most importantly, Smule users are happy and making music, which is what it’s all about.
Posted by Phalene Gowling, Product Manager, Google Play
Last year, mobile game consumer spending grew 7.3% to $93.2 billion with no signs of slowing down. In this competitive, growing market, effectively monetizing your audience has never been more important. But without access to a strategy consultant, how can you know if your monetization strategy is as strong as it can be?
That’s why we’re expanding the suite of tools available in Play Console to help it be exactly that. Last year, we released new engagement and monetization metrics on the Statistics page to help you grow your business, and now we’re pleased to announce new strategic guidance tools to help you drive successful monetization.
In this new section, you’ll see our metric-driven guidance to help you better monetize your game by:
Contextualizing your topline revenue: Understand how your game’s revenue metrics contribute to your overall business goals, and learn when to prioritize optimizing for one metric over another.
Identifying opportunities: Find out where there is an opportunity to improve a metric by benchmarking against peer groups, and explore insights by country.
Recommending next steps: Learn how to take advantage of monetization opportunities with specific actions you can take right away.
The strategic guidance metric hierarchy. (Learn more or visit our Play Academy for specific courses like monitoring KPIs.)
We’ve spent the last couple of years perfecting our guidance, and testing the dashboard with selected partners. Feedback on our strategic guidance has been positive — and we hope you’ll find it useful, too.
“This is extremely useful! These type of insights are actually what we expect from Google, because this is something that really can help us to scale our business.”
- Product Manager at Gameloft
Understand key monetization drivers and their relationships with the metric hierarchy
Strategic guidance can be found in Financial reports within Play Console. In partnership with experts in mobile games growth, we’ve included primary monetization metrics (including new metrics) and their relationships to help you easily assess your performance and measure against your peers. You can see all the metrics in this Help Center article.
The metric hierarchy is a tool to help you understand how you and your teams can directly influence the lower-level metrics of your games performance, like buyer conversions, which contribute to your overall top-line business performance. Using peerset comparisons and per-country breakdowns, you can quickly identify your biggest growth opportunities: what markets are underperforming and where you are a market leader.
Explore metric analysis to turn insights into action
Select a metric and explore it in detail to track your performance over time. Strategic guidance shows you a breakdown of your chosen metric by location to help you spot opportunities to expand your game globally. The detailed metric analysis also helps you identify where a small investment has an outsized return.
Strategic guidance metric recommendation example for returning daily buyer ratio.
Whether you’ve created a casual game or an RPG, the metric-specific recommendations are designed to be insightful and relevant to a variety of game developers. They can be used to help you diversify your promotional content, refine your game mechanics, or test new price points that enable purchasing power parity.
Get IAP monetization guidance today, with more insights to come
With an increasing number of developers shifting focus from an ads-only monetization business model to include in-app purchases (IAP), we’ve developed strategic guidance to be most relevant for developers that include IAP-monetization as part of their overall strategy. With this launch, we’re excited to bring growth consulting opportunities to these game developers at scale. Stay tuned for more launches this year to help you successfully drive your revenue growth.
Posted by Kateryna Semenova, DevRel Engineer; Rahul Ravikumar, Software Engineer; Chris Craik, Software Engineer
Why is startup time important?
A lot of apps find correlation between app performance and user engagement. People expect apps to be responsive and fast to load. Startup time is one of the major metrics for app performance and quality.
Some of our partners have already invested a lot of time and resources for app startup optimizations. For example, check out the Facebook story.
In this blog post we’ll discuss Baseline Profiles and how they improve app and library performance, including startup time by up to 40%. While this blogpost focuses on startup, baseline profiles also significantly improve jank as well.
History
Android 9 (API level 28) introduced ART optimizing profiles in Play Cloud to improve app startup time. On average, we’ve seen that apps' cold starts are at least 15% faster across a variety of devices when Cloud Profiles are available.
How do Profiles work?
When the app is first launched after install or update, its code runs in an interpreted mode until it is JITted. In an APK, Java and Kotlin code is compiled as dex bytecode, but not fully compiled to machine code (since Android 6), due to the cost of storing and loading fully compiled apps. Classes and methods that are frequently used in the app, as well as those used for app startup, are recorded into a profile file. Once the device enters idle mode, ART compiles the apps based on these profiles. This speeds up subsequent app launches.
Starting with Android 9 (API level 28), Google Play also provides Cloud Profiles. When an app runs on a device, the profiles generated by ART are uploaded by the Play Store app and aggregated in the cloud. Once there are enough profiles uploaded for an application, the Play app uses the aggregated profile for subsequent installs.
Problem
While Cloud Profiles are great when they are available, they aren't always ready to be used when an app is installed. Collecting and aggregating the profiles usually takes several days, which is a problem when many apps update on a weekly basis. Many users will install an update before the Cloud Profile is available. The Google Android team started looking for other ways to improve the latency of profiles.
Solution
Baseline Profiles are a new mechanism to provide profiles which can be used on Android 7 (API level 24) and higher. A baseline profile is an ART profile generated by the Android Gradle plugin using a human readable profile format that can be provided by apps and libraries. An example might look like this:
The binary profile is stored in a specific location in the APK assets directory
(assets/dexopt/baseline.prof).
Baseline Profiles are created during build time, shipped as part of the APK to Play, and then sent from Play to users when an app is downloaded. They fill the gap in the ART Cloud Profile pipeline, when Cloud Profiles are not yet available, and automatically merge with Cloud Profiles when they are.
This diagram displays the baseline profile workflow from creation through end-user delivery.
One of the biggest benefits of Baseline Profiles is that they can be developed and evaluated locally so developers can see realistic end-user performance improvements. They are also supported on a lower version of Android(7 and higher) than Cloud Profiles, which are only available starting in Android 9.
Impact
App devs
In early 2021, Google Maps switched from a two-week to a one-week release cycle. More frequent updates meant more frequently discarding local pre-compilation, and more users experiencing slow launches without Play Cloud Profiles. By using Baseline Profiles, Google Maps improved their average startup time by 30% and saw a corresponding increase in searches by 2.4%, an immense gain for such an established app.
Library devs
Code in a library is just like that of an app - it's not fully compiled by default, which can be a problem if it does significant work on the critical path of startup.
Jetpack Compose is a UI library that is not a part of the Android system image and thus not fully compiled when installed, unlike much of the Android View toolkit code. This was causing performance problems, especially for the first few cold launches of the app.
To solve this problem, Compose uses profile installer. It ships baseline profile rules which reduce startup time and jank in Compose apps.
Google PlayStore’s search results page has been re-written with Compose. After incorporating the Baseline Profile rules from Compose, time to render the initial search results page with images improved by ~40%.
The Android team has also added Baseline Profiles to relevant AndroidX libraries. This benefits all Android apps using these libraries. Constraint Layout has found shipping profile rulesreduces animation frame times by more than one millisecond.
How to use Baseline Profiles
Create a custom Baseline Profile
All apps and library developers can benefit from including Baseline Profiles. Ideally, developers create profiles for their most critical user journeys to ensure that those journeys have consistently fast performance regardless of whether cloud profiles are available. Check out the detailed guide on how to set up Baseline Profiles for both app and library developers.
Update dependencies
If you are not ready to generate Baseline Profiles for your app right now, you can still benefit from them by updating your dependencies. If you build with Android Gradle Plugin 7.1.0-alpha05 or newer, you'll get Baseline Profiles included in your APK that are already provided by libraries (such as Jetpack). Google Play compiles your app with these profiles at install time. You can supplement these profiles as part of building your application.
Today we’re announcing the availability of version 1.2 beta of the Car App Library, enabling app developers to start building their navigation, parking, and charging apps for Android Automotive OS.
As announced earlier, drivers of Polestar 2 and Volvo cars can now download charging (ChargePoint, PlugShare), parking (Spothero, Parkwhiz), and navigation (Flitsmeister, Sygic) apps developed with the Car App Library by joining the Google Group and opting-in to each app's beta on the Google Play store, with your Gmail account.
Car App Library apps on Android Automotive OS are automatically rendered to be consistent with the rest of the experience within each car, without additional work needed from developers.. For example,
Polestar 2
Volvo
Polestar 2 setting with labeled On / Off switches for PlugShare
Volvo settings with sliding switches for PlugShare
Polestar 2 sign-in screen for SpotHero
Volvo sign-in screen for SpotHero
Example of app customization on Android Automotive OS
Experience for yourself how your app will look within the different systems, by accessing the OEM emulator system images downloadable in Android Studio. You can begin developing your charging, parking and navigation apps for Android Automotive OS today, and we are working to enable you to publish your apps to the Google Play store in the coming months (stay tuned!).
Beyond navigation, rideshare drivers spend a lot of time in their vehicles and will benefit from safer interactions if those apps can be brought to the car’s screen. We are working with Lyft and Kakao Mobility to bring their driver app experiences into the car in the coming months.
We are also pleased to announce that we are expanding support to all Points of Interest apps. Beyond charging and parking, this allows any app that will help users discover and search for interesting locations on a map, and optionally enable them to navigate to such points. We are partnering with MochiMochi, Fuelio, Pezzi Bezzina, and NAVITIME JAPAN as our early access partners.
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.
Posted by Anna Bernbaum, Associate Product Manager
Last year we announced the Wear Tiles API. To complement that Java API, we are excited to announce that support for Wear OS Tiles has been added to Glance, a new framework built on top of Jetpack Compose designed to make it easier to build for surfaces outside your app on Android. We'd love to get your feedback on this alpha version.
Tiles provide Wear OS users easy access to the information and actions they need in order to get things done quickly. They also are one of the most used surfaces on Wear OS. Just one swipe away from the Watch Face, users can quickly access the most important information or actions from an app, like start a timer or get the latest weather forecast.
Let's see how we can create a Tile with Glance:
class HelloTileService : GlanceTileService() {
@Composable
override fun Content() {
Text(text = "Hello Glance")
}
}
The simple code above generates the Tile below.
“Hello Glance” Tile sample with Glance
Note: Using Glance-wear-tiles requires`minSdkVersion`>= 26.
How it works
Glance creates “glanceable” experiences across Android surfaces using a base-set of Composables. For Tiles on Wear OS, Glance translates Composables into Tiles.
The Android Studio team has been abuzz with the stable release of Android Studio Bumblebee (2021.1.1) 🐝 and Android Gradle plugin (AGP) 7.1.0; the latest versions of Android official IDE and build system. We’ve improved functionality across a broad area of the typical developer workflow: Build and Deploy, Profiling and Inspection, and Design.
Some notable additions include a unified test execution between Android Studio and your continuous integration (CI) server ✅, convenient pairing flows to support ADB over Wi-Fi 📲, Improved Profiler tools to help you identify and analyze jank in your app 🕵️, and new ways to preview animations 🎥 and UI interactions without deploying your app to a device.
As always, this release wouldn’t be possible without the early feedback from our Preview users. So read on or watch below for further highlights and new features you can find in this stable version. If you’re ready to jump in and see for yourself, head over to the official website to download Android Studio Bumblebee (2021.1.1).
What’s in Android Studio Bumblebee (2021.1.1)
Below is a full list of new features in Android Studio Bumblebee (2021.1.1), organized by the three major themes.
Build and Deploy
New Device Manager: This new tool window in Bumblebee makes it easier to see and manage your virtual and physical test devices, and you can open it by selecting View > Tool Windows > Device Manager from the main menu bar. In the Virtual tab, create a new device, review device details, delete a device, or anything else you used to do from the now removed AVD Manager. In the Physical tab, quickly pair to a new device using ADB Wi-Fi and see details of each physical device at a glance, or quickly inspect each device’s file system using the Device File Explorer with a click of a button. Learn more about the New Device Manager in the release notes.
Device Manager
ADB over Wi-Fi: Bumblebee includes a simplified flow to connect to your Android 11 and higher devices over Wi-Fi for deployment and debugging using ADB. After you enable debugging over Wi-Fi on your device, select the Pair using Wi-Fi action in the Physical tab of the new Device Manager to open the pairing wizard. Then follow the steps provided to pair to a device connected over the same network. Learn more.
Pairing a device with ADB over Wifi
Run Instrumented Tests in Android Studio using Gradle: Have you ever run tests in Android Studio with different results than the same tests running on your CI? This can be a frustrating issue that leads to lost productivity. To resolve this issue, we’ve introduced a new test runner to Android Gradle plugin (AGP) 7.1.0 that Android Studio Bumblebee uses by default when running instrumentation tests, so all your tests run through a unified test runner. This is a similar improvement to Android Studio Arctic Fox, where we started running all unit tests via Gradle by default. And, similarly, this improvement doesn’t require you to change how you write or run your tests!
Using different runners lead to inconsistent results
Android Studio now runs instrumentation tests via Gradle
Android Gradle Plugin Upgrade Assistant now updates API usage: Originally introduced in Android Studio 4.2, the AGP Upgrade Assistant helped users update their projects to the latest version, and improvements in Arctic Fox provided a new UI with the ability to review and select the upgrade version and steps. In Bumblebee, the Upgrade Assistant now also checks for and offers to update your DSL to help you avoid using deprecated APIs before they are deleted. For more information see the Android Gradle Plugin DSL/API migration timeline.
Non-Transitive R classes on for new projects: Android Studio Arctic Fox introduced new refactoring tools to help you use non-transitive R classes to enable faster builds for applications with multiple modules. When creating new projects using Bumblebee, the IDE configures your project to use non-transitive R classes, by default. While this does bring performance improvements, you now have to refer to R classes by their proper package name, and not by the package names of their parent modules, as they will no longer resolve transitively. For more information see Use non-transitive R classes.
Emulator tool window enabled by default: Introduced in Android Studio 4.1, the Emulator launches within an Android Studio tool window and allows you to deploy and interact with virtual Android devices while fully remaining within the context of the IDE. The changes ads an improved UX for extended controls and snapshot management. For more information see Run the Android Emulator directly in Android Studio.
Apple Silicon Support Update - For those using macOS on Apple Silicon (arm64) hardware, Android Studio Arctic Fox and the Android Emulator have supported this new architecture since last year. However, with this release, we have now updated the Android SDK platform tools v32.0.0 (which includes ADB and fastboot) and build tools v32.1.0 (which includes aapt) to be universal binaries so that your Android developer tools no longer need the Rosetta binary translator to run. Based on community feedback, those developers on this hardware platform have seen notable performance improvements. See release notes.
Profile and Inspect
Jank detection track in Profilers: When profiling your app using devices running Android 11 (API level 30) or higher, the CPU profiler now shows a new group of tracks that illustrate the stages of each frame under Frame Lifecycle: Application, Wait for GPU, Composition and Frames on display. Each track labels the frames with a frame number and color-codes the rectangle to make it easy for you to visualize where a particular frame is in its lifecycle, along with guides you can toggle to compare with Vsync events. You can use this data to understand where Jank might occur in your app and investigate the root causes. In the Analysis panel, there is now a Frames tab, which conveniently summarizes rendering information for all frames. For more information, see UI jank detection.
Detailed frame lifecycle information in the CPU Profiler
Profileable app profiling support in Studio Profilers: When profiling your app, it’s important to generate accurate data with the version of your app that most closely resembles what your users will install. To do so, you can now include the <profileable> property in your app’s manifest to profile apps that are not debuggable, as shown below.
<profileable android:shell="true"/>
Profileable is a manifest configuration introduced in Android 10, and is available for CPU and Memory profiling tasks. Using the profileable flag instead of the debuggable flag has the key advantage of lower overhead for performance measurement; however, certain profiling features are not available for Profileable builds, such as the Event timeline, API initiated CPU profiling, heap dumps, or live location recordings. For more information, see Profileable applications.
Inspect Jobs, Alarms, and Wakelocks: The Background Task Inspector has been expanded to allow you to inspect Jobs, Alarms, and Wakelocks. You can see live information on how these background tasks are being scheduled, and see detailed information about their execution, similar to how you can inspect Workers. Additionally, when inspecting Workers, you can track and inspect Jobs that your Workers schedule for you. If you used to use the Energy Profiler in previous versions of the IDE, you should now navigate to View > Tool Windows > App Inspection from the menu bar and select the Background Task Inspector to inspect Jobs, Alarms, and Wakelocks.
Inspect Jobs, Alarms, and Wakelocks in the Background Task Inspector
Network Inspection: The Network Profiler has now migrated to the App Inspection tool window, to allow for a lighter-weight experience for inspecting network traffic in your app. The look and feel of the Network Profiler has been maintained and works with any debuggable app on devices running API level 26 and higher. To use the new inspector, select View > Tool Windows > App Inspection from the menu bar and select the Network Inspector. For more information, see Inspect network traffic with the Network Inspector.
Capture Layout Inspector snapshots: You can now capture snapshots of your app’s layout hierarchy to save, share, or inspect later. Snapshots capture the data you would typically see when using the Layout Inspector, including a detailed 3D rendering of your layout, the component tree of your View, Compose, or hybrid layout, and detailed attributes for each component of your UI. When inspecting the layout of a live running app, click Export snapshot from the Layout Inspector toolbar and save the snapshot with an *.li extension. You can then load a Layout Inspector snapshot by selecting File > Open from the main menu bar, and opening a *.li file. The snapshot appears in a tab in the Editor window, so that you can easily compare it with your running app. Learn more at Capture layout hierarchy snapshots.
Support for Compose semantics in the Layout Inspector: In Compose, Semantics describe your UI in an alternative manner that is understandable for Accessibility services and for the Testing framework. In Android Studio Bumblebee, you can now use the Layout Inspector to inspect semantic information in your Compose layouts. When selecting a Compose node, use the Attributes window to check whether it declares semantic information directly, merges semantics from its children, or both. To quickly identify which nodes include semantics, either declared or merged, use select the View options dropdown in the Component Tree window and select Highlight Semantics Layers.
Design
Interactive Preview: Android Studio Arctic Fox launched with support to statically preview your composable functions in the Design / Split window of the Editor. In Bumblebee, we’ve expanded functionality to allow you to interact with certain components of your Compose layouts, to validate behavior without building and deploying the full app to a running device! To get started, navigate to a previewable compose function and click Start Interactive Mode in the Design / Split window. For more information see Interactive mode.
Interact with the Compose Preview to validate behavior
Animated Vector Drawables Preview: The Preview window is now also available when viewing vector drawables. When viewing a static drawable, you can use the preview window to change background options between “None”, “White”, “Black”, “Checkedered”, to view your drawable against different conditions. Animated drawables also provide the option to preview the animation at different speeds as well as backgrounds, to help you test animations before using them in your app. To learn more, see Animated Vector Drawables (AVD) preview.
Preview your animated vector drawables
Updated Device picker for design tools: To simplify designing your app for the diverse number of Android devices, we’ve updated the device picker in various design tool windows, such as Layout Editor and Layout Validation, with reference devices that reflect popular sizes of each device form factor. From phones to tablets, and Wear devices to Android TVs, it’s now easier to preview, validate, or edit your layout on screen sizes that are most representative of popular real-world devices. To learn more, see Change the preview appearance.
To recap, Android Studio Bumblebee (2021.1.1) includes these new enhancements & features:
Build and Deploy
Run Instrumented Tests in Android Studio using Gradle
Android Gradle Plugin Upgrade Assistant now updates API usage
Non-Transitive R classes on for new projects
New Device Manager
ADB over Wi-Fi
Emulator tool window enabled by default
Apple Silicon Support Update
Profile and Inspect
Jank detection track in Profilers
Profileable app profiling support in Studio Profilers
Inspect Jobs, Alarms, and Wakelocks in the Background task Inspector
Capture Layout Inspector snapshots
Support for Compose semantics in the Layout Inspector
Posted by Arjun Dayal, Group Product Manager, Google Play Games
In December, we announced that Google Play Games will be coming to PCs. As part of our broader goal to make our products and services work better together, this product strives to meet players where they are and give them access to their games on as many devices as possible. We're excited to announce that we’ve opened sign-ups for Google Play Games as a beta in Korea, Taiwan, and Hong Kong.
Users participating in the beta can play a catalog of Google Play games on their Windows PC via a standalone application built by Google. We’re excited to announce that some of the most popular mobile games in the world will be available at launch, including Mobile Legends: Bang Bang, Summoners War, State of Survival: The Joker Collaboration, and Three Kingdoms Tactics, which delight hundreds of millions of players globally each month.
This product brings the best of Google Play to more laptops and desktops, enabling immersive and seamless gameplay sessions between a phone, tablet, Chromebook, and Windows PC. Players can easily browse, download, and play their favorite mobile games on their PCs, while taking advantage of larger screens with mouse and keyboard inputs. No more losing your progress or achievements when switching between devices, it just works with your Google Play Games profile! Play Points can also be earned for Google Play Games activity on PCs.
We’re thrilled to expand our platform for players to enjoy their favorite Android games even more. To sign up for future announcements, or to access the beta in Korea, Taiwan, and Hong Kong, please go to g.co/googleplaygames. If you’re an Android developer looking to learn more about Google Play Games, please express interest on our developer site. We’ll have more to share on future beta releases and regional availability soon.
Windows is a trademark of the Microsoft group of companies. Game titles may vary by region.
Posted by Dan Galpin, Developer Relations Engineer
In October of 2021 we released the final unit of Android Basics in Kotlin, our free, self-paced programming course that makes Android development accessible to everyone. It teaches people with no programming experience how to build Android apps. Along the way, students learn the fundamentals of programming and the basics of the Kotlin programming language.
In response to feedback from educators and learners, we've continued to iterate on our course material, adding projects that allow you to apply learnings along with new topics that can prepare students for more advanced material.
A focus on basics
With these updates, Android Basics in Kotlin now covers the key material covered in Android Kotlin Fundamentals, so we will be sunsetting the latter course. More advanced learners are encouraged to work through the Basics material, skipping sections that they are familiar with and moving straight to quizzes. Focusing on basics means that intermediate and advanced learners that might be missing a key concept will have what they need to succeed with this material. This also allows our team to focus on making sure our courseware continues to represent our most recent guidance. In addition to courseware, we're continuing to provide codelabs, code samples, documentation, and video content to serve learners at all levels.
What's next?
Our team is hard at work on the next course that will teach people how to program Android applications using Jetpack Compose. We're looking forward to teaching Android’s modern toolkit for building native UI because of all the ways that it simplifies and accelerates Android UI development.
What to do now
Taking the current course will teach you the fundamentals of app development, serving as a great starting point should you want to explore the existing Jetpack Compose Learning Pathway, or jump into the upcoming Android Basics with Compose course. You'll have a foundation that you can build on as you continue to explore the world of Android development. Both versions of Android Basics are planned to coexist, giving the option of learning Android with either UI toolkit.
Whether you’ve never built an app before but want to learn how, or just want to brush up on some of our latest best practices, check out the Android Basics in Kotlin course.
Posted by Alicja Heisig, Developer Relations Program Manager
Welcome to #IamaGDE - a series of spotlights presenting Google Developer Experts (GDEs) from across the globe. Discover their stories, passions, and highlights of their community work.
Gaston Saillen started coding for fun, making apps for his friends. About seven years ago, he began working full-time as an Android developer for startups. He built a bunch of apps—and then someone gave him an idea for an app that has had a broad social impact in his local community. Now, he is a senior Android developer at Distillery.
Meet Gaston Saillen, Google Developer Expert in Android and Firebase.
Building the Uh-LaLa! app
After seven years of building apps for startups, Gaston visited a local food delivery truck to pick up dinner, and the server asked him, “Why don’t you do a food delivery app for the town, since you are an Android developer? We don’t have any food delivery apps here, but in the big city, there are tons of them.”
The food truck proprietor added that he was new in town and needed a tool to boost his sales. Gaston was up for the challenge and created a straightforward delivery app for local Cordoba restaurants he named Uh-Lala! Restaurants configure the app themselves, and there’s no app fee. “My plan was to deliver this service to this community and start making some progress on the technology that they use for delivery,” says Gaston. “And after that, a lot of other food delivery services started using the app.”
The base app is built similarly to food delivery apps for bigger companies. Gaston built it for Cordoba restaurants first, after several months of development, and it’s still the only food delivery app in town. When he released the app, it immediately got traction, with people placing orders. His friends joined, and the app expanded. “I’ve made a lot of apps as an Android engineer, but this is the first time I’ve made one that had such an impact on my community.”
He had to figure out how to deliver real-time notifications that food was ready for delivery. “That was a little tough at first, but then I got to know more about all the backend functions and everything, and that opened up a lot of new features.”
He also had to educate two groups of users: Restaurant owners need to know how to input their data into the app, and customers had to change their habit of using their phones for calls instead of apps.
Gaston says seeing people using the app is rewarding because he feels like he’s helping his community.“All of a sudden, nearby towns started using Uh-LaLa!, and I didn't expect it to grow that big, and it helped those communities.”
During the COVID-19 pandemic, many restaurants struggled to maintain their sales numbers. A local pub owner ran a promotion through Instagram to use the Uh-Lala! App for ten percent off, and their sales returned to pre-COVID levels. “That is a success story. They were really happy about the app.”
Becoming a GDE
Gaston has been a GDE for seven years. When he was working on his last startup, he found himself regularly answering questions about Android development and Firebase on StackOverflow and creating developer content in the form of blog posts and YouTube videos. When he learned about the GDE program, it seemed like a perfect way to continue to contribute his Android development knowledge to an even broader developer community. Once he was selected, he continued writing blog posts and making videos—and now, they reach a broader audience.
“I created a course on Udemy that I keep updated, and I’m still writing the blog posts,” he says. “We also started the GDG here in Cordoba, and we try to have a new talk every month.”
Gaston enjoys the GDE community and sharing his ideas about Firebase and Android with other developers. He and several fellow Firebase developers started a WhatsApp group to chat about Firebase. “I enjoy being a Google Developer Expert because I can meet members of the community that do the same things that I do. It’s a really nice way to keep improving my skills and meet other people who also contribute and make videos and blogs about what I love: Android.”
The Android platform provides developers with state-of-the art tools to build apps for user. Firebase allows developers to accelerate and scale app development without managing infrastructure; release apps and monitor their performance and stability; and boost engagement with analytics, A/B testing, and messaging campaigns.
Future plans
Gaston looks forward to developing Uh-La-La further and building more apps, like a coworking space reservation app that would show users the hours and locations of nearby coworking spaces and allow them to reserve a space at a certain time. He is also busy as an Android developer with Distillery.
Gaston’s advice to future developers
“Keep moving forward. Any adversity that you will be having in your career will be part of your learning, so the more that you find problems and solve them, the more that you will learn and progress in your career.”
That’s a wrap! We’ve just finished a new MAD skills series on Gradle and Android Gradle plugin build APIs. In this series we shifted gears and took a look at how you can extend your build by using Gradle and brand new Android Gradle plugin APIs.
We covered how Gradle works, how you can configure the Android Gradle plugin, and learned which APIs to use to help customize your builds and keep your builds fast and efficient. If you missed this series or some of the episodes, here is a quick recap of what to expect.
Episode 1: Configure your build - Intro to Gradle and AGP
Gradle is a general purpose build tool which can build specific project types by using plugins. Plugins introduce a way to configure the build and decide which tasks are needed to build that project. Gradle configures and executes these tasks in different phases. Understanding how the build phases work and how to configure the Android Gradle plugin can help you customize your build according to your project’s needs and keep build times efficient.
You can check out the following video or if you prefer, read the article.
Episode 2: How to write a plugin
Extending your build by writing your own plugin gives you a way to customize your build even further! Starting with version 7.0, Android Gradle Plugin now offers stable extension points for manipulating variant configuration and the produced build artifacts. In this episode we started with writing a custom task and used the new Variant API to initialize and modify properties of Variants.
As we saw in previous episodes, keeping your config phase fast and resolving values lazily can help keep your builds efficient. Providers and Properties let you pass inputs and receive outputs from Gradle tasks lazily. In this episode we also take a look at the new Artifacts API to access and modify the app manifest.
Episode 4: Gradle and AGP Build APIs Community Tip
In the last episode in the series, we feature Alex Saveau, who maintains the Gradle Play Publisher and Version Orchestrator plugins. Alex shares a tip on using modern AGP and Gradle APIs to manipulate Android build artifacts.
To learn more, check out the following video.
Episode 6: Live Q&A
Finally, we wrapped up this series with a live Q&A session where we answered your questions. If you missed the Q&A, make sure to check out the following recording.
If you are interested to learn more, make sure to check out the resources and the Gradle recipes repo linked below! See you in the next MAD Skills series.
Posted by Marcel Pintó Biescas, Developer Relations Engineer, @marxallski
Android 12 revamps a key feature for many Android users, App Widgets, making them more useful, beautiful, and discoverable (84% use at least 1 widget). Today, we’re making it even easier to build them by releasing the first alpha of Jetpack Glance, a new framework built on top of the Jetpack Compose runtime designed to make it faster and easier to build app widgets for the home screen and other surfaces.
Glance offers similar modern, declarative Kotlin APIs that you are used to with Jetpack Compose, helping you build beautiful, responsive app widgets with way less code.
Glance “Hello World” widget sample
class GreetingsWidget(private val name: String): GlanceAppWidget() {
@Composable
override fun Content() {
Text(text = "Hello $name")
}
}
class GreetingsWidgetReceiver : GlanceAppWidgetReceiver() {
override val glanceAppWidget = GreetingsWidget("Glance")
}
How it works
Glance provides a base-set of Composables to help build “glanceable” experiences. Starting today with app widget components but with more coming. Using the Jetpack Compose runtime, Glance can translate Composables into actual RemoteViews, and display them in an app widget.
Diagram: Glance structure
This means that Glance requires Compose to be enabled and depends on Runtime, Graphics, and Unit UI Compose layers, but it’s not directly interoperable with other existing Jetpack Compose UI elements. However, state or any other logic within your app can be shared to create a glanceable UI.
What's in Alpha
This initial release introduces the main APIs to enable you to build app widgets in addition to providing interoperability with existing RemoteViews.
Here’s an overview of what the library offers, at a glance:
Posted by Purnima Kochikar, Vice President, Google Play Partnerships
Hello there,
Today we are kicking off Notes from Google Play, a new series where several times a year we celebrate your creativity and impact, and share key insights and best practices, to inspire you to be bolder, go further, and build even more innovative apps and games.
Purnima Kochikar addresses our goals behind the 'Notes from Google Play' series.
2021 continued to be a year of challenges and uncertainty, and you inspired us by your ability to turn obstacles into useful and joyful apps and services. Your apps helped over 2.5 billion people using Android devices learn, connect, relax, exercise, laugh, have fun, and so much more. As a result, developers making over 1M USD per month with Google Play’s billing or having 10 million monthly active users grew by 30% this year.
In this inaugural edition of Notes from Google Play we celebrate your creativity and resilience. A developer who exemplified these traits and deeply moved and inspired me and my team is Mohammed Kamara. Thank you, Mo for channeling deep personal loss to create a better world for women of color, providing affordable and customized healthcare through the app. We are humbled to play a small part in making your vision for InovCares a reality.
Mohamed Kamara, CEO and Founder of InovCares, tells the story behind his groundbreaking healthcare app.
A special shout out also goes to the winners of the Best of Google Play Awards and the Indie Games Festival. All of you inspire us to continue to work hard to evolve Play and Android to enable you to build great apps and successful businesses.
This focus on you and your success resulted in many impactful developments in 2021, including the evolution of our business model and new product features and tools. At Google Play we are focused on two key goals - helping you build and grow sustainable global businesses and investing in Android and Play platform features, tools, and ecosystems to enable you to build innovative apps and games.
Supporting your business growth
As the mobile industry has matured, you have created app businesses that have varying needs, so we’ve designed multiple programs to support you. For example, we created the Play Media Experience Program to encourage Video, Audio, and Books developers to build great cross-device experiences, while enabling apps that support authors & musicians by discounting the service fee as low as 10%. A few months ago we announced a new fee structure to support the evolution of the subscriptions business model, allowing all subscription app developers to benefit from lower fees. Due to the innovative changes we announced this year, I’m thrilled to share that 99% of developers globally now qualify for a service fee of 15% or less. Thank you for your thoughtful feedback while we were designing these programs and your vocal support since the launch of the new fee structure.
We have also continued to invest in programs to help you reach, retain, and re-engage your users.
Google Play Pass is now available in 90 countries with over 800 games and apps; those of you participating have on average more than doubled your revenue across participating titles in these regions.
Google Play Points is now available in 28 countries. By interacting with and paying for your apps, consumers have earned over 20 billion points to date.
Helping you build high quality apps
We are committed to empowering you to turn your creative ideas into excellent apps and have created tools and guidelines to help ensure your apps are of high quality. I invite you to pay attention to three key features/guidelines:
Trust and safety are the cornerstones of sustainable business success and key to user loyalty. This year, we continued to invest in platform features and policies that help you build safer apps and strengthen user trust. We also heard your feedback and have invested in educational tools and resources to help you anticipate and understand the new features and policies. The key highlights this year -
Earlier this year, we shared details about the upcoming Data safety section in the Play store, which will let users know the type of data your app collects, stores, and how that data is used. By giving you a way to showcase your approach to privacy-and-security, we’re not only building user trust, we’re helping people make informed decisions about the apps they install and use.
To help you protect your business from abuse and your users from attack we created the Play Integrity API, which lets your backend server determine whether it’s interacting with your genuine app binary, installed by Google Play, and running on a genuine Android device that’s powered by Google Play services.
To help you build safer and more trusted apps, we have created webinars and new Google Play Console features to help you anticipate and understand policy changes, policy violations, and the process to appeal a decision. Please opt-in to receive email invites to upcoming policy webinars.
Fostering the next generation of developers
Nothing excites me more than finding and nurturing the next generation of talented developers and building local ecosystems around the world that address local needs. Earlier this year we announced a reduced service fee tier of 15% on the first $1M in annual earnings for all developers, helping us continue to foster innovation on Android/Play.
It has been truly humbling to see key influencers, stakeholders, and industry and government leaders co-invest with us in this effort. Our most successful developers invested personal time and energy to mentor, coach, and grow Indies through the Indie Games Accelerator. Government leaders partnered with us to support startup ecosystems in countries like Korea and India - the ChangGoo program in Korea has been created in partnership with Ministry of SMEs and Startups (MSS) and the Korea Institute of Startup & Entrepreneurship Development (KISED), whereas the Appscale Academy in India was established in partnership with the MeitY Startup Hub, an initiative of the Ministry of Electronics and Information Technology (MeitY). Thank you all for your commitment to innovation and the app ecosystem.
Get a snapshot view of Appscale Academy: our growth and development program for startups across India.
Staying connected
I have missed seeing you in person over the last two years. The challenges imposed by COVID-19 helped us find new ways to stay connected. Many of you participated in virtual sessions to learn about new market opportunities and engaged in thoughtful online discussions on topics as diverse as Future of Work, Diversity, Equity, and Inclusion, and Growth and Global expansion strategies. Some of you also told us that you are feeling some online event fatigue, so this year we also invested in content that you can consume at your own pace including thought leadership and best practices, and e-learning courses on Play Academy. We even launched our first certificate to help you get the most out of our store listing tools and features.
Until the next edition, from my team to yours, best wishes for the upcoming year. We hope you will always see Google Play as a partner to help you delight your users, expand your audience, and grow your business.
Happy Holidays.
Purnima Kochikar,
Vice President, Google Play Partnerships
Make sure you don’t miss future editions by following me / us on Twitter or signing up to our monthly newsletter.
Posted by Manuel Vicente Vivo, Developer Relations Engineer,
@manuelvicnt
As Android apps grow in size, it's important to design the code with an architecture in place to allow the app to scale, improve quality and robustness, and make it easier to test.
An app architecture defines the boundaries between parts of the app and the responsibilities each part should have. This favors the separation of concerns principle that enables the aforementioned benefits.
In response to community demand for up-to-date guidance on app architecture, we're launching a revamped guide to app architecture. This includes best practices and recommended architecture for building robust, high-quality apps. It also provides a page for each layer of the recommended architecture: UI, domain, and data layers. Within them, you'll find deep dives into more complex topics, such as how to handle UI events.
Each Android app should have at least two layers:
The UI layer that displays application data on the screen.
The data layer that contains the business logic of your app and exposes application data.
You can add an additional layer called the domain layer to simplify and reuse the interactions between the UI and data layers.
General diagram of a typical app architecture. The UI layer gets the application data from the optional domain layer, or the data layer, that exposes application data.
We have created a learning pathway to help you consume this content in order and in a trackable way. Don't miss the chance to learn all of this and get a badge as recognition!
Is this for you?
If you’re a beginner, you should begin by understanding the benefits of having an app architecture and then follow these recommendations as a first approach to the topic. Intermediate and advanced developers can follow these recommendations and customize them to their needs. In fact, our research suggests that most professional developers are already using these best practices.
You might be wondering if you should update your existing architecture to follow this recommendation, and the answer is no… or wait… it's up to you. If your current architecture works for your team, you might want to stick with it. But you might also find patterns in our guides you can benefit from and incorporate into your app.
We’re not done yet
This is the first batch of documents we're releasing, with more to come in 2022. Help us make the guidance better! If you have any feedback on the current recommendations or if you want to see other architecture-related topics in them, let us know in our docs issue tracker.
Posted by Maru Ahues Bouza, Director, Android Developer Relations
Apps are essential to making Android a platform people love - whether it’s on their phones, cars, TVs, or watches. As a popular mobile platform, Android is thriving with 1 in 4 developers - worldwide - building for Android according to Stack Overflow’s 2020 developer survey.
In Android Developer Relations (or Android DevRel for short), our mission is to help developers be successful on Android by helping them build great apps with the latest Android and Play features, empower anyone to get a great career as an Android developer, and advocate for developers as Android and Play evolve. It’s truly rewarding because we get to see the future of apps - every day - and help our fellow developers achieve great things. With such a big mission, we’re hiring engineers, technical writers, and program managers - and if this gets you inspired, we’d love to talk! Check out the links at the end of this blog and apply to join our team.
But first, what does Android DevRel actually do? Our team works with external developers, writes code, creates content, launches careers, grows communities, runs conferences - and more. Read on to learn more!
Building better products with developers
We work with product and engineering teams in Android and Play to define go-to-market strategies for new developer products and run Early Access Programs (EAPs) with the goal of building better products for all developers. Through these EAPs, we do deep technical engineering work with the most influential developers to help them integrate and deliver feedback to validate that the products we’re building are ready to work at scale.
We work with these developers to build high quality apps across multiple screens, to ensure better user experiences on Android and we share their success stories to show how integrating with these products will help developers be more successful in the Android ecosystem, and to help inspire other developers to adopt.
Code
A big part of how we help developers is through code — be it tutorials, videos, blogs, or entire multi-unit educational courses. We produce everything from simple code snippets that explain how to perform a specific function, to sample apps like Jet* or the Google I/O app that demonstrates how everything comes together. In the process of creating sample code, you may be the first developer to ever build something with a new API! We call this being the “zeroth customer” and it’s an important role where you can directly influence the direction of a product through feedback (and yes, some trial and error!)
Content
In helping developers, we end up learning best practices and producing a ton of content - documentation, tutorials, screencasts, talks, blog posts, podcasts, and more. There is an art to breaking down complex subjects into a learning path - to help both beginner and advanced developers alike - and it is something we do every day. From introducing new concepts, to distilling best practices, to thoroughly documenting the functionality of a new API - our role is to help developers understand and thrive on Android. While our output is the content itself, it’s important to note that engineering is at the heart of this. In order to teach developers how to use these technologies, we first have to understand them deeply ourselves.
Teach millions of developers through learning materials
Community
Many of us were Android developers before we joined DevRel, and one of the most gratifying aspects of our role is meeting and connecting with developers around the world. We engage with Google Developer Experts for Android (GDEs), Google Developer Groups, and of course individual community members on a regular basis through events, social media, and Slack. We love to hear what people are working on, lend a hand where we can, and create connections across the community so people can learn from each other.
Conferences
One of the places the community comes together is at conferences - and Android has a lot of them! While you can pick up a skill or learn about the latest software design pattern, people always say the most valuable thing they get from conferences is connecting with fellow developers. Meeting people in person (side note: can’t wait until we can do that again!) is such an important part of building a network of people you can count on for help - whether you get stuck in your next project, or are looking for career advice. While many of these conferences are run by the community themselves, we participate in these events around the world and look forward to engaging with this community wherever they are. We also organize the Android Developer Summit and the Android track at Google I/O.
Careers
Apps connect you to the people in your life, help you do things more easily, or even help you learn new skills. In the past year many of us have had to find new ways of doing things, and this has seen us reach for apps more often than ever before, while growing the demand for app developers. In fact, developer jobs are growing 5.5x faster than other professions (U.S. Bureau of Labor Statistics). In Android DevRel, it is our privilege to build curriculum and work with universities and student groups around the world to skill-up the next generation of developers.
Want to join Android DevRel? Take a look at some of the roles below. Google often uses a single listing to make it easier for people to apply - so if it doesn’t say Android DevRel in the title of the role just tell them you’re interested in joining our team in your cover letter.
Android DevRel works with developers everywhere in the world, we want our team to represent all the developers we work with and we believe that diverse teams build better products that work for everyone. If you’re from an underrepresented group in tech, please apply even if you don’t think you match all the requirements and read what we’re doing to build a more diverse and inclusive Google.
Read on to see the roles that are available today:
Posted by Maru Ahues Bouza, Director, Android Developer Relations
At Android Dev Summit in October we highlighted the growth we’re seeing in large screen devices like tablets, foldables, and Chromebooks. We talked about how we’re making it easier to build great app experiences for these devices through new Jetpack APIs, tools, and guidance. We also introduced a developer preview of 12L, a feature drop for Android 12 that’s purpose-built for large screens.
With 12L, we’ve optimized and polished the system UI for large screens, made multitasking more powerful and intuitive, and improved compatibility support so apps look better right out of the box. 12L also includes a handful of new APIs for developers, such as for spatial audio and improved drag-and-drop for accessibility.
Today we’re releasing the first Beta of 12L for your testing and feedback as you get your apps ready for the feature drop coming early next year. You can try the new large screens features by setting up an Android emulator in Android Studio. 12L is for phones, too, and you can now enroll here to get 12L Beta 1 on supported Pixel devices. If you are still enrolled in the Android 12 Beta program, you’ll get the 12L update automatically. Through a partnership with Lenovo, you can also try 12L on the Lenovo Tab P12 Pro tablet, see the Lenovo site for details on available builds and support.
What’s in 12L Beta 1?
Today’s Beta 1 build includes improvements to functionality and user experience as well as the latest bug fixes, optimizations, and the December 2021 security patches. For developers, we’ve finalized the APIs early, so Beta 1 also includes the official 12L APIs (API level 32), updated build tools, and system images for testing. These give you everything you need to test your apps with the 12L features.
With 12L, we’ve focused on refining the UI on large screen devices, across notifications, quick settings, lockscreen, overview, home screen, and more. For example, on screens above 600dp, the notification shade, lockscreen, and other system surfaces use a new two-column layout to take advantage of the screen area.
Two-column layouts show more and are easier to use
Multitasking is also more powerful and intuitive - 12L includes a new taskbar on large screens that lets users instantly switch to favorite apps on the fly or drag-and-drop apps into split-screen mode. Remember, on Android 12 and later, users can launch any app into split screen mode, regardless whether the app is resizable. Make sure to test your apps in split screen mode!
Drag and drop apps into split-screen mode
Last, we’ve improved compatibility mode with visual and stability improvements to offer a better letterboxing experience for users and help apps look better by default. If your app is not yet optimized for large screens, make sure to test your app with the new letterboxing.
More APIs and tools to help you build for large screens
As you optimize your apps for large screens, here are some of our latest APIs and tools that can make it easier to build a great experience for users.
Material patterns for large screens - Our new Material Design guidance can help you plan how to scale your app’s UI across all screens.
Jetpack Compose for adaptive UI - Jetpack Compose makes it very easy to handle UI changes across different screen sizes or components. Check out the Build adaptive layouts in Compose guide for the basics of what you need to know.
Window Size Classes for managing your UI - Window Size Classes are opinionated viewport breakpoints to help you more easily design, develop and test resizable application layouts. Watch for these coming soon in Jetpack WindowManager 1.1.
Activity embedding - With Activity embedding APIs you can take advantage of the extra display area on large screens by showing multiple activities at once, such as for the List-Detail pattern, and it requires little or no refactoring of your app. Available in Jetpack WindowManager 1.0 Beta 03 and later.
Visual linting in Android Studio - In Android Studio Chipmunk, try the new visual linting tool that proactively surfaces UI warnings and suggestions in Layout Validation, to help identify potential issues on large screens.
Resizable emulator - This new emulator configuration comes with Android Studio Chipmunk and lets you quickly toggle between the four reference devices - phone, foldable, tablet, and desktop for easier testing.
With the 12L feature drop coming to devices early next year, now is a great time to optimize your apps for large screens. For developers, we highly recommend checking out how your apps work in split screen mode with windows of various sizes. If you haven’t optimized your app yet, see how it looks in different orientations and try the new compatibility mode changes if they apply.
The easiest way to get started with the large screen features is using the Android Emulator in a foldable or tablet configuration - see the complete setup instructions here.
Now you can also flash 12L onto a large screen device. Through a partnership with Lenovo, you can try 12L preview builds on the Lenovo Tab P12 Pro. Currently Lenovo is offering a Developer Preview 1 build, with updates coming in the weeks ahead. Visit Lenovo's 12L preview site for complete information on available builds and support.
12L is coming to phones, too, and although you won’t see the large screen features on smaller screens, we welcome you to try out the latest improvements in this feature drop. Just enroll your supported Pixel device here to get the latest 12L Beta update over-the-air. If you are still enrolled in the Android 12 Beta program, you’ll automatically receive the update 12L.
For details on 12L and the release timeline, visit the 12L developer site. You can report issues and requests here, and as always, we appreciate your feedback!
Posted by Alex Vanyo, Developer Relations Engineer
Watch faces are one of the most visible ways that people express themselves on their smartwatches, and they’re one of the best ways to display your brand to your users.
Watch Face Studio from Samsung is a great tool for creating watch faces without writing any code. For developers who want more fine-tuned control, we've recently launched the Jetpack Watch Face library written from the ground up in Kotlin.
The stable release of the Jetpack Watch Face library includes all functionality from the Wearable Support Library and many new features that make it easier to support customization on the smartwatch and on the system companion app on mobile, including:
Watch face styling which persists across both the watch and phone (with no need for your own database or companion app).
Support for a WYSIWYG watch face configuration UI on the phone.
Smaller, separate libraries (that only include what you need).
Battery improvements through encouraging good battery usage patterns out of the box, such as automatically reducing the interactive frame rate when battery is low.
New screenshot APIs so users can see previews of their watch face changes in real time on both the watch and phone.
If you are still using the Wearable Support Library, we strongly encourage migrating to the new Jetpack libraries to take advantage of the new APIs and upcoming features and bug fixes.
Below is an example of configuring a watch face from the phone with no code written on or for the phone.
Editing a watch face using the Galaxy Wearable mobile companion app
If you use the Jetpack Watch Face library to save your watch face configuration options, the values are synced with the mobile companion app. That is, all the cross-device communication is handled for you.
The mobile app will automatically present those options to the user in a simple, intuitive user interface where they change them to whatever works best for their style. It also includes previews that update in real time.
Let’s dive into the API with an overview of the most important components for creating a custom watch face!
A subclass of WatchFaceService forms the entry point of any Jetpack watch face. Implementing a WatchFaceService requires creating 3 objects: A UserStyleSchema, a ComplicationSlotsManager, and a WatchFace:
Diagram showing the 3 main parts of a WatchFaceService
These 3 objects are specified by overriding 3 abstract methods from WatchFaceService:
class CustomWatchFaceService : WatchFaceService() {
/**
* The specification of settings the watch face supports.
* This is similar to a database schema.
*/
override fun createUserStyleSchema(): UserStyleSchema = // ...
/**
* The complication slot configuration for the watchface.
*/
override fun createComplicationSlotsManager(
currentUserStyleRepository: CurrentUserStyleRepository
): ComplicationSlotsManager = // ...
/**
* The watch face itself, which includes the renderer for drawing.
*/
override suspend fun createWatchFace(
surfaceHolder: SurfaceHolder,
watchState: WatchState,
complicationSlotsManager: ComplicationSlotsManager,
currentUserStyleRepository: CurrentUserStyleRepository
): WatchFace = // ...
}
Let’s take a more detailed look at each one of these in turn, and some of the other classes that the library creates on your behalf.
The UserStyleSchema defines the primary information source for a Jetpack watch face. The UserStyleSchema should contain a list of all customization settings available to the user, as well as information about what those options do and what the default option is. These settings can be boolean flags, lists, ranges, and more.
By providing this schema, the library will automatically keep track of changes to settings by the user, either through the mobile companion app on a connected phone or via changes made on the smartwatch in a custom editor activity.
override fun createUserStyleSchema(): UserStyleSchema =
UserStyleSchema(
listOf(
// Allows user to change the color styles of the watch face
UserStyleSetting.ListUserStyleSetting(
UserStyleSetting.Id(COLOR_STYLE_SETTING),
// ...
),
// Allows user to toggle on/off the hour pips (dashes around the outer edge of the watch
UserStyleSetting.BooleanUserStyleSetting(
UserStyleSetting.Id(DRAW_HOUR_PIPS_STYLE_SETTING),
// ...
),
// Allows user to change the length of the minute hand
UserStyleSetting.DoubleRangeUserStyleSetting(
UserStyleSetting.Id(WATCH_HAND_LENGTH_STYLE_SETTING),
// ...
)
)
)
The current user style can be observed via the CurrentUserStyleRepository, which is created by the library based on the UserStyleSchema.
It gives you a UserStyle which is just a Map with keys based on the settings defined in the schema:
Map<UserStyleSetting, UserStyleSetting.Option>
As the user’s preferences change, a MutableStateFlow of UserStyle will emit the latest selected options for all of the settings defined in the UserStyleSchema.
currentUserStyleRepository.userStyle.collect { newUserStyle ->
// Update configuration based on user style
}
Complications allow a watch face to display additional information from other apps on the watch, such as events, health data, or the day.
The ComplicationSlotsManager defines how many complications a watch face supports, and where they are positioned on the screen. To support changing the location or number of complications, the ComplicationSlotsManager also uses the CurrentUserStyleRepository.
override fun createComplicationSlotsManager(
currentUserStyleRepository: CurrentUserStyleRepository
): ComplicationSlotsManager {
val defaultCanvasComplicationFactory =
CanvasComplicationFactory { watchState, listener ->
// ...
}
val leftComplicationSlot = ComplicationSlot.createRoundRectComplicationSlotBuilder(
id = 100,
canvasComplicationFactory = defaultCanvasComplicationFactory,
// ...
)
.setDefaultDataSourceType(ComplicationType.SHORT_TEXT)
.build()
val rightComplicationSlot = ComplicationSlot.createRoundRectComplicationSlotBuilder(
id = 101,
canvasComplicationFactory = defaultCanvasComplicationFactory,
// ...
)
.setDefaultDataSourceType(ComplicationType.SHORT_TEXT)
.build()
return ComplicationSlotsManager(
listOf(leftComplicationSlot, rightComplicationSlot),
currentUserStyleRepository
)
}
The prettiest part of a watch face! Every watch face will create a custom subclass of a renderer that implements everything needed to actually draw the watch face to a canvas.
The renderer is in charge of combining the UserStyle (the map from CurrentUserStyleRepository), the complication information from ComplicationSlotsManager, the current time, and other state information to render the watch face.
class CustomCanvasRenderer(
private val context: Context,
surfaceHolder: SurfaceHolder,
watchState: WatchState,
private val complicationSlotsManager: ComplicationSlotsManager,
currentUserStyleRepository: CurrentUserStyleRepository,
canvasType: Int
) : Renderer.CanvasRenderer(
surfaceHolder = surfaceHolder,
currentUserStyleRepository = currentUserStyleRepository,
watchState = watchState,
canvasType = canvasType,
interactiveDrawModeUpdateDelayMillis = 16L
) {
override fun render(canvas: Canvas, bounds: Rect, zonedDateTime: ZonedDateTime) {
// Draw into the canvas!
}
override fun renderHighlightLayer(canvas: Canvas, bounds: Rect, zonedDateTime: ZonedDateTime) {
// Draw into the canvas!
}
}
In addition to the system WYSIWYG editor on the phone, we strongly encourage supporting configuration on the smartwatch to allow the user to customize their watch face without requiring a companion device.
To support this, a watch face can provide a configuration Activity and allow the user to change settings using an EditorSession returned from EditorSession.createOnWatchEditorSession. As the user makes changes, calling EditorSession.renderWatchFaceToBitmap provides a live preview of the watch face in the editor Activity.
To see how the whole puzzle fits together to tell the time, check out the watchface sample on GitHub. To learn more about developing for Wear OS, check out the developer website.
Posted by Florina Muntenescu, Developer Relations Engineer
From updates to Jetpack libraries, more guidance on using Kotlin coroutines and Flow in your android app and new versions of Android Studio, here are the top 3 things you should know:
#1 Jetpack feature updates
We’ve been working to add the features you’ve been asking us for in a lot of Jetpack libraries, here are a few highlights:
Navigation brings multiple backstacks support—no code update needed, just make sure you use the latest version.
WorkManager, our recommended solution for persistent work, makes it easier to handle Android 12 background restrictions, adding support for expedited jobs
DataStore, our coroutines based replacement for SharedPreferences, has reached 1.0.
Macrobenchmark, a tool to measure and improve startup and frame performance, added simplified and more accurate frame timing, and compatibility back to Android M
But if you want to deep dive, you should really check out: WorkManager - back to the foreground - where you’ll learn all about the latest APIs and features.
#2 Kotlin and Flow usage
Coroutines are the recommended solution for asynchronous work and Kotlin Flow is the obvious choice for managing streams of data in Android apps. To learn how to use Flows in practice, check out this Android Dev Summit session:
The talk also covers important things like how to stop collecting from the UI when it’s not needed, using the newly stable lifecycle-aware coroutines APIs: repeatOnLifecycle and flowWithLifecycle.
#3 Android Studio and LiveEdit for Jetpack Compose
In the Android Studio world, Arctic Fox is stable, Bumblebee is in Beta and Chipmunk is in Canary, all of them bringing a bunch of new features for Jetpack Compose and Material You, developer productivity and 12L and large screens.
The What’s new in Android Studio talk is a must see, especially the sneak peek demo of LiveEdit. LiveEdit is a generalization of live editing of literals, where you get to edit more general scenarios than just constants and strings: you can comment out parts of the UI, reorder composable calls and see the result on the phone in milliseconds. But, we want to make sure that this feature is really right before we include it in Android Studio, so stay tuned for it in the next releases.
You want more? Then sit back, relax and watch the full Modern Android Development playlist.
This year’s Android Dev Summit brought a lot of updates related to Large Screen development for Android, the 12L feature drop on foldables and tablets - a set of features optimising Android 12 for large screens, better developer tools and updates to Google Play purpose-built for large screens. Here are the top 3 things you should know:
#1: The 12L feature drop for large screens
12L makes Android 12 even better on Large Screen devices, with a bunch of new refined UI across surfaces such as notifications and the lock screen. The most important announcements for developers included
A renewed emphasis on multitasking. This means all apps can now enter split screen mode, regardless of whether they are resizeable or not.
New improvements to compatibility mode
New Activity Embedding APIs that allow you to show multiple activities side by side, making it easier to build large screen optimized layouts in existing apps
To find out more about what’s new, check out the What’s new for large screens and foldables video and developer.android.com/12L .
#2: Making it easier to build for Large Screens
Android has supported Large Screens for a long time, but we announced several new tools to help you scale up your app’s UI to larger form factors.
Window Size Classes, a new framework of breakpoints designed to represent the most common form factors in the ecosystem you should design and develop for
Updates to SlidingPaneLayout, the View component for 2 pane layouts, to support Navigation
New Compose APIs that make developing adaptive and responsive UI very simple, including Navigation Rail support
Android Studio reference devices, a new set of device profiles that represent the widest range possible of devices in the ecosystem to test for
Visual Lint brought to Android Studio Layout Validation to detect issues with large screen layouts
A brand new Resizeable Emulator that can quickly toggle between the reference devices
Learn more about all these items in the Building Android UIs for Any Screen Size and Design beautiful apps on foldables and large screens talks, and check out the latest Large Screen guide and Build adaptive layouts in Compose guide for more. You can also check out Best practices for video apps on foldable devices and Spotify Across Screens for examples on how apps are making this journey.
#3: Google Play updates for Large Screens
To help users find the best apps on tablets, foldables and ChromeOS devices, we’ve got new changes in Play to recommend apps optimized for the large screen. This includes new checks to assess app quality, so we can feature large screen optimized apps and update search rankings to show the best possible apps for these devices. We will also be introducing large screen specific app ratings, so users will be able to rate how your app works on their large screen devices.
You can find all of this year’s Android Dev Summit talks related to Large Screens in this playlist, and the full list of announcements for Large Screens in our blog post.
Posted by the Google and Facebook teams. Authored by Kateryna Semenova from the Google Android team and Tim Trueman, Steven Harris, Subramanian Ramaswamy from the Facebook team.
Introduction
Improving app startup time is not a trivial task and requires a deep understanding of things that affect it. This year, the Google Android team and the Facebook app team have been working together on metrics and sharing approaches to improve app startup. Google Android’s public documentation has a lot of information on app startup optimization. In addition to that we want to share how it applies to the Facebook app and what helped them to improve app startup.
There are now more than 2.9 billion people using Facebook every month. Facebook helps give people the power to build community and bring the world closer together. It is a place for people to share life’s moments, discover and discuss what’s happening, connect and nurture relationships, and help work together to build economic opportunity.
Facebook app developers are committed to ensure that people have the best possible experience and that the app works seamlessly on every device, in any country, and within different network conditions. Working together, the Google Android team and Facebook team aligned on metrics definition for app startup and best practices and shared them in this article.
Where to start
Start by measuring your startup times. This will let you know how good your user’s startup experience is, track any regressions, as well as how much to invest on improving it. At the end of the day, your startup times need to be tied to user satisfaction or engagement or user-base growth in order to prioritize your investments.
Android defines two metrics to measure app startup times: Time-To-Full-Display (TTFD) and Time-To-Initial-Display (TTID). While you can further split it into cold/warm startup times, this post will not disambiguate between them - Facebook's approach is to measure and optimize the startup time that’s experienced across all users interacting with the app (some of them will be cold, some warm).
Time-To-Full-Display
TTFD captures the time when your app has completed rendering and is ready for user interaction and consumption, perhaps including content from disk or the network. This can take a while on slow networks and can depend on what surface your users land on. Thus, it may also be helpful to show something right away and let users see progress is still happening, which brings us to TTID…
Time-To-Initial-Display
TTID captures the time for your app to draw its background, navigation, any fast-loading local content, placeholders for slower local content or content coming from the network. TTID should be when users can navigate around and get to where they want to go.
Don’t change too much: One thing to watch out for is visually shifting your app’s content between TTID and TTFD, like showing cached content then snapping it away once network content comes in. This can be jarring and frustrating for users, so make sure your TTID draws enough meaningful content to show users as much as possible of what to expect for TTFD.
Focus on user success
Your users are coming to your app for content that might take a while to load, and you want to deliver that content to them as quickly as you can.
Facebook app developers focus on a metric based on Time To Full Display (TTFD), including all content and images, because that represents the full experience of what users came to the app for. If a network call for content or an image takes a long time or fails, developers want to know so that they can improve the entire start to finish startup experience.
What’s a good target for TTID and TTFD?
Facebook’s startup metric is the percentage of app starts that they consider “bad,” which is any start that either has a TTFD longer than 2.5 seconds OR any part of startup that is unsuccessful (e.g. an image fails to load or the app crashes). Facebook focuses on driving this percentage of bad starts down either by improving successful starts that take longer than 2.5 seconds, or by fixing issues causing unsuccessful starts. 2.5 seconds was chosen based on research that showed this was meaningful to Facebook users (this also matches the Largest Contentful Paint (LCP) metric in the Web Vitals recommendations for web sites).
Including the full experience, especially of any network calls to fetch recent content, can make your TTFD startup metrics seem really slow compared to TTID. This is actually a good thing! It represents the real experience people have with your app. Improvements you make to this may drive increased usage and perception of your app’s performance for your users like it has at Facebook.
Measuring TTFD can be tricky depending on your app. If it’s too hard, it’s fine to start with Time To Initial Display (TTID). That may miss the performance of loading some of your content if you have placeholders or images, but it’s good to start somewhere even if it’s just a subset of what your users see interacting with your app every day.
Instrumenting TTID
In Android 4.4 (API level 19) and higher, logcat provides a “Displayed” value capturing the time elapsed between launching the process and the completion of drawing the first frame of the corresponding activity on the screen.
The reported log line looks similar to the following example:
To instrument TTFD, call reportFullyDrawn() in your Activity after all your content is on screen. Be sure to include any content that replaces placeholders, as well as any images you render (be sure to count when the image itself is displayed, not just its placeholder). Once you instrument calling reportFullyDrawn(), you can see it in logcat:
Facebook app developers have been optimizing the app for billions of users across a multitude of devices, platforms and countries for many years. This section shares some of the key lessons that Facebook app developers applied to optimize their app startup.
Understand first, then optimize - Once you’ve defined a good startup metric, instrumenting it in your app can allow you to understand and prioritize improving your startup performance to deliver a better experience for your users. By starting with instrumentation, you can prove there is an opportunity, you can identify where to focus your efforts, and you can see how much you’ve improved things as you start optimizing.
Fix crashes first - After you’ve instrumented your starts, make sure your app starts reliably. Crashes during startup are the most frustrating and quickest way to get users to abandon your app; measure and address these first.
Don’t forget about functional reliability - Also, don’t forget about functional reliability: did your app show some content quickly, but fail to load all content or take a long time to load images? Your app may be starting fast, but failing to function as a customer wants (e.g., if tapping a button doesn’t work) - this worsens the customer experience.
Aim for consistency - Inconsistent performance is more frustrating than consistent but slower than average startup performance. Take a look at the long tail of your starts and see if there are any fixes or ways to mitigate these slow starts. Don’t forget to look at your offline and lossy network startup performance starts.
Parallelize work - Most modern phones have at least 4 CPU cores, so there's room to multitask! Don’t block the main thread unless you have to. Move I/O and non-critical paths work off the main thread.
Be lazy - Once you’ve got a reliable and consistent startup, take a look through everything you’re doing to display your first visible screen of content—is there any work in there that’s not necessary? Remove, delay, or move to the background any work that’s not directly related to a startup experience until after the app has started (but be careful to watch your app’s responsiveness as a counter-metric). Try to keep your app’s onCreate() as lightweight as possible.You can also benefit from using the Jetpack App Startup library to initialize components at application startup. When doing so, make sure to still load all the required modules for the starting activity, and don’t introduce flickers where the lazily-loaded modules become available.
Show progress, but don’t shift the UI too much - Try not to shift what’s presented to users around too much during startup. It’s frustrating to try to tap on something, only to have it change and do the wrong thing. This is similar to the Cumulative Layout Shift (CLS) concept from web vitals.For network-based loads with indeterminate durations, dismiss the splash screen and show placeholders for asynchronous loading. Consider applying subtle animations to the content area that reflect the loading state. Make sure that the loaded content structure matches the skeleton structure as closely as possible, to allow for a smooth transition once the content is loaded.
Cache it - When a user opens your app for the first time, you can show loading indicators for some UI elements. The next time a user comes to your app, you can show this cached content while you load more recent content. Ever seen your FB feed update after your app is loaded as we fetch updated content from the network? Cutting network time out of your startup, if you can, is a great way to speed things up and introduce a more consistent startup performance experience. However, showing cached content may not always be the best approach as the next point suggests, and this is why it is important to measure what works better for the customer.
Go fast & slow - Slightly slower, fresh & relevant content may be better than fast stale content. Showing fresh content to your users may be more valuable than starting up super fast only to refresh the content soon after startup. Evaluate whether it’s better to optimize for showing fresh content as quickly as possible with a timeout for showing stale content if the network is slow, or to just show what’s available immediately if the network is offline.
Consistent session start surface - You may find it helpful to reset users to your main content after your app is in the background for a long time. Devices can keep your app in memory for a long time.
Look at the inner workings - Trace and actually look at what’s executing during startup or attach a debugger—you might be surprised what you find! Once you’ve got a good understanding of the critical path for your starts, you can efficiently optimize your app’s performance. Invest in your biggest opportunities because you’ll know where they are.
Make it easy to do the right thing - Sometimes developers use bad patterns and architecture because there are too many ways to do things. Don’t be afraid to consolidate the patterns used in your app, and optimize them so it’s easy to pick how to complete a task and for that task to be performant. A good example of this would be eager code execution patterns. If you’re running code for content that appears after the first full screen draw, you’re by definition hurting performance. Lazy code execution is a good pattern. Only run code eagerly when it is blocking the critical path for your startup.
Recommendations From Google Android Team
Google Android team’s recommendations to measure and optimize app startup are available in the public docs: App startup time. This section summarizes some of the key points that ties into Facebook’s recommendations above that all Android app developers should consider.
TTID and TTFD are important metrics for app startup. Google Android ranks apps with TTID in the Play Console. TTFD is a super-set of TTID, so any improvements in TTID should apply to both metrics.
Call reportFullyDrawn() to report TTFD and to let the system know that your activity is finished rendering. To improve app startup, the Android system adjusts optimizations to prioritize work that happens before reportFullyDrawn() is called. Calling this method when your app is in fully usable state will improve your app startup time. Every application should be using this API! And don’t forget to measure it.
Monitoring your app's technical performance with Android vitals will help you improve your app startup. Using the Play Console, you can view data to help you understand and improve your app's startup time and more.
We know a bug in production is much more expensive to fix compared to a fix at development time. The same applies to performance as well. Setup your application for measuring app startup early with local performance tests by using Jetpack Macrobenchmark: Startup.
Instrumenting is key to understanding and optimizing startup as we’ve discussed above. Android offers system tracing that can help to dig deep and diagnose app startup problems.
The Jetpack App startup library provides a straightforward, performant way to initialize components at application startup. Both library developers and app developers can use this library to streamline startup sequences and explicitly set the order of initialization. You can use this library to set which components load at what points during startup.
A typical issue that affects app startup is doing too much during initialization - for example, inflating large or complex layouts, blocking screen drawing, loading and decoding bitmaps, garbage collection, etc.
Recap
This article captures some key measures of startup and best practices to improve startup experience that helps drive user engagement and adoption for the Facebook Android app. It also shares metrics, libraries and tools recommended by the Google Android team. Any Android app stands to benefit from applying some of the strategies described in the document. Measure and make your app startup delightful and fast for your users!
New Releases: Jetpack Compose 1.1 beta and compose-material3
We released Jetpack Compose 1.1 beta. This means that new APIs in 1.1 are now stable, offering new functionality and performance improvements. 1.1 includes new features like improved focus handling & touch target sizing or `ImageVector` caching and support for Android 12 stretch overscroll. Compose 1.1 also graduates a number of previously experimental APIs to stable and supports newer versions of Kotlin. We've already updated our samples, codelabs and Accompanist library to work with Compose 1.1.
We released compose-material3. This is a brand new artifact for building Material You UIs with Jetpack Compose. It offers updated components and color system, including support for dynamic color, creating a personalized color palette from a user's wallpaper. This is our first alpha so we welcome your feedback as we continue to add features and iterate on the APIs. Check out the new m3.material.io website to learn more about Material Design 3 and find tools to help you design & build with dynamic color, like the Material Theme Builder.
More Guidance & Documentation for Jetpack Compose
We released a ton of talks about Jetpack Compose, providing deep dives into layout, animation and state, showed how to use Compose across Wear OS, homescreen widgets and Large Screens and held 3 code-alongs; live coding your first Compose app, migrating an existing app or using compose on Wear OS. Finally we held a panel discussion, answering your burning questions about Jetpack Compose and Material.
Android Studio Chipmunk canaries also introduced a new template for Compose (and View based) Material 3 applications.
Handoff
Lastly, we gave a sneak peak of some new tooling for design handoff, enabling you to export components designed in Figma to generate idiomatic Jetpack Compose code. You can iterate on the designs and pull in new changes, and safely edit the generated code. We're looking for a small group of teams to work directly with, so go sign up.
Jetpack Compose is stable and ready for production. We’ve been thrilled to see tens of thousands of apps start using Jetpack Compose in production and we continue to build our roadmap of features to enable you to use Compose to create excellent apps, across devices.
.png)
.jpg)
.png)
.png)
.jpg)
.png)
.png.jpeg)
.png)
.png.jpeg)
.jpg)
.png)
.png)
.png)
.png)
.gif){kind=link}
.png){kind=link}
.png){kind=link}
.png){kind=link}
.gif){kind=link}
