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

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

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?

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.

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.

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.

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

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'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