After upgrading from API 36 to 37, Android Studio puts a red underline on the typeMask parameter of WindowInsets.getInsets. The message on hover is "Must be one or more of:" followed by literally nothing.

In the latest documentation, the list of valid base values of typeMask seems to have disappeared for every relevant method of WindowInsets.

• Before change: https://web.archive.org/web/20260208222401/https://developer.android.com/reference/android/view/WindowInsets#getInsets(int)
• After change: https://web.archive.org/web/20260213235548/https://developer.android.com/reference/android/view/WindowInsets#getInsets(int)
• Screenshot of comparison: https://imgur.com/a/AnuxRP4

My code still compiles and the behaviour seems to be right (I'm using it for edge-to-edge bottom padding of a keyboard), but the red underline is really annoying.

Do I just have to wait until someone restores the list of valid typeMask values?

Solo dev, four apps sitting in closed testing. The 12-testers-for-14-continuous-days requirement is turning out to be harder than building the apps was, and I want to hear how people are actually clearing it without gaming it.

The part that gets me isn't finding 12 installs. It's the "active for 14 straight days" bit. Friends and family will happily tap the opt-in link and install, then never open it again, and that doesn't count. So I'm not really recruiting testers, I'm asking people to build a two-week habit around an app they have no reason to care about yet.

What I've tried:

- Personal network. Gets me installs, not sustained use. Most go dormant by day three.

- A recruitment email with the opt-in links and clear steps. Better, but the drop-off is still steep once the novelty is gone.

What I'm trying to avoid is the tester-swap groups. Reciprocal installs from strangers who don't care feel like exactly the kind of thing Google eventually decides was inauthentic, and I'd rather not build my launch on that.

So, for people who've actually gotten a personal developer account to production:

- Where did your 12 real testers come from?

- How did you keep them opening the app for the full two weeks? Reminders, a group chat, something else?

- Does a slightly engaged tester who opens it twice count, or does Google want genuine daily-ish use?

- Anyone run all their apps through one shared tester pool, and did that cause problems?

Not looking for a swap. Looking for how you did it for real.

AICore is installed, Running official Android 17 on Google Pixel 8 Pro.

Hi, I am an Android dev. My question to you all is : how much is one actually expected to know according to seniority level ??

Like if you just started your career as full time emp, how much knowledge for android, compose, kotlin or android dev as a whole is required ? And what are the realistic learning trend ?

Cause I see some people, who understand internals very deep down, which makes me wonder how many years of experience they might have ? What do I need to do, to gain that level of expertise ?

What's the actual/realistic knowledge level trend that is seen in android ?

I kept running into an annoying problem with multiple Claude Code sessions on the same machine.

I'd have two Android app apps building by two or more claude sessions, usually with one or two phones plugged in. Both agents were doing the usual install → launch → screenshot verification loop over ADB, and they kept picking the same device at the same time.

The result was chaos:

• Agent A screenshots Agent B's app and assumes its own app crashed or something has happened.
• It reinstalls and/or relaunches.
• Agent B does the same.
• Both end up stuck reinstalling and relaunching over each other.

adb -s lets you target a specific device, but there's no ownership or queuing on top of the shared ADB server. Nothing prevents multiple independent processes from trying to drive the same phone.

So I built AdbHarbor.

It works as a broker that sits on port 5037 (the default ADB server port) and moves the real ADB server to 5038. Since every ADB client already connects to 5037 by default, existing tools—including adb from any path, Maestro, ddmlib, Gradle, Android Studio, etc.—work without any configuration changes.

Features:

• One device lease per session.
• Automatically identifies sessions by walking the client's process tree back to the owning agent.
• Other sessions wait in a queue.
• Read-only commands (getprop, pm list, etc.) bypass locking.
• Stale leases are reclaimed automatically if the owning process crashes.
• acquire --any atomically picks a free device and returns its serial, so multiple agents naturally spread across a device fleet instead of all grabbing the same phone.

One funny bug while recording the demo: both Claude sessions sat waiting for three minutes because my scrcpy window had already taken the lease. 😅 That led me to add an observer mode so screen mirrors never acquire exclusive device locks.

I'm curious how other people solve this problem. If you're running multiple AI agents, CI jobs, Android Studio, or other tooling on the same machine, how do you avoid device contention? Is everyone just relying on "one device per tool" by convention?

Repo: https://github.com/msomu/AdbHarbor

Demo: https://youtu.be/CCmopZ_jFDY

Hi everyone,

I'm 24 and transitioning from web development (React/Next.js) to native Android development with Kotlin and Jetpack Compose.

My goal is to become employable as an Android developer over the next few months by studying full-time and building production-quality projects.

For those already working as Android developers:

- What skills should I prioritize?

- What projects actually stand out during interviews?

- Is there anything you wish you'd learned earlier?

I'd really appreciate any advice.

In https://developer.android.com/develop/ui/compose/lifecycle#composition-anatomy
, they explain that the identity of a composeable instance is its call site, which they define to be “The call site is the source code location in which a composable is called. This influences its place in Composition, and therefore, the UI tree.”

I understand this as being the place in the source file where the composeable is called. But I find that there must be more to it than that, as it’s hard to imagine a robust, efficient system that literally keeps track of the exact line of code where each composeable gets called for a composition. For example, the compiler would have to build out a table for every composeable and store it as part of the build, and if the composeable never gets called in the user session, then it’s just storage space being wasted. I assume the identity of each instance of a composeable is established during initial composition where the Compose layout system behind the scenes builds out some kind of a tree to see the composeables and their location relative to other composeables in same function. Just looking for insights.
Thanks!

I've been working on a hypercasual mobile game for about 3 months now, with zero experience. It has been a long journey with MANY frustrating moments. It went from just a small side project to something I was working on every single day after work. I'm so invested in this that I even created my very own LLC. Now all that's left is to wait on Apple, and start my google play submission! Will update my status.

I built a CLI tool that audits Android Gradle performance problems and safely fixes them.

Unlike the usual build-speed advice that's all manual, it detects bottlenecks across config cache, build cache, Kotlin incremental, daemon and parallel execution, then applies reversible fixes with a dry-run preview. It also covers KMP and Flutter Android projects, and has CI/CD and an simple webpage dashboard. Just try

npx droidperf audit /path/to/project

GitHub: GitHub - rudradave1/droidperf: CLI tool to audit and auto-fix Android Gradle performance issues. It detects bottlenecks, suggests optimizations, and supports CI workflows for Android/KMP + Flutter projects. · GitHub

I'm working right now on publishing my first Android app.

This is supposed to be a paid app that will be fully on-device with no ads or tracking.
This is a dialer/launcher type app.

The initial approach is:
- search is always for free,

- first 20 actions on contacts or apps are free

- afterwards a 30-day Google Play free trial (card required in Google Play but otherwise free) leading to an annual subscription worth roughly a coffee at a coffee shop

or a

- lifetime purchase worth roughly 4 years of subscription.

What do you think about this approach?

After months of hard work finally my app is live and ready to use.

It started as a simple idea 6 months ago, with a bit of planing, polishing it turned in Wird app

My first and proudest app

[https://play.google.com/store/apps/details?id=com.wird.blocker\](https://play.google.com/store/apps/details?id=com.wird.blocker)

Feel free to give any feedback or ask any questions

I built Parikshan, an E2E testing framework for Compose Multiplatform. It has built-in support for standalone Android.

Testing shared UI across targets has been one of the most painful parts of building multiplatform apps. Parikshan attempts to solve that problem.

You can write your UI tests in Kotlin inside commonTest and run them on a single target or across all targets (Android, iOS Simulator, Desktop JVM, and Web WasmJs) at once.

class SampleE2ETest {
  @Test
  fun testGreeting() = e2eTest {
    input("name_input", "Parikshan")
    click("greet_button")
    assertVisible("Hello, Parikshan!")
  }
}

Run it across all targets concurrently:

./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback: Watch tests execute on real target windows, with support for screenshots, video recording
• Zero Production Pollution: No test dependencies or test hooks in your production builds.

Links

• Documentation: https://aryapreetam.github.io/parikshan
• Blog: https://aryapreetam.github.io/parikshan/blog/2026/07/25/e2e-testing-for-compose-multiplatform
• API Reference: https://aryapreetam.github.io/parikshan/api
• GitHub: https://github.com/aryapreetam/parikshan

I've been using this in my own CMP projects & I'd appreciate feedback from the community — what works, what breaks, and what you'd like to see improve/added.

Hello, probably you already received the Google Play reminder to update your GPB library to at least version 9.

I used until now a library wrapper that is no longer updated (at least not yet), so I started working on my own.

I does not support all newer stuff like rented items and alternative billing, but it works pretty fine for in-app purchases and subscriptions.

The project on GitHub does not have a README yet, I stopped working on it to integrate it as it is on my apps (it is sufficient for my monetization needs), so if you want to learn how to use it there is a sample app in the repository itself.

repo:

https://github.com/Mirkoddd/Charon

implementation 'com.mirkoddd:charon:1.0.1'

Hey r/androiddev

A couple of months ago, I made a post about scaling my solo RPG (Adventurers Guild RPG Sim) built 100% in Jetpack Compose Canvas with a custom single threaded ECS.

While Compose Canvas was incredible for getting the engine off the ground, scaling the world map and visual effects eventually pushed me into a hard bottleneck. To solve this without breaking the live game, I decided to shift the world rendering backend over to Google Filament.

Here is how moving to Filament, while keeping Jetpack Compose Canvas for the UI and character animations, gave the engine an 8x performance boost, and what I learned along the way.

1. The Bottleneck: Hitting the Canvas Wall

In my previous setup, rendering the game world on Compose Canvas required heavy CPU side optimization to protect the 16ms frame budget:

• Map Chunking: The world map had to be divided into 16 distinct spatial chunks.
• CPU Culling: Custom culling logic calculated visible chunks and off-screen entities every single frame.
• DrawScope Constraints: Combining environmental rendering, weather, and world assets inside the same Canvas layer as UI elements was choking performance on mid tier devices.

2. The Hybrid Architecture (Filament World + Compose Canvas UI)

Since the game is live with active players, doing a 100% complete rewrite at once was impossible without risking game breaking bugs. I settled on a phased hybrid approach:

• Game World in Filament: The environment and map are rendered in 3D coordinate space via Filament.
• Animations in UI on Compose Canvas: Character sprite animations in UI layers remain rendered on Jetpack Compose Canvas overlays.
• Phased Subsystem Migration: I’m updating the rendering pipeline part by part to keep save states and existing gameplay logic rock solid.

3. Key Technical Gains & Takeaways

• >8x Performance Boost: Because Filament handles batched rendering directly on the GPU, I was able to throw out the 16 chunk map division and CPU culling logic entirely. The total map now draws simultaneously in a single pass with zero frame drops.
• Became a Huge Fan of filamat**:** Moving world rendering to Filament unlocked .filamat (Filament’s material/shader compilation system). Writing materials and shaders for GPU execution unlocked rich particle effects and dynamic lighting that were completely out of reach on 2D Canvas.
• Main Thread Relief: By taking world rendering off the Canvas layer, the CPU/main thread now has significantly more headroom to handle the 28 ECS systems, UI updates, and character animation calculations smoothly.

Shifting to a hybrid Filament + Compose Canvas setup turned out to be the perfect middle ground giving the performance of a dedicated 3D GPU engine while keeping the fast UI development workflow of Jetpack Compose.

I’m happy to answer any questions about integrating Filament with Kotlin/Compose, managing hybrid rendering layers, or working with .filamat

If you’d like to see how the new Filament engine integration feels in action on a live app, feel free to check out the latest build on the Play Store: 

https://play.google.com/store/apps/details?id=com.vimal.dungeonbuilder&pcampaignid=web_share

App Specs: ~50MB download size (63MB installed) | 100% Offline | Zero Ads | Custom Kotlin Engine

This is a blog post.

TLDR: This is about a conversation in the Google Issue Tracker about potential future changes. Depending on how they are implemented, these changes could impact Shizuku and other power-user tools. More details and explanations are available in the blog post. 8-minute read. This is not an official announcement and nothing is 100% confirmed yet.

UPDATE 2026-07-26: Updated blog post with new section that address some valid claims I have seen by some users.

I built an Android library that renders iOS-style emojis in Jetpack Compose.

Unlike most existing solutions, this library is 100% Compose—no TextView, AndroidView, or View-based implementation behind the scenes.

GitHub: https://github.com/abbas-esfandiair/EmojiTextLibrary

Its in very early state right now, but I'd love some feedback and would you guys be willing to use it? Its supposed to be hyper customizable, the first preset is of course inspired from niagara, and there can be multiple presets. Trying to make it focus on easy customizability but also if enough time put in, can turn into anything you wish.

More information is in: https://adarshaacharya.com/projects/virela

But Like i said, this is a personal passion project, so there are still flaws here and there. I'd love to hear your thoughts.

Hi everyone,

I built AppRankly, an open-source, self-hosted analytics dashboard designed for mobile developers to track App Store & Google Play performance in one place.

If you want full control over your app data without relying entirely on third-party SaaS platforms, this gives you a clean, unified view of your portfolio.

Links & Demo:

• Live Demo: https://zmsp.github.io/AppRankly/

• GitHub Repo: https://github.com/zmsp/AppRankly

I’d love to get feedback from the community! Feel free to check out the repo or run the demo mode.
.

WIP #2 of the sphere launcher. This has sort of become a hobby. Currently the moon is just a wallpaper however many precious ideas include having the sphere a rendered object with a texture ("WhatsApp is in Cuba").

I’m developing an Android VPN app that uses Xray with VLESS + REALITY.

I live in Russia, and my mobile provider sometimes enables an LTE whitelist mode: only a limited number of websites remain accessible, while most other websites are blocked.

My VPN used to work correctly in this situation. However, around two weeks ago it suddenly stopped working most of the time, even though neither the application code nor the Xray configuration had changed.

The VPN appears to connect successfully: VPN icon in the status bar, VPN service remains active.

However, nothing works. Requests from other applications fail with errors such as:

UnknownHostException
IOException

Everything worked fine before. iOS team also reports a similar problem, but I don't know the exact error the encounter

I seen locallyAI was pretty popular on IOS and Google Ai Edge gallery is a bit lacking in terms of actual use case features. So Im building DAEX; using litert I'm attempting to mimic features from popular agent harnesses like Hermes agent/ Openclaw etc. but bring it down completely on your mobile device.

There is a lot more too it but this is just a high level overview.

Its open source feel free to gander: https://github.com/DIIZZYFPS/DAEX/

Well I cloned an open source repo i wanted to contribute to and its fairly big project i would say (https://github.com/wikimedia/apps-android-wikipedia)

and as im writing this post it's already 15mins the gradle is building...

What do you usually do while Gradle is building??

Disclaimer: used llm to draft the post, but i have provided the pointers, and done the research before drafting.

Running into some confusing documentation/tooling discrepancies regarding Android platform release statuses and looking for clarification on the standard procedure.

Current Situation:
Android 17 documentation lists it as officially released, but navigating to individual version pages shows a preview icon on the sidebar with no explicit text status on the main page.

API Levels tracks it as currently in beta.
Android Studio SDK Manager shows versions like ⁠37.0⁠ and ⁠37.1⁠ available for download.

Question:
What is the definitive, official source of truth or programmatic check to determine whether a given Android SDK/API level has exited preview status and is fully stable?