Category Archives: Android Developers Blog

An Open Handset Alliance Project

The Recorder app on Pixel sees a 24% boost in engagement with Gemini Nano-powered feature

Posted by Terence Zhang – Developer Relations Engineer and Kristi Bradford - Product Manager

Google Pixel’s Recorder app allows people to record, transcribe, save, and share audio. To make it easier for users to manage and revisit their recordings, Recorder’s developers turned to Gemini Nano, a powerful on-device large language model (LLM). This integration introduces an AI-powered audio summarization feature to help users more easily find the right recordings and quickly grasp key points.

Earlier this month, Gemini Nano got a power boost with the introduction of the new Gemini Nano with Multimodality model. The Recorder app is already leveraging this upgrade to summarize longer voice recordings, with improved processing for grammar and nuance.

Meeting user needs with on-device AI

Recorder developers initially experimented with a cloud-based solution, achieving impressive levels of performance and quality. However, to prioritize accessibility and privacy for their users, they sought an on-device solution. The development of Gemini Nano presented a perfect opportunity to build the concise audio summaries users were looking for, all while keeping data processing on the device.

Gemini Nano is Google’s most efficient model for on-device tasks. “Having the LLM on-device is beneficial to users because it provides them with more privacy, less latency, and it works wherever they need since there’s no internet required,” said Kristi Bradford, the product manager for Pixel’s essential apps.

To achieve better results, Recorder also fine-tuned the model using data that matches its use case. This is done using low order rank adaptation (LoRA), which enables Gemini Nano to consistently output three-bullet point descriptions of the transcript that include any speaker names, key takeaways, and themes.

AICore, an Android system service that centralizes runtime, delivery, and critical safety components for LLMs, significantly streamlined Recorder's adoption of Gemini Nano. The availability of a developer SDK for running GenAI workloads allowed the team to build the transcription summary feature in just four months, with only four developers. This efficiency was achieved by eliminating the need for maintaining in-house models.

Since its release, Recorder users have been using the new AI-powered summarization feature averaging 2 to 5 times daily, and the number of overall saved recordings increased by 24%. This feature has contributed to a significant increase in app engagement and user retention overall. The Recorder team also noted that feedback about the new feature has been positive, with many users citing the time the new AI-powered summarization feature saves them.

“We were surprised by how truly capable the model was… before and after LoRA tuning.” — Kristi Bradford, product manager for Pixel’s essential apps

The next big evolution: Gemini Nano with multimodality

Recorder developers also implemented the latest Gemini Nano model, known as Gemini Nano with multimodality, to further improve its summarization feature on Pixel 9 devices. The new model is significantly larger than the previous one on Pixel 8 devices, and it’s more capable, accurate, and scalable. The new model also has expanded token support that lets Recorder summarize much longer transcripts than before. Gemini Nano with multimodality is currently only available on Pixel 9 devices.

Integrating Gemini Nano with multimodality required another round of fine-tuning. However, Recorder developers were able to use the original Gemini Nano model's fine-tuning dataset as a foundation, streamlining the development process.

To fully leverage the new model's capabilities, Recorder developers expanded their dataset with support for longer voice recordings, implemented refined evaluation methods, and established launch criteria metrics focused on grammar and nuance. The inclusion of grammar as a new metric for assessing inference quality was made possible solely by the enhanced capabilities of Gemini Nano with Multimodality.

UI example

Doing more with on-device AI

“Given the novelty of GenAI, the whole team had fun learning how to use it,” said Kristi. “Now, we’re empowered to push the boundaries of what we can accomplish while meeting emerging user needs and opportunities. It’s truly brought a new level of creativity to problem-solving and experimentation. We’ve already demoed at least two more GenAI features that help people get time back internally for early feedback, and we’re excited about the possibilities ahead.”

Get started

Learn more about how to bring the benefits of on-device AI with Gemini Nano to your apps.

#TheAndroidShow: diving into the latest from Made by Google, including wearables, Foldable, Gemini and more!

Posted by Anirudh Dewani, Director – Android Developer Relations

We just dropped our summer episode of #TheAndroidShow, on YouTube and on developer.android.com, where we unpacked all of the goodies coming out of this month’s Made by Google event and what you as Android developers need to know. With two new Wear OS 5 watches, we show you how to get building for the wrist. And with the latest foldable from Google, the Pixel 9 Pro Fold, we show how you can leverage out of the box APIs and multi-window experiences to make your apps adaptive for this new form factor.

Building for Pixel 9 Pro Fold with Adaptive UIs

With foldables like the Pixel 9 Pro Fold, users have options for how to engage and multitask based on the display they are using and the folded state of their device. Building apps that adapt based on screen size and device postures allows you to scale your UI for mobile, foldables, tablets and beyond. You can read more about how to get started building for devices like the Pixel 9 Pro Fold, or learn more about building for large screens.

Preparing for Pixel Watch 3: Wear OS 5 and Larger Displays

With Pixel Watch 3 ringing in the stable release of Wear OS 5, there’s never been a better time to prepare your app for the behavior changes from Wear OS 5 and larger screen sizes from Pixel. We covered how to get started building for wearables like Pixel Watch 3, and you can learn more about building for Wear OS 3.

Gemini Nano, with multi-modality

We also took you behind the scenes with Gemini Nano with multimodality, Google’s latest model for on-device AI. Gemini Nano, the smallest version of the Gemini model family, can be executed on-device on capable Android devices including the latest Pixel 9. We caught up with the team to hear more about how the Pixel Recorder team used Gemini Nano to summarize users’ transcripts of audio recordings, with data remaining on-device.

And some voices from Android devs like you!

Across the show, we heard from some amazing developers building excellent apps, across devices. Like Rex Jin and Bismark Ito, Android Developers at Meta: they told us how the team at Instagram was able to add Ultra HDR in less than three months, dramatically improving the user experience. Later, SAP told us how within 5 minutes, they integrated NavigationSuiteScaffold, swiftly adapting their navigation UI to different window sizes. And AllTrails told us they are seeing 60% higher monthly retention from Wear OS users… pretty impressive!


Have an idea for our next episode of #TheAndroidShow? It’s your conversation with the broader community, and #TheAndroidShow is your conversation with the Android developer community, this time hosted by Huyen Tue Dao and John Zoeller. You'll hear the latest from the developers and engineers who build Android. You can watch the full show on YouTube Comment start and on developer.android.com/events/show!

Adding 16 KB Page Size to Android

Posted by Steven Moreland – Staff Software Engineer, Sandeep Patil – Principal Software Engineer

A page is the granularity at which an operating system manages memory. Most CPUs today support a 4 KB page size and so the Android OS and applications have historically been built and optimized to run with a 4 KB page size. ARM CPUs support the larger 16 KB page size. When Android uses this larger page size, we observe an overall performance boost of 5-10% while using ~9% additional memory.

In order to improve the operating system performance overall and to give device manufacturers an option to make this trade-off, Android 15 can run with 4 KB or 16 KB page sizes.

The very first 16 KB enabled Android system will be made available on select devices as a developer option. This is so you can use the developer option to test and fix (if needed) your applications to prepare for Android devices with 16 KB page sizes in the near future.

Details

In most CPUs, dedicated hardware called memory management units (MMUs) translate addresses from what a program is using to a physical location in memory. This translation is done on a page-size basis. Every time a program needs more memory, the operating system needs to get involved and fill out a “page table” entry, assigning that piece of memory to a process. When the page size is 4 times larger, there is 4 times less bookkeeping. So, the system can spend more time making sure your videos look great, games play well, and applications run smoothly, and less time filling out low-level operating system paperwork.

Unlike 32-bit/64-bit mode, a page size is not an Application Binary Interface (ABI). In other words, once an application is fixed to be page size agnostic, the same application binary can run on both 4 KB and 16 KB devices.

In Android 15, we’ve refactored Android from the ground up to support running at different page sizes, thus making it page-size agnostic.

Major OS Changes

On new Android 15 based devices:

    • All OS binaries are 16 KB aligned (-Wl,-z,max-page-size=16384). 3rd party applications / libraries may not be 16 KB aligned.
    • All OS binaries are built with separate loadable segments (-Wl,-z,separate-loadable-segments) to ensure all memory regions mapped into a process are readable, which some applications depend on.

Many of our other OS components have been rewritten to avoid assuming the page size and to optimize for larger page size when available.

Filesystems

For performant operation, file system block size must match the page size. EROFS and F2FS file systems have been made 16 KB compatible, as has the UFS storage layer.

On 4 KB systems, ELF executable file size increases due to additional padding added for 16 KB alignment (-Wl,-z,max-page-size=16384 option), but several optimizations help us avoid this cost.

  1. Sparse read-only file systems ensure that zero pages created for additional padding for 16 KB alignment are not written to disk. For example, EROFS knows a certain range of a file is zero filled, and it will not need to do any IO if this part of the file is accessed.
  2. Read-writeable file systems handle zero pages on a case-by-case basis. For example, In Android 15, for files installed as part of applications PackageManager reclaims this space.

Memory Management

  1. The Linux page cache has been modified not to read ahead for these extra padding spaces, thereby saving unnecessary memory load.
  2. These pages are blank padding, and programs never read this. It’s the space in-between usable parts of the program, purely for alignment reasons.

Linux Kernel

The Linux kernel is deeply tied to a specific page size, so we must choose which page size to use when building the kernel, while the rest of the operating system remains the same.

Android Applications

All applications with native code or dependencies need to be recompiled for compatibility with 16 KB page size devices.

Since most native code within Android applications and SDKs have been built with 4 KB page size in mind, they need to be re-aligned to 16 KB so the binaries are compatible with both 4 KB and 16 KB devices. For most applications and SDKs, this is a 2 step process:

  1. Rebuild the native code with 16 KB alignment.
  2. Test and fix on a 16 KB device/emulator in case there are hardcode assumptions about page size.

Please see our developer documentation for more information.

NOTE: If you are an SDK or tools developer, you should add 16 KB support as soon as possible so that applications can work on 16 KB using your SDK or tools.

Developing for 16 KB devices

There are no production Android devices available today or expected for the Android 15 release that support a 16 KB page size. In order to fix this problem, we are taking steps to work with our partners to make a developer option available on existing devices. This developer option is meant for application development and testing. We are also making a 16 KB emulator target available for developers in Android Studio.

16 KB Developer option on device

In Android 15, we implemented a developer option that lets users switch between 16 KB and 4 KB page size on the device in order to test their application with either of the page sizes. This option is available on Pixel 8 and Pixel 8 Pro starting in the Android 15 QPR1 Beta, and we're collaborating closely with SoC and OEM partners to enable the option on additional devices soon.

screen grab of 16KB developer option on device

When built for 16 KB pages, the same binary will work with 4 KB and 16 KB devices, however the Linux kernel has to be separate. In order to solve this problem, we’ve added a way to include an extra kernel you can switch to as a developer option. Incrementally compressed, with one copy for each page size and takes ~12-16 MB of space on disk.

Using the 16 KB developer option will require wiping the device once and an unlocked bootloader. Following flashing, developers will be able to switch between a 4 KB and 16 KB mode by toggling the developer option over a reboot.

If you are a device manufacturer or SoC developer, see our instructions on how to enable and use this.

16 KB on x86_64 desktops

While 16 KB pages are an ARM-only feature, we recognize that many developers are using emulators on x86_64 hardware. In order to bridge this gap for developers, we’ve added support to emulate 16 KB page size for applications on x86_64 emulators. In this mode, the Kernel runs in 4 KB mode, but all addresses exposed to applications are aligned to 16 KB, and arguments to function calls such as mmap(...MAP_FIXED...) are verified to be 16 KB aligned.

To get started, you can download and run the 16 KB pages emulator inside the Android Studio SDK manager. This way, even if you don’t have access to ARM hardware, you can still ensure your applications will work with 16 KB page size.

16 KB pages emulator inside the Android Studio SDK manager

Future

In this post, we’ve discussed the technical details of how we are restructuring memory in Android to get faster, more performant devices. Android 15 and AOSP work with 16 KB pages, and devices can now implement 16 KB pages as a development option. This required changes from the bottom to the top of the operating system, in our development tooling, and throughout the Android ecosystem.

We are looking forward to application and SDK developers now to take advantage of these options and prepare for more performant and efficient Android devices in near future.

Tune in for our summer episode of #TheAndroidShow on August 27!

Posted by Anirudh Dewani – Director, Android Developer Relations

In just a few days, on Tuesday, August 27 at 10AM PT, we’ll be dropping our summer episode of #TheAndroidShow, on YouTube and on developer.android.com. In this quarterly show, we’ll be unpacking all of the goodies coming out of this month’s Made by Google event and what you as Android developers need to know!



With two new Wear OS 5 watches, we’ll show you how to get building for the wrist. And with the latest foldable from Google, the Pixel 9 Pro Fold, we’ll show how you can leverage out of the box APIs and multi-window experiences to make your apps adaptive for this new form factor.

Plus, Gemini Nano now has Multimodality, and we’ll be going behind-the-scenes to show you how teams at Google are using the latest model for on-device AI.

#TheAndroidShow is your conversation with the Android developer community, this time hosted by Huyen Tue Dao and John Zoeller. You'll hear the latest from the developers and engineers who build Android.

Don’t forget to tune in live on August 27 at 10AM PT, live on YouTube and on developer.android.com/events/show!

#WeArePlay | Meet the founders turning their passions into thriving businesses

Posted by Robbie McLachlan, Developer Marketing

Our celebration of app and game businesses continues with #WeArePlay stories from founders around the world. Today, we’re spotlighting the people who turned their passions into thriving businesses - from a passion for art and design from one game creator, to a passion for saving the environment from an app maker.

Brian, founder of SweatyChair
Sydney, Australia

During a gaming developer competition, Brian - alongside his wife and three other participants - built a challenging monster and bullet-dodging game called No Humanity within 48 hours, winning first place in the competition. From this, Brian founded his gaming company SweatyChair. No Humanity was improved and launched a week later and grew to over 9 million downloads. His passion for technology and art is how he champions a more active gaming experience, where players can create their own elements and play them in the game.


Prachi, founder and CEO of Cool The Globe
Pune, India

When Prachi travelled to Maharashtra, she saw first-hand how the effects of climate change impacted the locals. Her passion for protecting the environment led her to ask herself “What can I do about climate change?”. She vowed to reduce her carbon footprint and went on to create Cool The Globe, an app that helps people track daily actions to lower their emissions. Her dedication earned her the Young Changemaker Award in India. Next, she aims to add community dashboards for schools and organizations to follow their collective climate efforts.


François, Benoit and Julie Co-founders of Yuka App
Chatou, France

Benoit is passionate about providing nutritious food for his children, so he went on a mission to buy healthier food for his family. Whilst shopping, he found label-reading tiring and wished for a tool to check ingredients automatically. He shared his idea with his brother François and close friend Julie. Together, the trio saw a real need to combine their passions for nutrition and technology and spent a weekend hammering out their concept before presenting the idea in a food hackathon they went on to win. Their winning project laid the groundwork for their app Yuka, which scans product labels to reveal their ingredients and health impact.


Michelle, founder of Peanut App
London, UK

When the loneliness of early motherhood hit after her first child, Michelle sought community and answers from online forums. When the forums didn’t provide the safe space she was looking for, her passion for building community along with her 10 years of experience in social networking inspired her to create Peanut. The app helps moms to connect, make friends, and find support. With over 2.3 million downloads and a budding global community, the Peanut team recently revamped the main feed for greater personalization and introduced an ad-free option.

Discover more global #WeArePlay stories and share your favorites.



How useful did you find this blog post?

Indie Games Fund: Google Play’s $2m fund in Latin America is back

Posted by Daniel Trócoli – Google Play Partnerships

Back again for 2024, we’re opening up applications for Google Play’s Indie Games Fund in Latin America - as part of our commitment to helping developers of all sizes grow on Google Play. Check out the 10 selected studios who received a share of the fund last year.

We will award a share of $2 million in addition to hands-on support to selected small games studios based in Latin America.

The program is open to indie game developers who have already launched a game - whether it’s on Google Play or another mobile platform, PC or console. Each selected recipient will get between $150,000 and $200,000 to help them take their game to the next level, and build successful businesses.

Check out all eligibility criteria and apply now. Applications close at 12:00pm BRT September 13, 2024. Priority will be given to applications received by 12:00pm BRT August 30, 2024.

For more updates about all our programs, resources and tools for indie game developers visit our website.

Create exceptional experiences on Pixel’s new watches and foldables

Posted by Maru Ahues Bouza – Product Management Director

Pixel just announced the latest devices coming to the Android ecosystem, including Pixel 9 Pro Fold and Pixel Watch 3. These devices bring innovation to the foldable and wearable spaces, with larger screen sizes and exceptional performance.

Not only are these devices exciting for consumers, but they are also important for developers to consider when building their apps. To prepare you for the new Pixel devices and all the innovations in large screens and wearables, we’re diving into everything you need to know about building adaptive UIs, creating great Wear OS 5 experiences, and enhancing your app for larger watch displays.

Building for Pixel 9 Pro Fold with Adaptive UIs

Pixel unveiled their new foldable, Pixel 9 Pro Fold with Gemini, at Made By Google. This device has the largest inner display on a phone1 and is 80% brighter than last year’s Pixel Fold. When it’s folded, it’s just like a regular phone, with a 6.3-inch front display. Users have options for how to engage and multitask based on the screen they are using and the folded state of their device - meaning there are multiple different experiences that developers should be considering when building their apps.

the Pixel 9 Pro Fold

Developers can help their app look great across the four different postures – inner, front, tabletop, and tent – available on Pixel 9 Pro Fold by making their app adaptive. By dynamically adjusting their layouts—swapping components and showing or hiding content based on the available window size rather than simply stretching UI elements—adaptive apps take full advantage of the available window size to provide a great user experience.

When building an adaptive app, our core guidance remains the same – use WindowSizeClasses to define specific breakpoints for your UI. Window size classes enable you to change your app layout as the display space available to your app changes, for example, when a device folds or unfolds, the device orientation changes, or the app window is resized in multi‑window mode.

Announced at Google I/O 2024, we’ve introduced APIs that, under the hood, take advantage of these WindowSizeClasses for you. These APIs provide a new way to implement common adaptive layouts in Compose. The three components in the library – NavigationSuiteScaffold, ListDetailPaneScaffold, and SupportingPaneScaffold – are designed to help you build an adaptive app with UI that looks great across window sizes.

Finally, developers who want to build a truly exceptional experience for foldables should consider supporting tabletop mode, where the phone sits on a surface, the hinge is in a horizontal position, and the foldable screen is half opened. You can use the Jetpack WindowManager library, leveraging FoldingFeature.State and FoldingFeature.Orientation to determine whether the device is in tabletop mode. Once you know the posture the device is in, update your app layout accordingly. For example, media apps that adapt to tabletop mode typically show audio information or a video above the fold and include controls and supplementary content just below the fold for a hands-free viewing or listening experience.

Screenshot of gameplay from Asphalt Legends Unite (Gameloft)
Asphalt Legends Unite (Gameloft)

Even games are making use of foldable features: from racing games like Asphalt Legends Unite and Disney Speedstorm to action games like Modern Combat 5 and Dungeon Hunter 5, Gameloft optimized their games so that you can play not just in full-screen but also in split-view tabletop mode which provides a handheld game console experience. With helpful features like detailed game maps and enhanced controls for more immersive gameplay, you’ll be drifting around corners, leveling up your character, and beating the bad guys in record time!

Preparing for Pixel Watch 3: Wear OS 5 and Larger Displays

Pixel Watch 3 is the latest smartwatch engineered by Google, designed for performance inside and out. With this new device, there are also new considerations for developers. Pixel Watch 3 rings in the stable release of Wear OS 5, the latest platform version, and has the largest display ever from the Pixel Watch series - meaning developers should think about the updates introduced in Wear OS 5 and how their UI will look on varied display sizes.

the Pixel Watch 3

Wear OS 5 is based on Android 14, so developers should take note of the system behavior changes specific to Android 14. The system includes support for the privacy dashboard, giving users a centralized view of the data usage for all apps running on Wear OS 5. For apps that have updated their target SDK version to Android 14, there are a few additional changes. For example, the system moves always-on apps to the background after they're visible in ambient mode for a certain period of time. Additionally, watches that launch with Wear OS 5 or higher will only support watch faces that use the Watch Face Format, so we recommend that developers migrate to using the format. You can see all the behavior changes you should prepare your app for.

Another important consideration for developers is that the Pixel Watch 3 is available in two sizes, 41 mm and 45 mm. Both sizes offer more display space than ever2, having 16% smaller bezels, which gives the 41 mm watch 10% more screen area and the 45 mm watch 40% more screen area than on the Pixel Watch 2! As a developer, review and apply the principles on building adaptive layouts to give users an optimal experience. We created tools and guidance on how to develop apps and tiles for different screen sizes. This guidance will help to build responsive layouts on the wrist using the latest Jetpack libraries, and make use of Android Studio’s preview support and screenshot testing to confirm that your app works well across all screens.

Learn more about all these exciting updates in the Building for the future of Wear OS technical session, shared during this year’s Google I/O event.

Learn more about how to get started preparing your app

With these new announcements from Pixel, it’s a great time to make sure your app looks great on all the screens your users love most. Get your app ready for large screens by building adaptive layouts and learn more about all things Wear OS on our Wear OS developer site. For game developers, be sure to read our large screen game optimization guide and check the sample project to learn the best practices for leveling up your game for large screen and foldable devices.

For even more of the latest from Android, tune into the Android Show on August 27th. We’ll talk about Wear OS, adaptive apps, Jetpack Compose, and more!


1 Among foldable phones in the United States. Based on inner display. 
2 Compared with Pixel Watch 2.

#WeArePlay | How Jakub is infusing Czech mythology into his games

Posted by Robbie McLachlan, Developer Marketing

In our latest film for #WeArePlay, which celebrates the people behind groundbreaking apps and games, Jakub takes us on a journey through the world of Amanita Design. Born in Prague, Czech Republic, his journey into the world of games began with a passion for animation and an eye for artistic detail. Driven by a vision to create games that blend captivating art with immersive storytelling, he founded his company Amanita Design in 2003.

Today, the thriving business is renowned for its unique approach to games, drawing inspiration from Czech landscapes, fairy tales, and the rich cultural heritage of its homeland. With a dedicated team of around 30, they are crafting games as visually stunning as they are narratively rich. Discover how he is merging the charm of Czech culture with the magic of gaming.



What’s the inspiration behind Amanita Design and your game Machinarium?

I have a love for nature, fairy tales, and Czech culture. Growing up in Prague, I was surrounded by beautiful landscapes and old buildings that sparked my imagination. I studied classical animation and always wanted to create something that felt both magical and deeply connected to my roots. Our games often use Czech folklore and the natural world. In 2009, when we developed Machinarium, I was fascinated with industrial decay and old machinery. The abandoned factories around Prague provided a gritty backdrop for the game. We paired this with a compelling story and handcrafted visuals. We even used natural sounds from our environment to add an authentic touch.



Did you always imagine you’d be an entrepreneur?

I didn’t initially see myself as an entrepreneur. My journey began with a passion for games and animation, and I started Amanita Design as a natural extension of my interests. I began the studio right after finishing school, driven by a desire to create and share my artistic vision. Over time, as the studio grew organically, I embraced the role of an entrepreneur but it was the love for game development that initially set me on this path.

What sets your games apart?

What makes our games stand out is the mix of old-world craftsmanship with today’s tech. We really enjoy incorporating hand-painted cardboard characters and using natural materials for sound effects, which adds a unique, tactile feel to our work. We draw deeply from Czech culture, nature, and fairy tales, giving each game a distinctive and enchanting touch. It’s all about creating something authentic and immersive, and we hope that passion resonates with our players.



What does the future look like for Amanita Design?

We’re working on several new games and exploring different distribution models, such as the free-to-try approach on mobile platforms. Our goal is to continue creating unique and artistically rich games that resonate with a global audience. As technology evolves, we plan to adapt and innovate, maintaining our focus on storytelling and artistic craftsmanship while embracing new opportunities in the gaming industry.

Discover more global #WeArePlay stories and share your favorites.



How useful did you find this blog post?

Android Device Streaming: Announcing Early Access to Samsung, Xiaomi, and Oppo Device Labs

Posted by Grant Yang (Product Manager for OmniLab) & Adarsh Fernando (Product Manager for Android Studio)

At Google I/O 2024, we announced Android Device Streaming in open beta, which allows you as a developer to more easily access and interactively test your app on real physical devices located in Google data centers and streamed directly to Android Studio. This enables teams in any location to access a variety of devices across top Android device manufacturers, including the latest family of Google Pixel and Samsung Galaxy series devices.

We’re significantly expanding on the diversity of devices available in this service by working closely with Android device manufacturers (also known as original equipment manufacturers, or OEMs)—such as Samsung, Xiaomi, and Oppo—to connect their device labs to Android Device Streaming, so you can access even more physical devices directly in your workflow in Android Studio. This integration is offered with the same performance, stability, and security benefits you get with devices provided by Google. Keep reading for more details below, as well as how you can sign up for the early access and take advantage of these new devices.

screen grab of Device Streaming in Android Studio
Access devices hosted by Google and other OEMs, such as Samsung, with Android Device Streaming, powered by Firebase

Signup for Early Access to OEM Lab Devices

If you haven’t already done so, follow the steps to get up and running with the beta release of Android Device Streaming, which will give you access to all the Google-hosted devices to test with directly from Android Studio. Later this year, we will start an Early Access Program that allows participants to use Android Device Streaming to connect to devices hosted by our OEM partners. This expands the catalog of test devices available to you with Android Device Streaming.

To kick off this program, we’re first partnering with Samsung, Xiaomi, and Oppo. These labs will be situated in various locations around the world, and you will be able to use the Firebase project you’re already using with Android Device Streaming in Android Studio to access them. Your Firebase project’s administrator will have control to enable or disable individual OEM labs.

If you’d like to participate in the EAP for accessing OEM device labs, fill out this form, and we will let you know if you and your team have been accepted. During the EAP, OEM-provided devices will not be billed or counted against your promotional monthly quota.

We look forward to sharing more details during Google’s I/O Connect Beijing in early August 2024.

In the meantime, we encourage you to try out the devices currently available in Android Device Streaming. Currently, the Android Device Streaming program is in a promotional period, with a higher amount of monthly minutes offered at no cost, which will last until approximately February 2025.

OEM Labs powered by OmniLab

Omnilab Logo

Some of you may wonder how these devices are being connected through to Android Studio. Under the hood, Android Device Streaming is built on top of the device platform for Google, OmniLab. OmniLab, the same device platform that powers all internal device labs, is also powering the OEM labs. Omnilab did this by open sourcing their Android Test Station (ATS) framework available to its open source.

OmniLab provides a framework to ensure that your Android Device Streaming session is secure and performant. You’re able to deploy, debug, and interact with your app on these remote devices through a direct ADB over SSL connection, all without having to leave the IDE. And when the session ends, the device data is fully wiped and factory reset before it’s made available to another developer.


In summary, if you’d like to participate in the EAP for accessing OEM device labs, fill out this form, and we will let you know if you and your team have been accepted. During the EAP, OEM-provided devices will not be billed or counted against your promotional monthly quota.

Be part of our vibrant community on LinkedIn, Medium, YouTube, or X and share your experiences on using Android Device streaming in Android Studio.

Making security easy: How we are helping you fix vulnerabilities in your Android apps

Posted by Bessie Jiang – Software Engineer and Chris Schneider – Security Engineer

Contributors: Maciej Szawłowski – Security Engineer, Hannah Barnes – Technical Program Manager, Dirk Göhmann – Technical Writer, Patrick Mutchler – Software Engineer

Security is tricky, but vital to protecting your users and their data. We’re here to help you build secure Android apps with fewer vulnerabilities for an even safer Android ecosystem for everybody.

Vulnerability Detection – How it Works

Google currently scans every app on Google Play for dozens of common security vulnerability classes. If we spot something, we let you know so you can fix the problem. Imagine a pentesting team hunting for bugs in each of the millions of apps published on Play, rooting out issues like bad TLS configurations that expose network traffic or directory traversal vulnerabilities that let adversaries read from or write to an app’s private files.

We are committed to keeping our joint users protected. In serious cases, if a security vulnerability doesn't get fixed, Google may remove the app from Google Play to keep users safe.

Android Application Security Knowledge Base

We know that it isn’t always enough to just tell you about a vulnerability in your app; you need to know how to fix the issue and how to prevent similar issues from cropping up in the future. To this end, we are introducing our security guidance and recommendations under a new program: the Android Application Security Knowledge Base (AAKB).

AAKB aims to establish guidelines for writing secure Android software. It is a repository of common code issues, with remediation examples and explanations for implementing specific code patterns. Organic in nature, new issues are identified automatically for review with experts across the industry – ensuring broad but well-tested approaches and guidance.

Data collected from your engagement with AAKB is used to improve guidance, and to identify how to make the Android ecosystem more secure by default.

How Does it Work?

AAKB establishes clear, vetted guidance with code examples. Guidance is aligned to OWASP MASVS standards, and content is vetted in partnership with technical peers, such as Microsoft. This helps ensure the content is not biased to one party and represents state-of-the-art standards. This also provides an educational place for you to proactively remediate security risks in your applications using industry-wide standards, with direct access to knowledge from subject-matter experts.

The guidance is available through two mechanisms:

The AAKB homepage lists each article independently, aligned to the relevant OWASP MASVS category (e.g. MASVS-STORAGE). Anyone can view or provide direct feedback to this content. Security is an ever-changing field, and being able to update guidance on the fly means software development lifecycles can be updated dynamically with as little friction as possible.

Android Studio triggers remediation guidance from lint checks by pointing directly to AAKB articles. You can fix problems as you're building the app and before they ever reach users.

There are two methods to view remediation guidance with Android Studio:

Existing security lint checks within Android Studio Giraffe+ have had their descriptions updated to include a link to the relevant AAKB article, allowing you get more context as to why a particular code snippet might be potentially “at-risk”.

Example of a finding with a link to a relevant AAKB article in the Android Studio IDE
Figure 1. Example of a finding with a link to a relevant AAKB article in the Android Studio IDE

Meanwhile, the open-source Android Security lint checks give you access to our most recent guidance and experiments to further protect your mobile applications and get ahead of future security concerns.

Add the open source checks to your project by following the README. These lint checks all contain click-to-fix functionality that make it easy for you to write safer code with minimal effort, as well as links to the relevant AAKB articles like the built-in IDE checks.

Example of an open-source security lint finding, highlighting a vulnerable code snippet and click-to-fix solution
Figure 2. Example of an open-source security lint finding, highlighting a vulnerable code snippet and click-to-fix solution

All built-in IDE lint checks can be found in this list, with many under the Security category containing links to relevant AAKB articles. We would love to hear your feedback and suggestions for new lint checks and other improvements to the open-source lint library.