Posted by Paris Hsu, Product Manager, Android Studio

Android Studio Narwhal 4 Feature Drop is now stable and ready for you to use! This release brings targeted support for declarative Wear OS watch faces, a new customization option for your Project view, and continues our focus on quality by fixing 550+ numbers of bugs to improve stability and performance.

This is also the final feature drop for the Android Studio Narwhal releases. With the new monthly release cadence, we’ve been delivering new features and bug fixes every month. The last three Narwhal releases have been packed with features, including the launch of Agent Mode and Compose previews. We’d like to not only share what’s new in this release, but also recap some key features from the Narwhal releases.

---

What’s New in Android Studio Narwhal 4 Feature Drop

Here are the new features shipping with this release:

Declarative Wear OS watch faces support in Android Studio

Android Studio Narwhal 4 Feature Drop improves the workflow for creating Wear OS watch faces by introducing editor support for the Watch Face XML Format to write, debug, and fine-tune your watch face designs directly within the IDE. This helps you work faster by bringing the Android development process into the IDE instead of having to change context and work with multiple programs when developing watch faces. 

Declarative watch faces support in Android Studio

Android Studio lets you directly edit the XML files used in the Watch Face Format. It now provides code completion for tags and attributes based on the official Watch Face Format schemas and live error validation that helps identify issues like missing required attributes. Android Studio also includes resource linking to quickly navigate to drawable resources and other referenced XML elements along with advanced syntax support for handling arithmetic expressions and data source references embedded in the XML. Finally, you can deploy watch faces directly to a Wear OS emulator or physical device from Android Studio.

Option to make Project view your default

Tired of always having to switch to the Project view every time you open a new project? There is a new setting to have new projects open in Project view by default. To enable the setting go to File (Android Studio on macOS) > Settings > Advanced Settings > Project View and select Set Project view as the default.

Settings to make Project view your default

---

A look back: key features from the Android Studio Narwhal releases

The Android Studio Narwhal releases have been packed with features, especially with our move to monthly releases. Between powerful AI integrations and new testing tools, it can be easy to miss an update. Below, we highlight a few key features, but for a complete look at everything we shipped, we highly recommend reading the full posts for Narwhal Feature Drop and Narwhal 3 Feature Drop.

Here’s a quick summary of some of the top features you should be trying out:

Agent Mode

Have Google Gemini help with your tasks by using Agent Mode. The AI agent can understand your project, break down complex tasks into smaller steps, make edits on your behalf, and help you with multi-step operations — like adding new features, refactoring code, or debugging complex issues right inside your IDE. Developers such as Entri used Agent Mode to generate Jetpack Compose layouts from UI mockups, and found that Gemini in Android Studio reduced their overall UI development time by 40%. 

Gemini in Android Studio: Agent Mode

Android partner device labs (using Android Device Streaming)

We expanded Android Device Streaming by adding Android Partner Device Labs. This gives you secure access to a wide range of remote, physical devices from partners like Samsung, enabling you to test your app’s compatibility and performance on some of the most popular devices in the market, directly from Android Studio.

Android Device Streaming supports Android Partner Device Labs

Test app backup and restore

We added tools to test your app’s data backup and restoration flow. This is critical for ensuring a smooth user experience when switching to a new device. You can generate a backup of your app’s data, restore it to another device, and even attach backups to your run configurations to test this flow easily.

Backup and restore dialog

Resizable Compose Preview

Building responsive UIs became much easier in Android Studio Narwhal. Compose Preview now supports dynamic resizing, giving you instant visual feedback on how your UI adapts to different screen sizes. You can simply enter Focus mode in the Compose Preview and drag the edges to see your layout change in real time.

Resizable compose preview

Google Play policy insights

Get early warnings about potential Google Play policy violations to help you build more compliant apps with Play Policy Insights, now in Android Studio. The IDE now shows lint warnings directly in your code when it relates to a Google Play policy requirement. You can also integrate these lint checks into your CI/CD pipelines. These insights provide an overview of the policy, dos and don’ts, and links more resources, helping you address potential issues early in your development cycle.

Play policy insights example

---

Summary

To recap, the entire Android Studio Narwhal release series, including this Narwhal 4 Feature Drop, has delivered a wide array of powerful features. Here is a comprehensive summary of the major additions:

Develop with AI (Gemini)

• Agent Mode: An semi-autonomous AI assistant that helps with complex, multi-step operations like refactoring, adding features, and debugging.

• AGENTS.md support: Provide project-specific context, instructions, and style guides to Gemini.

• Rules in Prompt Library: Customize Gemini’s output to match your team’s coding standards.

• Image & @File attachment: Attach screenshots and project files for more context-aware responses.

• Transform UI (Studio Labs): Use natural language to iterate on Compose UI directly in the preview window.

Faster UI iteration and development

• Declarative Wear OS watch faces support (New in Narwhal 4 ): Write, debug, and deploy watch faces with code completion, error validation, and direct deployment.

• Resizable Compose Preview: Dynamically resize previews in Focus mode to instantly test responsive UIs.

• Compose preview improvements: Better code navigation and a new picker for managing previews.

Optimize, refine and test

• Test App Backup and Restore: Easily test your app’s data backup and restoration flow for new device transfers.

• Android Partner Device Labs: Access a wide range of remote, physical partner devices from Samsung and more for testing.

• Google Play policy insights: Get early warnings about potential Play Policy violations directly in the IDE.

• Proguard inspections: Identify and fix overly broad keep rules for better code optimization.

• K2 mode by default: Faster performance with the next-generation Kotlin compiler.

• 16 KB page size support: Lint warnings and an emulator to prepare for new devices.

Immersive development (XR)

• Embedded Android XR emulator: Run the XR emulator directly inside the IDE.

• Embedded Layout Inspector for Android XR: Inspect and optimize UI layouts within the XR environment.

• Android XR project template: A new template to quickly start XR projects.

IDE workflow and quality improvements

• Project view default (New in Narwhal 4 ): A new advanced setting to always open new projects in the Project view.

• Display build files under module: Improve project navigation in the Android view.

• Manual project sync: Gain more control over when Gradle syncs occur in large projects.

• Quality improvements: Fixed xx numbers of bugs in this release for better stability and performance.

---

Get started

Ready to accelerate your development? Download Android Studio Narwhal 4 Feature Drop from the stable channel today!

Your feedback is essential. Please continue to share your thoughts by reporting bugs or suggesting features. For early access to the latest features, download Android Studio from the Canary channel.

Join our vibrant Android developer community on LinkedIn, Medium, YouTube, or X. We can’t wait to see what you build!

The post Android Studio Narwhal 4 Feature Drop: watch face support and improved stability appeared first on InShot Pro.

Posted by Robbie McLachlan – Developer Marketing

In our latest #WeArePlay stories, we meet the founders building apps and games that are making finance simple for everyone, everywhere. From providing first-time loans in Myanmar to digitizing piggy banks for young savers in Nigeria, these founders are breaking down traditional financial barriers.

Here are a few of our favorites:

Yusuf E, Yağmur, Tolgahan and Yusuf D, co-founders of Yuyuto Games Technology Istanbul, Türkiye

Yağmur, Yusuf D, Yusuf E, and Tolgahan’s game Ticarium Business Tycoon teaches real-world finance and entrepreneurial skills in a virtual world.

University friends Yağmur, Yusuf D, Yusuf E, and Tolgahan turned a passion project for an old simulation game into Ticarium Business Tycoon. The game lets players run companies, trade goods, and learn about finance in a fun, risk-free environment, encouraging entrepreneurial thinking. Now live in over 30 countries, the founders plan to scale globally and launch new titles to reach even more future entrepreneurs.

Theta, founder of Mother Finance Yagon, Myanmar

Theta’s AI-powered app Mother Finance provides microloans and financial education to people in Myanmar.

While working at a bank in Myanmar, Oxford and MIT graduate Theta saw that many citizens couldn’t access credit without traditional collateral. She created Mother Finance to provide microloans, financial literacy content, and a localized digital credit score, supporting over 300,000 people so far. Looking ahead, the team is developing loan products for overseas Burmese workers with the goal of becoming Myanmar’s leading digital lender.

Odunayo, Somtochukwu, and Joshua co-founders of Piggytech Global Lagos, Nigeria 

Somtochukwu, and Joshua’s app PiggyVest lets anyone get started with micro-savings and investments.

University friends Odunayo, Somtochukwu, and Joshua knew that high banking fees in Nigeria kept young people from saving. Inspired by a social media post, they decided to digitize the traditional piggy bank. They launched PiggyVest, a micro-savings and investment app that lets anyone get started with as little as 100 Naira, helping many build better financial habits. Now, the team is aiming for 10 million downloads to make finance more accessible for the next generation.

Discover other inspiring app and game founders featured in #WeArePlay.

The post #WeArePlay: Meet the people building apps and games that are making finance simple for everyone, everywhere. appeared first on InShot Pro.

Posted by Robbie McLachlan – Developer Marketing

In our latest #WeArePlay film, which celebrates the people behind apps and games on Google Play, we meet Bryan, Jeremy and Elias, the co-founders of Geocaching. For nearly 25 years, their app has been turning the world into a real-life treasure hunt by using technology to inspire outdoor adventure and connect a global community. Discover the origin story of this unique app and the incredible impact it’s had in the past 25 years.

What was the spark that led to Geocaching?

Bryan: It all started almost 25 years ago. We were just three friends working at a dot-com, all passionate about technology and the outdoors. One day, Jeremy brought a new GPS unit into the office, and we were fascinated.

Jeremy: I also found this early online game called the “Great American GPS stash hunt”. I came back to the office completely hooked and told the guys we could build a website to make it easier for everyone to play. We all recognized the potential in that idea.

Bryan: We decided to combine our different skills in web development, IT infrastructure, and my business background to support what was then just a tiny hobby.

Jeremy, Elias and Bryan when they first started Geocaching

For those who haven’t played, how does Geocaching work?

Jeremy: The basic idea is a real-world treasure hunt. When you find a cache, the rules are simple: if there are items inside, you can take one, but you have to replace it with something of similar value. Then, you sign the physical logbook and put the container back exactly where you found it for the next person.

Bryan: The geocaching community has now hidden over 3.4 million geocaches worldwide. They’re placed everywhere. You’ve probably walked past dozens without ever knowing it. Caches are hidden everywhere all over the world, from the middle of a city to a mountain trail. You will find them in unexpected places.

Bryan, we heard Geocaching has had a huge personal impact on your own life. Can you tell us about that?

Back in 2001, I went to my first-ever Geocaching event. It was a simple potluck in a park, but that’s where I met my wife, Heidi, who was there with her son Dylan. Our first date was even a hike to find a special, hard-to-find geocache! Now, almost 25 years later, we’re a geocaching family through and through. It’s amazing because my story isn’t unique; we hear all the time from people who have found lifelong friends, partners, and a whole community through this game.

Geocaching started before smartphones. How has technology, and Google Play specifically, changed the game?

Bryan: In the early days, you had to buy a dedicated GPS device that could cost hundreds of dollars. As a bootstrapped business, having our app on Google Play was legitimately game-changing for us. It put a powerful GPS device into everyone’s pocket and gave us access to a global audience. It has really enabled the growth of this game worldwide. From a developer standpoint, we build our app on Google’s technology; Google Maps is the foundation of the entire experience.

What’s next for Geocaching?

Bryan: We’re celebrating our 25th anniversary with community events all over the world and by releasing Treasures, a brand-new feature in the app. Looking ahead, our mission remains the same: to inspire outdoor adventure, exploration, and community. We want to continue using technology to get more people outside, away from their couches, and having real-world experiences.

Discover other inspiring app and game founders featured in #WeArePlay.

The post #WeArePlay: Meet the founders of Geocaching, the digital treasure hunt game with 3.4 million caches appeared first on InShot Pro.

Written by Alice Yuan, Senior Developer Relations Engineer

Most of the content of this post is also available in video format, go give it a watch!

Battery life is a crucial aspect of user experience and wake locks play a major role. Are you using them excessively? In this blog post we’ll explore what wake locks are, what are some best practices for using them and how you can better understand your own app’s behavior with the Play Console metric.

Excessive partial wake lock usage in Android Vitals

The Play Console now monitors battery drain, with a focus on excessive partial wake lock usage, as a key performance indicator.

This feature elevates the importance of battery efficiency alongside existing core metric stability indicators: excessive user-perceived crashes and ANRs. Currently, an app exceeding the threshold will not be less discoverable on Google Play.

The excessive wake lock warning in the Android vitals overview.

For mobile devices, the Android vitals metric applies to non-exempted wake locks acquired while the screen is off and the app is in the background or running a foreground service. Android vitals considers partial wake lock usage excessive if:

• Wake locks are held for at least two hours within a 24-hour period.

• It affects more than 5% of your app’s sessions, averaged over 28 days.

Wake locks created by audio, location, and JobScheduler user initiated APIs are exempted from the wake lock calculation.

Understanding wake locks

A wake lock is a mechanism that allows an app to keep a device’s CPU running even when the user isn’t actively interacting with it. 

A partial wake lock keeps the CPU running even if the screen is off, preventing the CPU from entering a low-power “suspend” state. A full wake lock keeps both the screen and the CPU running.

There are 2 methods partial wake locks are acquired:

• The app manually acquires and releases the wake lock using PowerManager APIs for a specific use case, often this is acquired in conjunction with a Foreground Service – a platform lifecycle API intended for user-perceptible operation.

• Alternatively, the wake lock is acquired by another API, and attributed to the app due to usage of the API, more on this in the best practices section.

While wake locks are necessary for tasks like completing a user-initiated download of a large file, their excessive or improper use can lead to significant battery drain. We’ve seen cases where apps hold wake locks for hours or fail to release them properly, leading to user complaints about significant battery drain even when they’re not interacting with the app.

Best Practices for Wake Lock Usage

Before we go over how to debug excessive wake lock usage, ensure you’re following wake lock best practices. 

Consider these four critical questions.

1. Have you considered alternative wake lock options?

Before considering acquiring a manual partial wake lock, follow this decision-making flowchart:

Flowchart to decide when to manually acquire a wake lock

1. Does the screen need to stay on?

• Yes: Reference the Keep Screen On documentation instead

Is the application running a foreground service? 

• No: You don’t need to manually acquire a wake lock.

Is it detrimental to the user experience if the device suspends? 

• No: For instance, updating a notification after the device wakes up doesn’t require a wake lock. 

• Yes: If it’s critical to prevent the device from suspending, like ongoing communication with an external device, proceed.

Is there already an API keeping the device awake on your behalf?

• You can leverage the documentation Identify wake locks created by other APIs to identify scenarios where wake locks created by other APIs to identify scenarios where wake locks are created by other APIs such as LocationManager.

• If no APIs exist, proceed to the final question.

If you’ve answered all these questions and determined no alternative exists, you should proceed with manually acquiring a wake lock.

2. Are you naming the wake lock correctly?

When manually acquiring wake locks, proper naming is important for debugging:

• Leave out any Personally Identifiable Information (PII) in the name like email addresses. If PII is detected, the wake lock is logged as _UNKNOWN, hindering debugging.

• Don’t name your wake lock programmatically using class or method names, as these can be obfuscated by tools like Proguard. Instead, use a hard-coded string.

• Do not add counters or unique identifiers to wake lock tags. The same tag should be used every time the wake lock runs to allow the system to aggregate usage by name, making abnormal behavior easier to detect.

3. Is the acquired wake lock always released?

If you’re acquiring a wake lock manually, ensure the wake lock release always executes. Failing to release a wake lock can cause significant battery drain. 

For example, if an uncaught exception is thrown during processingWork(), the release() call might never happen. Instead, you can use a try-finally block to guarantee the wake lock is released, even if an exception occurs.

Additionally, you can add a timeout to the wake lock to ensure it releases after a specific period, preventing it from being held indefinitely.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Can you reduce the wake-up frequency?

For periodic data requests, reducing how often your app wakes up the device is key to battery optimization. Some examples of reducing wake-up frequency include:

• WorkManager: Increase the periodic interval in PeriodicWorkRequests.

• SensorManager: Leverage batching by specifying maxReportLatencyMs when registering the listener.

• Fused Location Provider: 

• Reduce location retrieval frequency by using getLastLocation for the most recent cached location. 

• Use setPriority(PRIORITY_PASSIVE) for a less battery-intensive update method. 

• Also, you can leverage the location batching mechanism by setting a minimum update interval with setMinUpdateIntervalMillis.

You can view more details in the wake lock best practices documentation.

Debugging excessive wake lock usage

Even with the best intentions, excessive wake lock usage can occur. If your app is flagged in the Play Console, here’s how to debug it:

Initial identification with Play Console

The Android vitals excessive partial wake lock dashboard provides breakdowns of non-exempted wake lock names associated with your app, showing affected sessions and durations. Reminder to use the documentation to help you identify if the wake lock name is app-held or held by another API.

The Android vitals excessive partial wake lock dashboard scrolled down to the breakdowns section to view excessive wake lock tags.

Debugging excessive wake locks held by workers/jobs

You can identify worker-held wake locks with this wake lock name:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

The full list of variations of worker-held wake lock names is available in documentation. To debug these wake locks, you can use Background Task Inspector to debug locally, or leverage getStopReason to debug issues in the field. 

Android Studio Background Task Inspector

Screen capture of the Background Task Inspector, where it has been able to identify a worker “WeatherSyncWorker” that has frequently retried and failed.

For local debugging of WorkManager issues, use this tool on an emulator or connected device (API level 26+). It shows a list of workers and their statuses (finished, executing, enqueued), allowing you to inspect details and understand worker chains. 

For instance, it can reveal if a worker is frequently failing or retrying due to hitting system limitations. 

See Background Task Inspector documentation for more details.

WorkManager getStopReason

For in-field debugging of workers with excessive wake locks, use WorkInfo.getStopReason() on WorkManager 2.9.0+ or for JobScheduler, JobParameters.getStopReason() available on SDK 31+. 

This API helps log the reason why a worker stopped (e.g., STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), pinpointing issues like frequent timeouts due to exhausting runtime duration.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

See Optimize battery use for task scheduling APIs for more details.

Debugging other types of excessive wake locks

For more complex scenarios involving manually held wake locks or APIs holding the wake lock, we recommend you use system trace collection to debug.

System trace collection

A system trace is a powerful debugging tool that captures a detailed record of system activity over a period, providing insights into CPU state, thread activity, network activity, and battery-related metrics like job duration and wake lock usage.

You can capture a system trace using several methods: 

• Utilizing the system trace command line tool

• Using the Android Studio CPU Profiler

• Using the Perfetto UI

• Recording a trace manually on the device directly from the developer options. 

Enable “power:PowerManagement” Atrace category in the Perfetto UI under the Android apps & svcs tab. 

Regardless of the chosen method, it’s crucial to ensure that you are collecting the “power:PowerManagement” Atrace category to enable viewing of device state tracks. 

Perfetto UI inspection and SQL analysis

System traces can be opened and inspected in the Perfetto UI. When you open the trace, you will see a visualization of various processes on a timeline. The tracks we will be focused on in this guide are the ones under “Device State”.

Pin the tracks under “Device State” such as “Top app”, “Screen state”, “Long Wake locks”, and “Jobs” tracks to visually identify long-running wake lock slices.

Each block lists the name of the event, when the event started, and when it ended. In Perfetto, this is called a slice.

For scalable analysis of multiple traces, you can use Perfetto’s SQL analysis. A SQL query can find all wake locks sorted by duration, helping identify the top contributors to excessive usage.

Here’s an example query summing all the wake lock tags that occurred in the system trace, ordered by total duration:

SELECT slice.name as name, track.name as track_name,
SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'
GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

Use ProfilingManager for in-field trace collection

For hard-to-reproduce issues, ProfilingManager (added in SDK 35) is a programmatic API that allows developers to collect system traces in the field with start and end triggers. It offers more control over the start and end trigger points for profile collection and enforces system-level rate limiting to prevent device performance impact. 

Check out the ProfilingManager documentation for further steps on how to implement in field system trace collection which include how to programmatically capture a trace, analyze profiling data, and use local debug commands.

The system traces collected using ProfilingManager will look similar to the ones collected manually, but system processes and other app processes are redacted from the trace.

Conclusion

The excessive partial wake lock metric in Android vitals is only a small part of our ongoing commitment to supporting developers in reducing battery drain and improving app quality. 

By understanding and properly implementing wake locks, you can significantly optimize your app’s battery performance. Leveraging alternative APIs, adhering to wake lock best practices, and using powerful debugging tools such as Background Task Inspector, system traces and ProfilingManager are key to ensuring your app’s success on Google Play.

The post Optimize your app battery using Android vitals wake lock metric appeared first on InShot Pro.

Posted by Matthew Forsythe, Director, Product Management, Android App Safety

We recommend you register. It’s a simple, one-time process that will allow anyone to download and install your app. However, if you prefer not to, we are also introducing a free developer account type that will allow teachers, students, and hobbyists to distribute apps to a limited number of devices without needing to provide a government ID.

The post Let’s talk security: Answering your top questions about Android developer verification appeared first on InShot Pro.

Posted by Robbie McLachlan – Developer Marketing

In our latest #WeArePlay stories, we meet the founders who turned their interests into vibrant communities through their apps and games on Google Play – from democratizing music production for artists in Brazil to building a global network for Black professionals.

Here are a few of our favorites:

Erick and Kelvin, co-founders of Murb  São Bernardo do Campo, Brazil

Erik and Kelvin’s app Murb connects and enables indie artists in Brazil to create and distribute music from their phones.

Brothers Erick and Kelvin combined their passion for Brazil’s urban culture from skateboarding to graffiti with their professional experience in tech to create Murb. Their app empowers young, independent artists in the rap, trap, and funk communities to produce music directly on their phones, providing a vital platform for those who lack access to studios. With recent features like producer profiles to help musicians sell their work and plans to integrate with major streaming platforms, Murb is on a mission to democratize music production.

Channing, founder of BlackListed Texas, U.S.

Channing’s app BlackListed empowers Black professionals with a dedicated platform to build community, share career milestones, and directly support Black-owned businesses.

After working as a product manager in the energy sector, Channing saw the need for a dedicated space where Black professionals could connect, celebrate achievements, and support each other. She created BlackListed, a social networking app for users to share career milestones and job updates. Channing is now preparing to launch a new shopping feature to support Black-owned businesses directly through the app, with plans to expand the platform to Canada and Africa.

Zeyang, Kan, and Susheng, co-founders of ChillyRoom
 Shenzhen, China 

Zeyang, Kan and Susheng built a global community with their popular game Soul Knight.

After meeting in the U.S. while studying computer science, Zeyang, Kan, and Susheng united over a shared passion for gaming to launch ChillyRoom. Their hit title, Soul Knight, is a rogue-like pixel shooter built purely for fun, intentionally avoiding pay-to-win mechanics. The game’s co-op and local multiplayer modes helped it spread rapidly through word-of-mouth in schools and dorms, building a dedicated global community. Today, the team is developing new projects while staying true to their mission of providing opportunities for the next generation of game developers.

Discover other inspiring app and game founders featured in #WeArePlay.

The post #WeArePlay: Meet the people building vibrant communities with their apps and games appeared first on InShot Pro.

Posted by Aurash Mahbod – VP and GM, Games on Google Play

We’re evolving Google Play Games into an integrated experience centered on the player journey. Today, players have to jump between different platforms to discover, play, and socialize. Our goal is to connect these journeys to create the best gaming experience for players and grow your business. Games that offer seamless and rewarding experiences achieve higher engagement and growth on Play. That’s why we’re introducing Google Play Games Level Up, a new way we’re leveling up the player experience and unlocking greater success for your business.

The Level Up program is open to all games¹, including access to powerful tools and promotional opportunities. Games can stay enrolled in the program and maximize benefits by meeting the user experience guidelines by each program milestone, the first milestone date being July 2026. Let’s take a closer look at the benefits and guidelines of Google Play Games Level Up.

Program benefits to accelerate your growth

Games that are part of the Level Up program can access a suite of benefits to accelerate business growth. This includes a new space to engage with players, access to content tools in Play Console, and enhanced discovery opportunities through editorial surfaces on the Play Store.

1. Re-engage players on You tab. You tab² is a new personalized destination on the Play Store where players can view content and rewards from games they’ve recently played, all in one dedicated place. It’s designed to help you re-engage and retain players by showcasing your latest events, offers, and updates.

   Games can feature their content on You tab using engagement tools in Play Console. You can drive player engagement through a rich store presence using promotional content, Play Points coupons, YouTube videos, and achievements, which all show up on your game detail page and You tab.

   
   Clash of Clans is re-engaging players through You tab

2. Maximize your game’s reach. To make it easier for players to discover great games, we’re incorporating the user experience guidelines into our editorial criteria. Games that are part of the program will have the opportunity for prominent boosts across the store including featuring opportunities and Play Points boosters and quests. Titles that are part of the program will have more opportunities to be recommended through editorial surfaces across the store including the Games home and Play Points home.  

   
   Get more opportunities to be featured on editorial surfaces

3. Unlock deeper performance insights. Making the right decisions to grow your game requires a clear picture of your entire business. Next year, we’re introducing more advanced reporting in Play Console. You’ll be able to connect the dots from player acquisition to long-term engagement and monetization, giving you the holistic insights needed to optimize your growth strategy with confidence.

Guidelines built on great user experience

Games can stay enrolled in the program and access benefits by meeting the user experience guidelines. These guidelines are based on what players want: a seamless, rewarding experience everywhere they play. To deliver on this, we’ve established three core user experience guidelines:

1. Player continuity: Today’s players enjoy their games across multiple devices. They want to continue playing without missing a beat. Cloud save makes this possible, Cloud save makes this possible, while Play Games Services automatically syncs their sign-in credentials for a seamless experience.

   We’re making this experience even better with Play Games Sidekick. The new in-game overlay gives players instant access to their rewards, offers, and achievements, driving higher engagement for your game. With AI-driven tips and advice, Sidekick helps players stay immersed in the games they love. Starting early next year, you can enable this experience by using a simple toggle in Play Console with a streamlined testing process.

• Play Games Sidekick July, 2026
• Cloud save November, 2026
• Seamless restore November, 2026

Play Games Sidekick keeps players immersed in your game

Rewarding player journeys: Players love seeing the time and effort they invest in games be recognized and rewarded. By designing achievements that span the lifetime of the game—celebrating progression to discovering hidden surprises or even acknowledging failed attempts—you can make a player’s entire experience feel more engaging and valued. By implementing high quality achievements, you’ll become eligible for Play Points quests that reward players for completing each achievement and increase retention for your game.

• Achievements July, 2026

DREDGE rewards player progression through achievements

Cross device gameplay: Players want the flexibility to enjoy their favorite games on any device. We’ve seen games optimized for multiple device types—from mobile to tablet to PC—drive higher player engagement and spend.  To make these games even easier for players to find, we are launching new in-store discovery features later this year to prominently showcase titles with great cross device and input support.

You can give your players the flexibility to play how they want by adding keyboard and mouse support, as well as controller support—which also unlocks better gaming with attachable mobile controllers and Android XR. Google Play Games on PC makes it easier to bring your mobile game to a new audience with a streamlined distribution using Play Console.

• Controller and mouse / keyboard support Recommended
• Play on PC Recommended

User experience guidelines by each program milestone

Start exploring Google Play Games Level Up today

The Level Up program is rolling out in Play Console starting today. Player expectations and developer needs are always evolving. The Level Up program is designed to evolve with them which is why user experience guidelines and benefits may be updated over time. We’re committed to providing updates early so you can make informed decisions about the program. 

Google Play Games Level Up is how we’re investing in your success and creating the best experience for players. We believe that by partnering to build amazing experiences, we can build a stronger ecosystem for everyone.

¹ Games in the Casino category, including social casino and real-money wagering titles, may have limited access to certain program benefits.
² You tab is available in countries where Google Play Points is offered. See the Play Points Help Center for details.

The post Introducing the Google Play Games Level Up program appeared first on InShot Pro.

Posted by Mayuri Khinvasara Khabya – Developer Relations Engineer (LinkedIn and X)

Welcome to the second installment of our three-part series on media preloading with Media3. This series is designed to guide you through the process of building highly responsive, low-latency media experiences in your Android apps.

• Part 1: Introducing Preloading with Media3 covered the fundamentals. We explored the distinction between PreloadConfiguration for simple playlists and the more powerful DefaultPreloadManager for dynamic user interfaces. You learned how to implement the basic API lifecycle: adding media with add(), retrieving a prepared MediaSource with getMediaSource(), managing priorities with setCurrentPlayingIndex() and invalidate(), and releasing resources with remove() and release().
• Part 2 (This post): In this blog, we explore the advanced capabilities of the DefaultPreloadManager. We cover how to gain insights with PreloadManagerListener, implement production-ready best practices like sharing core components with ExoPlayer, and master the sliding window pattern to effectively manage memory.
• Part 3: The final part of this series will dive into integrating PreloadManager with a persistent disk cache, enabling you to reduce data consumption with resource management and provide a seamless experience.

If you are new to preloading in Media3, we highly recommend reading Part 1 before proceeding. For those ready to move beyond the basics, let’s explore how to elevate your media playback implementation.

Listening in: Fetch analytics with PreloadManagerListener

When you want to launch a feature in production, as an app developer you also want to understand and capture the analytics behind it. How can you be certain that your preloading strategy is effective in a real-world environment? Answering this requires data on success rates, failures, and performance. The PreloadManagerListener interface is the primary mechanism for gathering this data.

The PreloadManagerListener provides two essential callbacks that offer critical insights into the preloading process and status.

• onCompleted(MediaItem mediaItem): This callback is invoked upon the successful completion of a preload request, as defined by your TargetPreloadStatusControl.
• onError(PreloadException error): This callback could be useful for debugging and monitoring. It is invoked when a preload fails, providing the associated exception.

You can register a listener with a single method call as shown in the following example code:

val preloadManagerListener = object : PreloadManagerListener {
    override fun onCompleted(mediaItem: MediaItem) {
        // Log success for analytics. 
        Log.d("PreloadAnalytics", "Preload completed for $mediaItem")
    }

    override fun onError( preloadError: PreloadException) {
        // Log the specific error for debugging and monitoring.
        Log.e("PreloadAnalytics", "Preload error ", preloadError)
    }
}

preloadManager.addListener(preloadManagerListener)

Extracting insights from the listener 

These listener callbacks can be hooked to your analytics pipeline. By forwarding these events to your analytics engine, you can answer key questions like:

• What is our preload success rate? (ratio of onCompleted events to total preload attempts)
• Which CDNs or video formats exhibit the highest error rates? (By parsing the exceptions from onError)
• What is our preload error rate? (ratio of onError events to total preload attempts)

This data could give you quantitative feedback on your preloading strategy, enabling A/B testing and data-driven improvements to your user experience. This data can further help you to intelligently finetune your preload durations and number of videos you want to preload as well as the buffers you allocate.

Beyond debugging: Using onError for graceful UI fallback

A failed preload is a strong indicator of an upcoming buffering event for the user. The onError callback allows you to respond reactively. Instead of merely logging the error, you can adapt the UI. For instance, if the upcoming video fails to preload, your application could disable autoplay for the next swipe, requiring a user tap to begin playback.

Additionally, by inspecting the PreloadException type you can define a more intelligent retry strategy. An app can choose to immediately remove a failing source from the manager based on the error message or HTTP status code. The item would need to be removed from the UI stream accordingly to not make loading issues leak into the user experience. You could also get more granular data from PreloadException like the HttpDataSourceException to probe further into the errors. Read more about ExoPlayer troubleshooting.

The buddy system: Why is sharing components with ExoPlayer necessary?

The DefaultPreloadManager and ExoPlayer are designed to work together. To ensure stability and efficiency, they must share several core components. If they operate with separate, uncoordinated components, it could impact thread safety and usability of preloaded tracks on the player since we need to ensure that preloaded tracks should be played on the correct player. The separate components could also compete for limited resources like network bandwidth and memory, which could lead to performance degradation. An important part of the lifecycle is handling appropriate disposal, the recommended order of disposal is to release the PreloadManager first, followed by the ExoPlayer.

The DefaultPreloadManager.Builder is designed to facilitate this sharing and has APIs to instantiate both your PreloadManager and a linked player instance. Let’s see why components like BandwidthMeter, LoadControl, TrackSelector, Looper must be shared. Check the visual representation of how these components interact with ExoPlayer Playback.

Preventing bandwidth conflicts with a shared BandwidthMeter

The BandwidthMeter provides an estimate of available network bandwidth based on historical transfer rates. If the PreloadManager and the player use separate instances, they are unaware of each other’s network activity, which can lead to failure scenarios. For example, consider the scenario where a user is watching a video, their network connection degrades, and the preloading MediaSource simultaneously initiates an aggressive download for a future video. The preloading MediaSource’s activity would consume bandwidth needed by the active player, causing the current video to stall. A stall during playback is a significant user experience failure.

By sharing a single BandwidthMeter, the TrackSelector is able to select tracks of highest quality given the current network conditions and the state of the buffer, during preloading or playback. It can then make intelligent decisions to protect the active playback session and ensure a smooth experience.

preloadManagerBuilder.setBandwidthMeter(customBandwidthMeter)

Ensuring consistency with shared LoadControl, TrackSelector, Renderer components of ExoPlayer

• LoadControl: This component dictates buffering policy, such as how much data to buffer before starting playback and when to start or stop loading more data. Sharing LoadControl ensures that the memory consumption of player and PreloadManager is guided by a single, coordinated buffering strategy across both preloaded and actively playing media, preventing resource contention. You will have to smartly allocate buffer size coordinating with how many items you are preloading and with what duration, to ensure consistency. In times of contention, the player will prioritize playback of the current item displayed on the screen. With a shared LoadControl, the preload manager will continue preloading as long as the target buffer bytes allocated for preloading hasn’t reached the upper limit, it doesn’t wait until the loading for playback is done.

Note : The sharing of LoadControl in the latest version of Media3 (1.8) ensures that its Allocator can be shared correctly with PreloadManager and player. Using the LoadControl to effectively control the preloading is a feature that will be available in the upcoming Media3 1.9 release.

preloadManagerBuilder.setLoadControl(customLoadControl)

• TrackSelector: This component is responsible for selecting which tracks (for example, video of a certain resolution, audio in a specific language) to load and play. Sharing ensures that the tracks selected during preloading are the same ones the player will use. This avoids a wasteful scenario where a 480p video track is preloaded, only for the player to immediately discard it and fetch a 720p track upon playback.< br />
  The preload manager should NOT share the same instance of TrackSelector with the player. Instead, they should use the different TrackSelector instance but of the same implementation. That’s why we set the TrackSelectorFactory rather than a TrackSelector in the DefaultPreloadManager.Builder.

preloadManagerBuilder.setTrackSelectorFactory(customTrackSelectorFactory)

• Renderer: This component is responsible for understanding the player’s capabilities without creating the full renderers. It checks this blueprint to see which video, audio, and text formats the final player will support. This allows it to intelligently select and download only the compatible media track and prevents wasting bandwidth on content the player can’t actually play.

preloadManagerBuilder.setRenderersFactory(customRenderersFactory)

Read about more Exoplayer components.

The golden rule: A common Playback Looper to rule them all

The thread on which an ExoPlayer instance can be accessed can be explicitly specified by passing a Looper when creating the player. The Looper of the thread from which the player must be accessed can be queried using Player.getApplicationLooper. By maintaining a shared Looper between the player and PreloadManager, it is guaranteed that all operations on these shared media objects are serialized onto a single thread’s message queue. This can reduce the concurrency bugs.

All interactions between the PreloadManager and the player with media sources to be loaded or preloaded need to happen on the same playback thread. Sharing the Looper is a must for thread safety and hence we must share the PlaybackLooper between the PreloadManager and player.

The PreloadManager prepares a stateful MediaSource object in the background. When your UI code calls player.setMediaSource(mediaSource), you are performing a handoff of this complex, stateful object from the preloading MediaSource to the player. In this scenario, the entire PreloadMediaSource is moved from the manager to the player. All these interactions and handoffs should occur on the same PlaybackLooper.

If the PreloadManager and ExoPlayer were operating on different threads, a race condition could occur. The PreloadManager’s thread could be modifying the MediaSource’s internal state (e.g, writing new data into a buffer) at the exact moment the player’s thread is attempting to read from it. This leads to unpredictable behavior, IllegalStateException that is difficult to debug.

preloadManagerBuilder.setPreloadLooper(playbackLooper)

Lets see how you can share all the above components between ExoPlayer and DefaultPreloadManager in the setup itself.

val preloadManagerBuilder =
DefaultPreloadManager.Builder(context, targetPreloadStatusControl)

// Optional - Share components between ExoPlayer and DefaultPreloadManager
preloadManagerBuilder
     .setBandwidthMeter(customBandwidthMeter)
     .setLoadControl(customLoadControl)
     .setMediaSourceFactory(customMediaSourceFactory)
     .setTrackSelectorFactory(customTrackSelectorFactory)
     .setRenderersFactory(customRenderersFactory)
     .setPreloadLooper(playbackLooper)

val preloadManager = val preloadManagerBuilder.build()

Tip: If you use the Default components in ExoPlayer like the DefaultLoadControl, etc, you don’t need to explicitly share them with DefaultPreloadManager. When you build your ExoPlayer instance via the buildExoPlayer of the DefaultPreloadManager.Builder these components are automatically referenced with each other, if you use the default implementations with default configurations. But if you use custom components or custom configurations, you should explicitly notify the DefaultPreloadManager about them via the above APIs.

Production-ready preloading: The sliding window pattern

In a dynamic feed, a user can scroll through a virtually infinite amount of content. If you continuously add videos to the DefaultPreloadManager without a corresponding removal strategy, you will inevitably cause an OutOfMemoryError. Each preloaded MediaSource holds onto a SampleQueue, which allocates memory buffers. As these accumulate, they can exhaust the application’s heap space. The solution is an algorithm you may already be familiar with, called the sliding window.
The sliding window pattern maintains a small, manageable set of items in memory that are logically adjacent to the user’s current position in the feed. As the user scrolls, this “window” of managed items slides with them, adding new items that come into view, and also removing items that are now distant.

Implementing the sliding window pattern

It is essential to understand that PreloadManager does not provide a built-in setWindowSize() method. The sliding window is a design pattern that you, the developer, are responsible for implementing using the primitive add() and remove() methods. Your application logic must connect UI events, such as a scroll or page change, to these API calls. If you want a code reference for this, we have this sliding window pattern implemented in socialite sample which also includes a PreloadManagerWrapper which imitates a sliding window.

Don’t forget to add preloadManager.remove(mediaItem) in your implementation when the item is no longer likely to come up soon in the user’s viewing. Failing to remove items that are no longer proximate to the user is the primary cause of memory issues in preloading implementations. The remove() call ensures resources are released that help you keep your app’s memory usage bound and stable.

Fine-Tuning a categorized preloading strategy with TargetPreloadStatusControl

Now that we have defined what to preload (the items in our window), we can apply a well defined strategy for how much to preload for each item. We already saw how to achieve this granularity with the TargetPreloadStatusControl setup in Part 1.

To recall, an item at position +/- 1 could have a higher probability of being played than an item at position +/- 4. You could allocate more resources (network, CPU, memory) to items the user is most likely to view next. This creates a “preloading” strategy based on proximity, which is the key to balancing immediate playback with efficient resource usage.

You could use analytics data via PreloadManagerListener as discussed in the earlier sections to decide your preload duration strategy.

Conclusion and next steps

You are now equipped with the advanced knowledge to build fast, stable, and resource-efficient media feeds using Media3’s DefaultPreloadManager.

Let’s recap the key takeaways:

• Use PreloadManagerListener to gather analytics insights and implement robust error handling.
• Always use a single DefaultPreloadManager.Builder to create both your manager and player instances to ensure important components are shared.
• Implement the sliding window pattern by actively managing add() and remove() calls to prevent OutOfMemoryError.
• Use TargetPreloadStatusControl to create a smart, tiered preloading strategy that balances performance and resource consumption.

What’s next in Part 3: Caching with preloaded media

Preloading data into memory provides an immediate performance benefit, but it can come with tradeoffs. Once the application is closed or the preloaded media is removed from the manager, the data is gone. To achieve a more persistent level of optimization, we can combine preloading with disk caching. This feature is in active development and will come soon in a few months.

Do you have any feedback to share? We are eager to hear from you.

Stay tuned, and go make your video playback faster!

The post Elevating media playback : A deep dive into Media3’s PreloadManager – Part 2 appeared first on InShot Pro.

Gratitude is a mental wellness Android app that encourages self-care and positivity with techniques like in-app journaling, affirmations, and vision boards. These mindfulness exercises need to be free from performance bottlenecks, bugs, and errors for the app to be truly immersive and helpful—but researching solutions and debugging code took away valuable time from the team experimenting on new features. To find a better balance, Gratitude used Gemini in Android Studio to help improve the app’s code and streamline the development process, enabling the team to implement those exciting new features faster.

Gratitude’s AI image generation feature, built in record time with the help of Gemini in Android Studio

Unlocking new efficiencies with Gemini in Android Studio

The Gratitude team decided to try Gemini in Android Studio, an AI assistant that supports developers throughout all stages of development, helping them be more productive. Developers can ask Gemini questions and receive context-aware solutions based on their code. Divij Gupta, senior Android developer at Gratitude, shared that the Gratitude team needed to know if it was possible to inject any object into a Kotlin object class using Hilt. Gemini suggested using an EntryPoint to access dependencies in classes where standard injection isn’t possible, which helped solve their “tricky problem,” according to Divij.

Gemini eliminated the need to search for Android documentation as well, enabling the Gratitude team to learn and apply their knowledge without having to leave Android Studio. “Gemini showed me how to use Android Studio’s CPU and memory profilers more effectively,” recalled Divij. “I also learned how to set up baseline profiles to speed up cold starts.”

Identifying performance bottlenecks became easier too. When analyzing the Gratitude team’s code, Gemini suggested using collectAsStateWithLifecycle instead of collectAsState to collect flows in composables, which helps the app handle lifecycle events more effectively and improves overall performance. Gemini also analyzes the app’s crash reports in the App Quality Insights panel and provides guidance on how to address each issue, which enabled the Gratitude team to “identify root causes faster, catch edge cases we might have missed, and improve overall app stability,” according to Divij.

Experimenting with new features using Gemini in Android Studio

Gemini in Android studio helped the Gratitude team significantly improve their development speed and morale. “This faster cycle has made the team feel more productive, motivated, and excited to keep innovating,” said Divij. Developers are able to spend more time ideating and experimenting on new features, leading to innovative new experiences.

One feature the developers built with their new found time is an image generation function for the app’s vision boards feature. Users can now upload a photo with a prompt, and then receive an AI-generated image that they can instantly pin to their board. The team was able to build the UI using Gemini in Android Studio’s Compose Preview Generation — allowing them to quickly visualize their Jetpack Compose code and craft the pixel-perfect UI their designers intended.

Going forward, the Gratitude team is looking forward to using Gemini to implement more improvements to its code, including correcting glitches, memory leaks, and improving performance based on more insights from Gemini, which will further improve user experience.

Build with Gemini in Android Studio

Discover all of the features available as part of Gemini in Android Studio that can accelerate your development such as code completion, code explanation, that can accelerate your development such as Agent Mode, document generation, and more.

The post Gratitude’s developers released 2X the amount of innovative experiments with the help of Gemini in Android Studio appeared first on InShot Pro.

Posted by Robbie McLachlan – Developer Marketing

In our latest #WeArePlay stories, we meet the people who turned personal challenges into successful apps and games on Google Play – from a new puppy inspiring a digital pet care assistant, to losing contact with family during an earthquake leading to an app that delivers real-time disaster alerts to millions.

Here are a few of our favorites:

Daiki Ishimori, founder of Gehirn Tokyo, Japan

Daiki’s app, NERV Disaster Prevention, delivers real-time, location-based disaster warnings.

A self-taught programmer from a young age, Daiki Ishimori was inspired by his popular social media posts sharing earthquake alerts to create the NERV Disaster Prevention app. Now a trusted daily safety tool, the app provides real-time, location-based warnings and recently launched a Crisis Mapping tool for multilingual, crowd-sourced relief information. Daiki is now gearing up to roll out new community features to keep people connected and protected during emergencies.

Jaimes Almeida Neto, Rafael Rojas and Rodrigo Gomes, co-founders of Budz São Paulo, Brazil

Jaimes, Rafael, and Rodrigo’s AI-powered app, Budz, helps dog and cat owners with training, health, and nutrition.

Inspired by a co-founder’s new puppy, Jaimes, Rafael, and Rodrigo created Budz to support fellow animal lovers. The app assists with pet training, health, and nutrition through features like vaccine reminders, 24/7 teleconsultations, and an AI tutor that answers real-time questions. By helping people in Brazil better care for their pets, Budz aims to reduce pet abandonment and is now preparing to expand across Latin America.

Khaldon Evans, Perrine Chapot and Victor Dequid, co-founders of Ochy
 Rennes, France  

Khaldon, Perrine and Victor’s app, Ochy, analyzes running form to prevent injuries.

After injuries sidelined his sprinting career, Khaldon Evans was inspired by his own recovery to make lab-grade movement analysis accessible. He teamed up with biomechanics expert Perrine Chapot and developer Victor Dequid to create Ochy. Using just a smartphone camera, the app analyzes a user’s running form to help runners, coaches, and doctors prevent injuries, and recently added a new back-view analysis feature. Next, the team plans to introduce personalized shoe recommendations and expand into new sports.

Discover other inspiring app and game founders featured in #WeArePlay.

The post #WeArePlay: Meet the people whose personal challenges inspired their apps and games. appeared first on InShot Pro.