I've always been bothered by how slow mobile UI tests are. Most of a test run is spent waiting: fixed sleeps, polling, comparing screenshots to guess whether the app is done animating. Coming from a game dev background, where you fight for every millisecond of a frame, that felt like a solvable problem. So I spent the last while building my own runner from the ground up, and it turns out UI tests can be a lot faster.

Speedrun is a black-box E2E test runner for Android and iOS. It's open source (Apache 2.0) and it runs Maestro's YAML flow format so if you already have Maestro tests, trying it is one word:

maestro test flows/ # before
speedrun test flows/ # after

Numbers

One user journey (sign in with a code, search a shop, fill a cart, set a PIN under a loading overlay, scroll a long list), written for each tool the way its tests are usually written. Median of 3 runs after a warm-up, start-up included:

On the native Settings app benchmark it's 8x faster than Maestro on Android and 2.8x on iOS. On a 19-flow React-Native test suite it passes all 19 on both platforms, and is 6.1x faster on Android and 2.6x on iOS. Android is where it shines most, which is nice for CI: Android runs on cheap Linux runners.

Full disclosure: the main benchmark app is mine, built in React Native to be hard to test (endless animations, late popups, loading overlays, lists that load as you scroll). The flows, per-flow results and scripts to rerun everything are in the repo, and I'd love to see numbers on other apps.

Why it's fast

• It waits for the app, not the clock. A small on-device agent knows when the app has actually settled (accessibility events on Android, XCTest's idle state checked against the screen on iOS), so each step starts the moment the app is ready. No sleeps, no screenshot diffing.
• Reading the screen is cheap. The agent reads the UI tree in about 10 ms on Android and talks to the host over a compact binary protocol.
• Screens that never stop moving don't block it. Spinners, tickers and carousels are left out of the "is it done?" check.
• Nothing to warm up. One native binary, no JVM. The iOS agent stays running between runs, so later runs start in about 0.2 s.

It's also less flaky: it won't tap a popup that's still sliding in or a button under a loading overlay, and it scrolls an element out from under a sticky footer or the keyboard before tapping it.

It works with AI agents too

speedrun mcp exposes it as an MCP server (Claude Code, Cursor, etc.). Your agent can explore the app on its own: tap around, read each screen in a few lines (cheap on tokens, not a whole accessibility tree), figure out how things work, then save the steps that worked as a YAML flow you can drop into CI.

claude mcp add speedrun -- ~/.speedrun/speedrun mcp

Limitations (so you don't have to find them)

• Android emulators and devices, iOS **simulators** only (no real iOS devices yet)
• macOS (Apple silicon); the Linux x86_64 build is Android-only
• Maestro's AI commands (`assertWithAI` and co.) aren't supported; the few other differences are documented
• It's young (v0.1.10) and moving fast

Try it

Repo, docs and benchmark details: https://github.com/hubastard/speedrun

If you have a Maestro suite, I'd really like to hear how it does on yours, especially where it breaks or is slower. Happy to answer questions about how it works.

edit1: added maestro-runner to the benchmark.
edit2: added ai agent benchmark.

I've been working on it for a few months now.

GitHub: https://github.com/justdeko/kuiver

As you've seen from this little showcase, nodes and edges are composables, there's built-in layout algorithms, zoom/pan, selection and drag, animated relayouts, and so on.

Recently promoted it to beta since I'm slowing down the pace a bit and there's not many additional large-scale changes I see for the future. Doesn't use any additional dependencies other than some core compose libraries.

Feedback on the library is super welcome! And ofc if you have any questions, you can also ask them here

Google almost gave up on this one, so i decided to build it myself
What works:-

1. IDE and compiler, solved all performance issues with coding and compiling
2. XML previews
3. Jetpack Compose Previews (Had to build the xml and compose viewing library from scratch to support arm64, google did not have that.)

What isn't supported yet:-

1. Android Emulator, you will need a physical device to test.

Known issues:-

1. Gradle project is imported every time you open it in android studio (Fixed, thanks for the comments)

Download link: https://github.com/DevanshSampat/android-studio-arm64-releases

All repositories required for building Android Studio are on my github: https://github.com/DevanshSampat?tab=repositories&q=android-studio&type=&language=&sort=

Enjoy Devs ;)

I just went through one of the most unnecessarily stressful 24 hours of my developer life, and I need to rant about how Google treats its developers.

Because my app generates revenue, Play Console recently went through a routine check regarding merchant payment verification. Fine, I updated everything immediately and submitted it.

But right after, a massive, scary red banner slammed across my dashboard saying:
"Your developer profile will be removed, and all your apps will be removed from Google Play on November 23, 2026."

Underneath that terrifying headline, in much smaller text, it says: "Google couldn't verify your merchant payment method." And deep down in the microcopy, it basically implies that this warning stays active even while your newly submitted info is under review.

Are you kidding me, Google?

I am a partner introducing revenue to your platform, complying with your rules, and your automated system decides to hold a metaphorical gun to my head with a countdown timer to wipe out my entire business, just because your team takes a day to press a review button?

Mixing up "Routine Administrative Review" and "Severe Violation Punishment" into the exact same panic-inducing UI element is peak lazy engineering and toxic UX. For an entire day, I had to stare at a countdown to my apps being deleted, wondering if an automated glitch would destroy years of my hard work.

The verification finally cleared today (it only took about a day) and the warning went away, but the psychological toll and unnecessary anxiety were completely uncalled for.

Has anyone else been absolutely jump-scared by this specific red banner? Google seriously needs to fix their Developer Experience (DX). This is not how you treat people who build your ecosystem.

I've been building an app that needs to know how many seconds a handful of specific apps were actually on screen. User grants Usage Access, I read queryEvents(), filter to those packages, done. Or so I thought.

The naive version (sum RESUMED -> PAUSED per package) worked on the apps I tried first and then fell apart once other people's apps got involved. Writing down what I found, because I couldn't find most of it anywhere.

First bug: the counter would just stop a few seconds after opening certain apps, while I was still in them. Those apps had a splash activity. The order was splash RESUMED, main RESUMED, and then a late STOPPED for the splash, which my per-package "open" flag happily read as "app left". What fixed it was tracking the set of resumed activity classes per package, and only treating the package as gone when that set is empty:

private class Fg {
    private val resumed = HashSet<String>()
    private var since: Long? = null
    var total = 0L

    fun on(e: UsageEvents.Event) {
        val cls = "${e.packageName}/${e.className}"
        when (e.eventType) {
            ACTIVITY_RESUMED -> {
                if (resumed.isEmpty()) since = e.timeStamp
                resumed += cls
            }
            ACTIVITY_PAUSED, ACTIVITY_STOPPED -> {
                // an activity always pauses before it stops, so a STOPPED for a class
                // that is still "resumed" belongs to an older instance of that class
                if (e.eventType == ACTIVITY_STOPPED && cls in resumed) return
                if (resumed.remove(cls) && resumed.isEmpty()) {
                    total += e.timeStamp - since!!
                    since = null
                }
            }
        }
    }
}

The STOPPED check in there came later. An activity always pauses before it stops, so if a STOPPED shows up for a class that's still in the resumed set, it's from an older instance. I hit that with two web apps back to back, both running in Chrome's CustomTabActivity, and the old one's STOPPED was cutting off the new one.

TWAs were the real headache. On Oct 12 I got support reports about three different apps, all TWAs, all saying the same thing: the counter doesn't move. Turns out a TWA shows its own LauncherActivity for less than a second and then hands off to the browser's CustomTabActivity, and from that point UsageStats books the time under com.android.chrome (or Samsung Internet, Edge, whatever the user has). The app itself gets basically 0 seconds. The events do have a task root package, but the getter is hidden, so no luck there.

What I ended up doing: if a browser activity resumes within 5 seconds of the target app's own activity, I treat that browser activity class as belonging to the target, and keep counting it on later resumes as long as the target is still the last non-browser app in front (so coming back from recents still works). If the user opens Chrome on their own, or some other app opens a custom tab, it doesn't count. To know what counts as a browser I query ACTION_VIEW on an https URL with BROWSABLE, plus the CustomTabsService intent, plus a hardcoded list of the usual suspects, because package visibility sometimes just gives you nothing.

Then warm starts. If the TWA's task is still alive and you launch it again, you get zero events from its package. Only the custom tab comes back. Since my app is the one doing the launching, I log launches myself (time + package) and treat each one as a fake "target came to front" while scanning.

Smaller stuff, in case it saves someone an hour:

• Usage Access isn't a runtime permission, you check it through AppOpsManager (unsafeCheckOpNoThrow with OPSTR_GET_USAGE_STATS on 29+, checkOpNoThrow before that)
• you don't need QUERY_ALL_PACKAGES just to list launchable apps, a <queries> entry for MAIN/LAUNCHER is enough
• events survive your process being killed, so you can work the time out afterwards instead of keeping a foreground service running
• queryEvents gives you every app on the phone. I filter to the packages I care about right away and only a {package, seconds} summary ever leaves the device

The 5 second window works on everything I've tried so far (my S24+ and the phones of the people using the app) but it's obviously a heuristic. If anyone knows a supported way to get the task root, or a cleaner way to tie custom tab time back to the app that opened it, I'd really like to hear it.

n most projects I worked on, analytics was treated as a secondary part of the app. We spend a lot of time on the architecture of main parts, and almost no time on analytics.

Then business asks to track this and that. Then to add a new vendor. Then to decide which event goes where. And in the end we have one AnalyticsManager with a huge list of methods, and every layer depends on it.

I came to a simple idea: the app should not know which analytics vendors exist. Feature code only says what happened, and everything else is split into small pieces:

• Event describes what happened, in the app’s words
• Factory decides what one vendor receives for an event, or ignores it
• Tracker makes one call to one vendor SDK
• Dispatcher passes calls from the app to the vendors

So in a ViewModel it looks like this:

class CheckoutViewModel(
    private val tracker: EventTrackerService,
) : ViewModel() {

    fun onTicketPurchased(fare: String, price: Double, currency: String) {
        tracker.track(TicketPurchased(fare, price, currency))
    }
}

No vendor SDKs, no god object. Each feature keeps its own factories, and DI (Koin in my example) collects them from all modules. Adding a vendor means writing its factories, and removing one means deleting them.

I wrote a full article about it with code for every piece, published in ProAndroidDev:
https://proandroiddev.com/app-architecture-analytics-ec3471ca619b

I also built an open-source library around this idea, Herald, if you want to see it in practice:
https://mkhytarmkhoian.github.io/herald-docs/

Curious how you handle analytics in your projects. Do you have one manager, a wrapper per vendor, or something else?

The last one was in July, and it was announced that the next one would be in October. Either I missed it, or it did not happen.

A few years ago my developer account got closed due to inactivity. I want to create a new use, preferably with my existing email but there seem to be no such option. In the play console, the "help" link doesn't work and any links to "contact support" also redirecct me to my developer account page, which of cause doesn't work! Anyone managed to get their account re-activated or had success with support?

I also tried with my second email but got a warning that the developer name is used ... of cause, by my inactive account

Something has been rubbing me the wrong way for a while now. I have 3 tracks for my app in Google Play, internal, open beta, production. When deploying changes we go through all 3 tracks with a single binary. I can understand the Open Beta track needing a review, but once that's approved why do I need yet another review to promote that binary to Production? I honestly wouldn't care if the review times were manageable, but I've had multiple reviews take over 2 weeks. When they are reviewing the binary are they expecting different results? Notes about the app that might be affecting the review timelines; it has Android Auto capabilities as well as a Wear OS version.

TLDR; Why do we need multiple reviews on the same binary when promoting between release tracks?

Specifically as an Android developer? I spoke to my mentor about being interested in android development, and he said he thinks I would only enjoy it only if I went to a Big Tech company because it would provide more challenge and chance for cross team collaboration which I enjoy.

It made me want to hear about people's experience working in Big Tech vs smaller or non-tech companies as an Android dev. Which do you prefer?

I'm building an Android app that uses AccessibilityService to keep people on a lock screen during a time window they chose themselves.

I have read Google's Accessibility policy. It says the API can't be used to stop users from disabling or uninstalling an app. I also read over 200 user reviews of an existing app on Play with a strict lock. It's official way out of a session is a paid in-app exit. The reviews suggest a lock only works if it's hard to escape, so I'd prefer no early exit.

My question: does play allow a lock with no in-app exit when the person chose the window themselves? I want to stay within the policy. Has anyone shipped one, or been rejected for one?

I just thought I would post how my play store submission is going, since I am always looking for info and want to help people out that are looking for answers. App store submissions are much more work that I thought.

I just had my iOS app approved last week. Now android. I submitted on Saturday.

It was WAY faster than I expected. Review came back rejected yesterday, Monday morning (India time). Then I resubmitted yesterday too.

Now this morning, already got rejected again. They are WAY faster than Apple, at least for me. But I also realized they are actually testing way more thoroughly than Apple did. I am getting my second fixed submission back now. I will update this post if they review it again right away tonight (India employees seem to do it at 3-4am EST, which is day in India obviously).

It seems the only issues they have are with my Google API scopes I use for some imports from health, sleep, etc... I did get it all approved in the Auth Center, but I guess they dive deep into those in review. It seems they all are okay, I just have to show them proof. No issues with my actual app though and they actually signed-in and used it.

Hopefully this helps someone! There is light at the end of the tunnel. Google seems faster than Apple right now, not sure why.

It's an open source app that cleans up your Android TV, turns off ads, trackers and bloat in a few taps. Side load apps your TV's store doesn't carry, send files from your phone, and see which apps use data and where they connect.

It's all Kotlin, UI in Jetpack Compose with Material 3 Expressive. A few bits devs might find useful:

- a remote with no lag: the usual `input keyevent` starts a new process for every key press, which is slow. Tellyscope starts one small helper on the TV and keeps it running, so key presses land instantly

- real app names and icons: ADB normally only gives you package names, so a second small helper reads them on the TV and is removed right after

- the ADB client runs entirely on the phone (pure Kotlin on Kadb), including Android 11+ wireless pairing and mDNS discovery. Every reopen of the TV's pairing dialog picks a new port, so it browses mDNS fresh each time instead of trusting the last one

- under 3 MB: most of the crypto library Kadb depends on gets trimmed, keeping only the handful of pieces it actually uses. That alone saved ~700 KB

Happy to answer questions on any of it. It's Free, GPL-3.0, no ads, no tracking, no account. It makes two internet requests: the cleanyourtv debloat lists from GitHub, and an update check you can turn off.

GitHub (APK + source): https://github.com/man15h/tellyscope

Disclosure: Most of the code is written by Claude Opus 5.5 + Fable 5, and I direct the work. what gets built, how it should behave, and what's safe to touch. It's not prompt and ship. Every change goes through a pull request that gets reviewed before I merge it, and CI runs the build, unit tests and lint. Risky features get e2e tests on an Android TV emulator first. The safety rules are hard coded rather than left to the AI and I've created and maintained open source projects since before the AI era. It's GPL-3.0, so you can read all of it on GitHub

I'm building an app using Supabase Auth, and my email verification emails are landing in users' spam folders.

For those who've dealt with this, what worked for you? Would only configuring SPF, DKIM, and DMARC solve the issue?

Any practical advice from developers who've fixed this would be greatly appreciated!

I'm looking to modernize my Android CI/CD setup to make it as AI-friendly and low-maintenance as possible for our company's daily workflow with coding agents.

I’m considering Dagger.io, do any guys has actually run Android builds through Dagger and how does it feel, or is there a better tool I should look into instead?