Yes, just to set expectations, here is an AI description of the App: The app is a probe dressed as a hello world. The Activity, written in dynamic Groovy, shows "Hello from Groovy 6.0.0-SNAPSHOT" and then one line per check from a Groovy `Probe` class, ending in PROBE OK. The checks are the same shapes as the native-image probe: closures over ranges, GStrings, operator overloading on a user class, dynamic property access, a trait, currying, closure-to-SAM coercion, `as float[]`, captured locals, metaclass and bean-property introspection, JSON round-tripping through groovy-json, regex, ranges, a switch expression, a category, closure delegation, and the null-receiver call. Three timing loops follow. A second, pure-Java activity lists which JDK classes and members exist on the device and holds the `catchException` repro. The screenshot I looked at earlier is that list on an Android 16 emulator.
So it exercises the runtime broadly, but through one small program. Would a wide range of apps work? I would split the answer in three. **What the ten changes buy.** They remove every crash the runtime hit *before user code ran*: version probing, the module walk, the hidden-class definer, type annotations, the logger, ScopedValue detection, the exception combinator, and the grooid packaging bug. With them, plus the SwitchPoint shim, the runtime initialises cleanly and the dynamic feature set in the probe works. That covers the bulk of what ordinary application code does. **What is still missing, in decreasing importance.** - SwitchPoint. The shim lives in the app, not in Groovy, so nothing works without a user adding it. That alone means "not supported" until the invalidation abstraction exists. - Performance. Dynamic calls run at tens of microseconds each because ART interprets MethodHandle chains. A UI with a few hundred dynamic calls per frame is fine, a loop over a large list is not. The tier work is what fixes that. - Runtime class generation. Anything that defines classes at run time fails on ART: scripts and `GroovyShell`, `Eval`, `as` coercion to abstract classes or maps, `ProxyGenerator`, and dynamic `@Grab`. Apps have to be fully precompiled and stick to interface coercion, which goes through `java.lang.reflect.Proxy`. - Modules using APIs Android lacks, and covariant JDK signatures such as `ByteBuffer.flip` in groovy-nio, plus anything with `java.beans.Introspector` outside the grooid rewrite. - R8. The generated keep rules work, but every library type an app dispatches to dynamically must be kept whole, and only the JSON module has been tried. **What has not been tested at all.** Real apps. The probe never touches AppCompat, view binding, lifecycle-aware components, coroutines interop, or anything involving threads, and it has not been run on a physical device or an older API level. So my honest reading is: the runtime is now *startable* on Android, which it was not a week ago, and typical dynamic Groovy code runs correctly. Calling it supported would take the SwitchPoint abstraction and the dispatch tier inside Groovy, both Groovy 7 work, and then a couple of real apps as the corpus, the way Iris and the MCP server served the native-image work. A good next probe when you want one is a small but real app, say a list view backed by groovy-json parsing a bundled file, with AppCompat, built in release mode. On Wed, Sep 9, 2026 at 5:59 PM Guillaume Laforge <[email protected]> wrote: > > Back in the day, I remember when a famous American newspaper built its mobile > app with Groovy. > One of the pain points was the slow startup time, with tasks like loading DGM > methods taking a lot of time, along with other factors I've forgotten (such > as some metaclass creations). > I'd be curious to hear if a Groovy Android app (even moreso when it's > dynamic, and not compile-static) loads snappily. > > Guillaume > > > On Wed, Sep 9, 2026 at 9:52 AM Paul King <[email protected]> wrote: >> >> Hi folks, >> >> It has been a long time since we seriously supported Android. And, the >> marketing dynamics might mean that no-one will give a Groovy solution >> in that space serious attention. But, partly due to recent work on >> other things, we can now support it again (with caveats). >> >> I have a bunch of what AI calls "small defensive patches", after >> applying them, you can build dynamic Groovy Android apps (I have one >> I'll share shortly) with a shim add-on. We can consider removing the >> shim for Groovy 7; to do that, we need an extra tier. For now, I am >> doing some PRs for the suggested patches. They are all no change >> (needs more eyes) for normal Groovy JVM usage. >> >> Just in case you are wondering where the motivation for today's PRs came >> from. >> >> Cheers, Paul. > > > > -- > Guillaume Laforge > Apache Groovy committer > Developer Advocate @ Google Cloud > > Blog: glaforge.dev > X: @glaforge > Bluesky: @glaforge.dev > Mastodon: @[email protected]
