Learn more about the upcoming Video Action Campaign upgrades to Demand Gen and how you can drive better performance with more powerful features.
Although a product's requirements can change often, its fundamental ideas usually change slowly. This leads to an interesting insight: if we write code that matches the fundamental ideas of the product, it will be more likely to survive future product changes.
Domain objects are building blocks (such as classes and interfaces) in our code that match the fundamental ideas of the product. Instead of writing code to match the desired behavior for the product's requirements ("configure text to be white"), we match the underlying idea ("text color settings").
For example, imagine you’re part of the gPizza team, which sells tasty, fresh pizzas to feed hungry Googlers. Due to popular demand, your team has decided to add a delivery service.
Without domain objects, the quickest path to pizza delivery is to simply create a deliverPizza method:
Although this works well at first, what happens if gPizza expands its offerings to other foods?
You could add a new method:
But as your list of requirements grows (snacks, sweets, etc.), you’ll be stuck adding more and more methods. How can you change your initial implementation to avoid this continued maintenance burden?
You could add a domain object that models the product's ideas, instead of its requirements:
A use case is a specific behavior that helps the product satisfy its business requirements.
(In this case, "Deliver pizzas so we make more money".)
A domain object represents a common idea that is shared by several similar use cases.
To identify the appropriate domain object, ask yourself:
What related use cases does the product support, and what do we plan to support in future?
A: gPizza wants to deliver pizzas now, and eventually other products such as drinks and snacks.
What common idea do these use cases share?
A: gPizza wants to send the customer the food they ordered.
What is a domain object we can use to represent this common idea?
A: The domain object is a food order. We can encapsulate the use cases in a FoodOrder class.
Domain objects can be a useful generalization - but avoid choosing objects that are too generic, since there is a tradeoff between improved maintainability and more complex, ambiguous code. Generally, aim to support only planned use cases - not all possible use cases (see YAGNI principles).
Learn more about domain objects and the more advanced topic of domain-driven design in the book Domain-Driven Design by Eric Evans.
Our new Heat Resilience tool uses AI to help cities prioritize where to implement cooling strategies.
Hello All,
The Stable channel has been released for 128.0.6613.118 (Platform version: 15964.41.0) for most ChromeOS devices.
If you find new issues, please let us know one of the following ways:
Google ChromeOS.
TalkBack is Android’s screen reader in the Android Accessibility Suite that describes text and images for Android users who have blindness or low vision. The TalkBack team is always working to make Android more accessible. Today, thanks to Gemini Nano with multimodality, TalkBack automatically provides users with blindness or low vision more vivid and detailed image descriptions to better understand the images on their screen.
Advancing accessibility is a core part of Google’s mission to build for everyone. That’s why TalkBack has a feature to describe images when developers didn’t include descriptive alt text. This feature was powered by a small ML model called Garcon. However, Garcon produced short, generic responses and couldn’t specify relevant details like landmarks or products.
The development of Gemini Nano with multimodality was the perfect opportunity to use the latest AI technology to increase accessibility with TalkBack. Now, when TalkBack users opt in on eligible devices, the screen reader uses Gemini Nano’s new multimodal capabilities to automatically provide users with clear, detailed image descriptions in apps including Google Photos and Chrome, even if the device is offline or has an unstable network connection.
“Gemini Nano helps fill in missing information,” said Lisie Lillianfeld, product manager at Google. “Whether it’s more details about what’s in a photo a friend sent or the style and cut of clothing when shopping online.”
Here’s an example that illustrates how Gemini Nano improves image descriptions: When Garcon is presented with a panorama of the Sydney, Australia shoreline at night, it might read: “Full moon over the ocean.” Gemini Nano with multimodality can paint a richer picture, with a description like: “A panoramic view of Sydney Opera House and the Sydney Harbour Bridge from the north shore of Sydney, New South Wales, Australia.”
“It's amazing how Nano can recognize something specific. For instance, the model will recognize not just a tower, but the Eiffel Tower,” said Lisie. “This kind of context takes advantage of the unique strengths of LLMs to deliver a helpful experience for our users.”
Using an on-device model like Gemini Nano was the only feasible solution for TalkBack to provide automatically generated detailed image descriptions for images, even while the device is offline.
“The average TalkBack user comes across 90 unlabeled images per day, and those images weren't as accessible before this new feature,” said Lisie. The feature has gained positive user feedback, with early testers writing that the new image descriptions are a “game changer” and that it’s “wonderful” to have detailed image descriptions built into TalkBack.
One important decision the Android accessibility team made when implementing Gemini Nano with multimodality was between inference verbosity and speed, which is partially determined by image resolution. Gemini Nano with multimodality currently accepts images in either 512 pixels or 768 pixels.
“The 512-pixel resolution emitted its first token almost two seconds faster than 768 pixels, but the output wasn't as detailed,” said Tyler Freeman, a senior software engineer at Google. “For our users, we decided a longer, richer description was worth the increased latency. We were able to hide the perceived latency a bit by streaming the tokens directly to the text-to-speech system, so users don’t have to wait for the full text to be generated before hearing a response.”
TalkBack developers also implemented a hybrid AI solution using Gemini 1.5 Flash. With this server-based AI model, TalkBack can provide the best of on-device and server-based generative AI features to make the screen reader even more powerful.
When users want more details after hearing an automatically generated image description from Gemini Nano, TalkBack gives the user an option to listen to more by running the image through Gemini Flash. When users focus on an image, they can use a three-finger tap to open the TalkBack menu and select the “Describe Image” option to send the image to Gemini 1.5 Flash on the server and get even more details.
By combining the unique advantages of both Gemini Nano's on-device processing with the full power of cloud-based Gemini 1.5 Flash, TalkBack provides blind and low-vision Android users a helpful and informative experience with images. The “describe image” feature powered by Gemini 1.5 Flash launched to TalkBack users on more Android devices, so even more users can get detailed image descriptions.
The Android accessibility team recommends developers looking to use the Gemini Nano with multimodality prototype and test on a powerful, server-side model first. There developers can understand the UX faster, iterate on prompt engineering, and get a better idea of the highest quality possible using the most capable model available.
While Gemini Nano with multimodality can include missing context to improve image descriptions, it’s still best practice for developers to provide detailed alt text for all images on their apps or websites. If the alt text is not provided, TalkBack can help fill in the gaps.
The Android accessibility team’s goal is to create inclusive and accessible features, and leveraging Gemini Nano with multimodality to provide vivid and detailed image descriptions automatically is a big step towards that. Furthermore, their hybrid approach towards AI, combining the strengths of both Gemini Nano on device and Gemini 1.5 Flash in the server, showcases the transformative potential of AI in promoting inclusivity and accessibility and highlights Google's ongoing commitment to building for everyone.
Learn more about Gemini Nano for app development.
This blog post is part of our series: Spotlight Week on Android 15, where we provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features in Android 15. You can read more in the overview of Spotlight Week: Android 15, which will be updated throughout the week.
By now, you’ve probably heard the news: Android 15 was just released earlier today to AOSP. To celebrate, we’re kicking off a new series called “Spotlight Week” where we’ll shine a light on technical areas across Android development and equip you with the tools you need to take advantage of each area.
The Android 15 "Spotlight Week" will provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features. These changes strive to improve the Android ecosystem, but updating the OS comes with potential app compatibility implications and integrations that require detailed guidance.
That’s just a taste of what we’re covering in our Spotlight Week on Android 15. Keep checking back to this blog post for updates, where we’ll be adding links and more throughout the week. Plus, follow Android Developers on X and Android by Google at Linkedin throughout the week to hear even more about Android 15.
By now, you’ve probably heard the news: Android 15 was just released earlier today to AOSP. To celebrate, we’re kicking off a new series called “Spotlight Week” where we’ll shine a light on technical areas across Android development and equip you with the tools you need to take advantage of each area.
The Android 15 "Spotlight Week" will provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features. These changes strive to improve the Android ecosystem, but updating the OS comes with potential app compatibility implications and integrations that require detailed guidance.
That’s just a taste of what we’re covering in our Spotlight Week on Android 15. Keep checking back to this blog post for updates, where we’ll be adding links and more throughout the week. Plus, follow Android Developers on X and Android by Google at Linkedin throughout the week to hear even more about Android 15.
In Android 14 we introduced user-initiated data transfer jobs, or UIDT. You can use the new API setUserInitiated in JobScheduler to specify that the job is a user-initiated data transfer job. This API is helpful for use cases that require long-duration (>10 minutes), user-initiated transfer of data over network. UIDT is also an alternative API to using a dataSync foreground service, which has new timeout behavior for apps that target Android 15.
UIDT is intended to support user initiated use cases such as downloading files from a remote server, uploading files to a remote server or transferring data between two devices via Wi-Fi transport. Since the release of Android 14, the new API has been adopted by a growing number of Android apps running on hundreds of millions of user devices.
The Android team’s extensive analysis found gaps in foreground services and WorkManager for long duration, user initiated data transfers. Although WorkManager could support retries and constraints, it could not support long duration work which are often necessary for data transfer operations. Developers also found it challenging to use foreground service, which did not provide an ideal user experience during interruption of network connectivity.
JobScheduler’s user initiated data transfer API helps solve for these gaps by offering developers the following benefits:
If you’re looking to do short or interruptible background work, WorkManager is still the recommended solution. Check out data transfer background task options to learn more.
Google Maps decided to use UIDT for their offline maps download use case. This use case ensures that users are able to download offline maps so they have map data even when they lose network connectivity.
Google Maps decided to adopt UIDT to ensure that the download service works with the latest Android releases and continues to be reliable and efficient.
“We implemented several features and optimizations, such as resumable downloads so that if a user's internet connection is interrupted or they exit the app before the download is complete, the download resumes from where it left off when the user returns to the app or their connection is restored.” - Emma Li, Software Engineer at Google
The UIDT is triggered when a user decides to download a map region to have that data offline. When a user hits download, the UIDT is triggered immediately and processing of the region begins as soon as possible.
Google Maps rolled out the project using experiment flags to understand metrics impact after each ramp stage.
“We successfully launched UIDT on Android 14 in early 2024 migrating from our foreground service implementation. After a retroactive analysis on Android 14 vs Android 13 implementation, we now see a 10%+ improvement in download failure rate of offline downloads!” - Matthew Valgenti, Software Engineer at Google
In order to adopt user initiated data transfer, you will need to integrate with the JobScheduler platform API and gate the change to Android 14 or higher.
Check out the following developer documentation to get started with user initiated data transfer:
This blog post is part of our series: Spotlight Week on Android 15, where we provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features in Android 15. You can read more in the overview of Spotlight Week: Android 15, which will be updated throughout the week.
In Android 14 we introduced user-initiated data transfer jobs, or UIDT. You can use the new API setUserInitiated in JobScheduler to specify that the job is a user-initiated data transfer job. This API is helpful for use cases that require long-duration (>10 minutes), user-initiated transfer of data over network. UIDT is also an alternative API to using a dataSync foreground service, which has new timeout behavior for apps that target Android 15.
UIDT is intended to support user initiated use cases such as downloading files from a remote server, uploading files to a remote server or transferring data between two devices via Wi-Fi transport. Since the release of Android 14, the new API has been adopted by a growing number of Android apps running on hundreds of millions of user devices.
The Android team’s extensive analysis found gaps in foreground services and WorkManager for long duration, user initiated data transfers. Although WorkManager could support retries and constraints, it could not support long duration work which are often necessary for data transfer operations. Developers also found it challenging to use foreground service, which did not provide an ideal user experience during interruption of network connectivity.
JobScheduler’s user initiated data transfer API helps solve for these gaps by offering developers the following benefits:
If you’re looking to do short or interruptible background work, WorkManager is still the recommended solution. Check out data transfer background task options to learn more.
Google Maps decided to use UIDT for their offline maps download use case. This use case ensures that users are able to download offline maps so they have map data even when they lose network connectivity.
Google Maps decided to adopt UIDT to ensure that the download service works with the latest Android releases and continues to be reliable and efficient.
“We implemented several features and optimizations, such as resumable downloads so that if a user's internet connection is interrupted or they exit the app before the download is complete, the download resumes from where it left off when the user returns to the app or their connection is restored.” - Emma Li, Software Engineer at Google
The UIDT is triggered when a user decides to download a map region to have that data offline. When a user hits download, the UIDT is triggered immediately and processing of the region begins as soon as possible.
Google Maps rolled out the project using experiment flags to understand metrics impact after each ramp stage.
“We successfully launched UIDT on Android 14 in early 2024 migrating from our foreground service implementation. After a retroactive analysis on Android 14 vs Android 13 implementation, we now see a 10%+ improvement in download failure rate of offline downloads!” - Matthew Valgenti, Software Engineer at Google
In order to adopt user initiated data transfer, you will need to integrate with the JobScheduler platform API and gate the change to Android 14 or higher.
Check out the following developer documentation to get started with user initiated data transfer:
This blog post is part of our series: Spotlight Week on Android 15, where we provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features in Android 15. You can read more in the overview of Spotlight Week: Android 15, which will be updated throughout the week.
Today we're releasing Android 15 and making the source code available at the Android Open Source Project (AOSP). Android 15 will be available on supported Pixel devices in the coming weeks, as well as on select devices from Samsung, Honor, iQOO, Lenovo, Motorola, Nothing, OnePlus, Oppo, realme, Sharp, Sony, Tecno, vivo, and Xiaomi in the coming months.
We're proud to continue our work in open source through the AOSP. Open source allows anyone to build upon and contribute to Android, resulting in devices that are more diverse and innovative. You can leverage your app development skills in Android Studio with Jetpack Compose to create applications that thrive across the entire ecosystem. You can even examine the source code for a deeper understanding of how Android works.
Android 15 continues our mission of building a private and secure platform that helps improve your productivity while giving you new capabilities to produce beautiful apps, superior media and camera experiences, and an intuitive user experience, particularly on tablets and foldables.
Starting today, we're kicking off a new educational series called Spotlight Weeks, where we dive into technical topics across Android, beginning with a week of content on Android 15. Check out what we'll be covering throughout the week, as well as today's deep dive into edge-to-edge.
While most of our work to improve your productivity centers around tools like Android Studio, Jetpack Compose, and the Android Jetpack libraries, each new Android platform release includes quality-of-life updates to improve the development experience. For example, Android 15 gives you new insights and telemetry to allow you to further tune your app experience, so you can make changes that improve the way your app runs on any platform release.
Android helps you make beautiful apps that work well across the global diversity of the Android ecosystem.
Each Android release helps you bring superior media and camera experiences to your users.
We continue to refine the Android user experience with every release, while working to improve performance and battery life. Here is just some of what Android 15 brings to make the experience more intuitive, performant, and accessible.
Privacy and security are at the core of everything we do, and we work to make meaningful improvements to protect your apps and our users with each platform release.
If you develop an SDK, library, tool, or game engine, it's particularly important to prepare any necessary updates immediately to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your developers know if updates are needed to fully support Android 15.
Testing your app involves installing your production app using Google Play or other means onto a device or emulator running Android 15. Work through all your app's flows and look for functional or UI issues. Review the behavior changes to focus your testing. Here are several changes to consider that apply even if you don't yet target Android 15:
Please thoroughly exercise libraries and SDKs that your app is using during your compatibility testing. You may need to update to current SDK versions or reach out to the developer for help if you encounter any issues.
Once you’ve published the Android 15-compatible version of your app, you can start the process to update your app's targetSdkVersion.
We’re working to make updates faster and smoother with each platform release by prioritizing app compatibility. In Android 15 we’ve made most app-facing changes opt-in until your app targets SDK version 35. This gives you more time to make any necessary app changes.
To make it easier for you to test the opt-in changes that can affect your app, based on your feedback we’ve made 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 how to do this, here.
To help you migrate your app to target Android 15, the Android SDK Upgrade Assistant within the latest Android Studio Koala Feature Drop release now covers android 15 API changes and walks you through the steps to upgrade your targetSdkVersion.
If you have a supported Pixel device, you will receive the public Android 15 over the air update when it becomes available. If you don't want to wait, you can get the most recent quarterly platform release (QPR) beta by joining the Android 15 QPR beta program at any time.
If you're already in the QPR beta program on a Pixel device that supports the next Android release, you'll likely have been offered the opportunity to install the first Android 15 QPR beta update. If you want to opt-out of the beta program without wiping your device, don't install the beta and instead wait for an update to the release version when it is made available on your Pixel device. Once you've applied the stable release update, you can opt out without a data wipe as long as you don't apply the next beta update.
Stay tuned for the next five days of our Spotlight Week on Android 15, where we'll be covering topics like edge-to-edge, passkeys, updates to foreground services, picture-in-picture, and more. Follow along on our blog, X, LinkedIn or YouTube channels. Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 15.
For complete information, visit the Android 15 developer site.
Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Posted by Aaron Labiaga- Android Developer Relations Engineer