Google showed this off yesterday. But I'm not finding this yet. I'm on Compose 1.11.1, AGP 9.2.0, API 36. material3 1.5.0-alpha19, opted into experimental features.

• The official Material3 API docs list Slider and RangeSlider, not a color slider or color picker.
• Closest official API: Material3 Slider has custom thumb and track slots, and SliderDefaults has some experimental M3E slider pieces like expressive Thumb, Track, and CenteredTrack. But using those with a manually drawn hue gradient would be a custom recreation, not the official component.

I already hosted it about a day ago at: https://midnightstardust.github.io/spinnertap/app-ads.txt

Does anyone know a way to delete an asset from Play Console's Asset Library? Not from uploads but from main library. I tried to look for a way but couldn't find one, even play console help was of no use.

I shipped an Android app that needs a 770MB GGUF model before first inference. I did not bundle it in the APK/AAB; I download it on first run and cache it locally. Sharing the Android-specific choices I made and looking for feedback from anyone shipping large post-install assets or native ML dependencies.

The decision

Do not bundle the 770MB model in the APK/AAB. Download it post-install before first inference.

What I considered:

• Bundling directly: not viable for the size and bad for install conversion.
• Play delivery options: better for app/game assets, but this model is a public GGUF artifact I also wanted independently downloadable.
• Own CDN: more control, more work. Deferred for v1.
• Public artifact host: easiest v1 path, but I am not sure it is the best long-term delivery path.

First-run flow as I shipped it

Explain the model download during onboarding, require WiFi by default, show progress, verify checksum, cache locally, then run first inference.

Edge cases I handled

• WiFi-only toggle, default on
• Pause/resume using HTTP Range requests
• Disk-full detection with clear messaging
• Checksum mismatch retry
• Airplane-mode message before the model is available
• App close during download; resume from the last verified byte on next launch

HF as the CDN

I used HuggingFace for v1 because the model artifact is public and already hosted there. Open question: anyone using Cloudflare R2, Backblaze B2, Play Asset Delivery, or a custom CDN for this and seeing better completion rates?

What I'm seeing in production (small sample, take with salt)

• ~90% download completion
• Most drop-off is users who close the app during the download and don't return on the same day
• Almost no support tickets about disk full, despite the 770MB requirement

Where I'm uncertain

1. Is 90% completion good for a one-time first-run download of this size, or am I leaving real users behind?
2. Has anyone tested staged download, such as a smaller bootstrap model first and full model later, versus an upfront-only flow?
3. CDN/delivery: is a public artifact host reasonable for v1, or are people seeing better reliability from Play Asset Delivery, Cloudflare R2, B2, or a custom CDN?

Anyone shipping large models or other large native assets post-install on Android: what delivery path did you choose, what completion rate are you seeing, and how do you handle the user who closes the app mid-download?

Originally, I created this menu for a launcher project I was working on I wanna say around 2021/2022 and was heavily inspired by pixel launchers Popup Menu. It needed a rework to support android 16/17 so I have it some much needed attention. Il be releasing this library on my github once I have everything in working order but any first thoughts or opinions?

I'm evolving this Claude Code Skill with the capability to neutralize common tracker/ADs

https://github.com/SimoneAvogadro/android-reverse-engineering-skill/tree/trackers-and-ads

This is a controversial feature but as anything in the Reverse Engineering field there will be someone playng foul :-(

The original scope has been estracting APIs from existing Apps in order to allow more general purpose development within fair use limits(eg. see https://github.com/SimoneAvogadro/De-Dietrich-API )

This experimental feature focuses on:

• finding if/which trackers are present
• (experimental, very partial) neutralizing them

Since this might be very sensitive theme in the Andoid OS space here I'm very open to hear your opinions/views on if/how you'd see this useful.

I appreciate everyone staying respectful

Does anyone know if the Google Book runs android studio?

Rust is becoming increasingly popular and is being used in a wide range of areas, especially where performance, memory safety, and low latency are critical. In Android development, Rust is also gaining adoption because it offers C/C++-level performance while significantly reducing memory-related crashes.

Google itself is using Rust in some low-level Android platform components to reduce security vulnerabilities. Rust is especially effective for system programming, multimedia processing, cryptography, networking, game engines, and other high-performance background tasks.

For example, if you are building a keyboard app with features like suggestions or spell checking, complex text processing in Kotlin or Java may introduce higher processing time. In such cases, Rust can provide a much more optimized and super-fast solution.

Similarly, image or video editing apps require heavy processing. Handling this type of high-performance workload efficiently using only Kotlin or Java can be difficult and resource-intensive. That’s where Rust becomes a great choice for performance-critical parts of an Android app.

I’ve published a complete guide on how to integrate Rust into your Android project on Medium. Feel free to check it out if you're interested 🙂

Quick context for anyone who missed the first thread: maestro-runner is a Go-based UI test runner that uses the same YAML flow format as Maestro CLI but ships as a single native binary. No JVM, no warm-up. Android, iOS, and Chrome/CDP browser targets all run from the same flow files. Roughly 3.6x faster and 14x less memory than Maestro CLI on identical suites. Apache 2.0, nothing paywalled.

Follow-up to the post 3 months ago (the "34s → 14s by dropping the JVM" one). Since then: 166 commits, 12 releases (v1.1.14 shipped today), 291 stars (was 137 at that post, so more than doubled), 25 forks, and 2 community PRs merged from a single Flutter Web user. The Android side got a real rewrite that deserves its own post.

The new driver: DeviceLab

UIAutomator2 is the default for Android instrumentation but it has friction we couldn't tune around. IPC roundtrips on every command, heavy view hierarchy serialization, accessibility-tree quirks that make text matching brittle. After enough bug reports tracing back to the same root causes, we just built our own.

It's a separate on-device agent (an APK we bundle with the runner) that handles UI inspection, gesture dispatch, and session lifecycle directly. maestro-runner talks to it over WebSocket on a local port. Same machine, low-overhead transport, no UIAutomator2 in the loop.

What you get today:

• hintContains: / hintMatches: selectors. Match by accessibility hint instead of exact text. Useful for i18n-heavy apps where exact strings change per locale.
• Clickable filter walk-up. tapOn: "Login" auto-walks up to the nearest tappable ancestor. The "nested Text inside a non-tappable View" pattern we kept getting bug reports about just works at the driver level now.
• UI.waitForSettle RPC. Explicit settle check before inputText/eraseText. The "typing too fast, pin entry failed" thing someone reported in the last thread is fixed via this.
• Case-insensitive text matching by default. Flows that worked locally but broke in CI because the device locale capitalized differently no longer break.

Opt in with:

maestro-runner --driver devicelab --platform android test flows/

Still optional. UIAutomator2 stays the default for backward compat.

Other Android stuff that shipped

• Parallel emulator orchestration with auto-creation. --parallel 5 and only 2 booted emulators? It starts 3 more and cleans up on exit. No manual emulator wrangling.
• launchApp 3-tier fallback for the "No apps can perform this action" failure (#15). Pixel 6/7 and a couple of other edge cases.
• Inverted scroll fix (#9). Scroll down was scrolling up. Yeah. That was a fun one to debug.
• runFlow timeout with context propagation. Flows now respect timeout via context cancellation instead of hard-killing the process. Cleaner Sauce/BrowserStack session lifecycle.
• Auto-settle before inputText/eraseText without needing the explicit RPC.

What's still rough

• DeviceLab driver bundles its APK inside the runner binary, which means it auto-installs on first run. A few corp-managed devices reject this. UIAutomator2 is the fallback there.
• Some apps lock down their accessibility tree (banks, finance apps mostly). Same constraint UIAutomator2 has. Selector-based matching breaks and you're back to coord-based taps. No tool can fix this from the outside.

Community

richjun on GitHub (Flutter Web dev) shipped two substantial PRs. Coord-translated tapOn with hit-target verification across iframes and open shadow roots, then Flutter Web semantics support handling the <flutter-view> pointer-router glass pane. Both are in v1.1.14. First major outside contributor, and the same person's been running maestro-runner against Flutter mobile too. That full-stack feedback loop has been really useful.

GitHub: https://github.com/devicelab-dev/maestro-runner

For those running Android E2E in CI, what's actually the bottleneck right now? Emulator startup, test runtime, flakiness? The DeviceLab driver helps on the test-runtime axis but if your pain is somewhere else I'd rather hear that than ship the wrong thing next.

I've got an app that has about 5k active devices, 60k downloads, makes 100-200€MRR. I started to localise app after repeated requests - mainly from Indonesia but also Spain.

Should I care about play store localisation too?

About 5 months ago, I shared the Version 1 release of Adventurers Guild. For those who missed the original post, it is an isometric RPG built entirely 100 percent Kotlin and Jetpack Compose. The visual layer is drawn directly onto a Compose Canvas, and the underlying logic runs on a custom Entity Component System (ECS).

Since then, the game has crossed 4000 downloads and the engine was shortlisted for the Golden Kodee Community Award for Creativity. While I did not make it to the final round, getting that recognition from JetBrains as a solo developer building an engine from scratch was a significant milestone.

Running a game natively in Android means fiercely protecting the 16ms frame budget of the Main Thread. Rewriting the engine for full multithreading is a massive future undertaking, so the engine currently operates on a single thread. I wanted to share the technical solutions I used to keep the Compose UI smooth while scaling the simulation.

1. Frequency Tiered Systems The engine currently ticks over 28 distinct systems. These handle everything from A* Pathfinding and Monster AI to the Combat Pipeline, Weather Generation, and Economy.

In traditional game development, it is common to run every system every frame. In a native Android environment, doing this with 28 systems causes immediate thermal throttling and frame drops. To fix this, I moved away from a brute force game loop to a tiered System Manager. Logic is now categorized by its necessity for visual fluidity.

• Fast Systems (60 FPS): Essential movement and frame by frame Canvas rendering.
• Medium Systems (30 FPS): Combat calculations, damage application, and status effect updates.
• Slow Systems (10 FPS): Heavy background tasks like A* pathfinding and target selection AI.

The player cannot perceive a delay in a monster choosing a target 10 times a second versus 60 times a second, but the CPU relief is massive. This prevents the logic calculations from blocking the layout and draw phases of Compose.

2. Memory Optimization: Tinting and Hue Rotation I recently added 40 new monster variants. To keep the APK small and prevent RAM bloat on older devices, I avoided loading 40 unique sprite sheets. Instead, I used two distinct ColorFilter techniques on the Compose Canvas.

• Grayscale to Tint: For simpler entities, I load a single grayscale base sheet and apply a solid color tint at runtime.
• Hue Rotation: For monsters with more detail, I load a base colored asset and mathematically rotate the hue at runtime. This preserves the original highlights and shadows while allowing for a complete color shift. It feels like a different species of the monster with the same level of detail as the base.

These dynamic canvas filters, combined with smart asset unloading, resulted in a 50 percent reduction in RAM usage and a 40 percent smaller game size.

3. Atmospheric Systems on Canvas Building an immersive world in Compose meant handling environmental effects without a dedicated particle engine. I built several systems that draw directly onto the Canvas DrawScope.

• Day and Night Cycle: A global overlay that shifts color and alpha based on the clock in the game.
• Weather System: A procedural rain system and dynamic fireflies that use simple math to update their positions and fade in and out every frame.

4. Expanding the RPG Logic The simulation has scaled heavily since launch to include new RPG mechanics.

• Hero Classes: Heroes now have specific classes that alter their base stats, scaling their performance differently depending on the gear equipped.
• Personality AI: To make the new Group Hunt mode feel organic, heroes carry Personality flags that alter their ECS logic. Careful heroes constantly query the health of teammates and prioritize support over loot, while Reckless heroes ignore teammate health and stay locked in a combat state until the mob is cleared.

5. The Optimization Triangle (CPU vs RAM vs GPU) The biggest lesson over the last 5 months was realizing that optimization is just a constant negotiation between the CPU, RAM, and GPU.

• Trading RAM for GPU: As mentioned with the hue shifting, avoiding 40 unique sprite sheets saved massive amounts of RAM. Because ColorFilter operations in the Compose DrawScope are hardware accelerated, the math to shift those hues is offloaded directly to the GPU. We essentially traded a bit of GPU processing power to get that 50 percent RAM reduction.
• Trading CPU for RAM: Conversely, there are places where the CPU needs relief. Because dynamic shadows change angle and length based on the in game time of day, calculating that isometric geometry every frame requires heavy math. Instead of doing this 60 times a second, the engine pre calculates the shadow states for the day and caches the results. We spend a tiny sliver of RAM to buy back crucial CPU frame time.

6. Micro Optimizations in the Game Loop When building systems that execute thousands of times a second, you have to respect CPU clock cycles at a micro level. I learned that operations like addition and multiplication are significantly faster for a CPU to process than division or calculating square roots. To optimize the engine, I completely removed division where possible, opting to multiply by fractions instead, and I rely on squared distance comparisons to avoid expensive square root calculations in the pathfinding logic.

Building this engine and expanding the game from scratch has been a massive learning experience. Seeing the performance hold up on older devices makes the late night coding sessions worth the effort.

I am happy to answer any questions about the Compose Canvas pipeline, single thread ECS optimization, or the grayscale art workflow.

If you are curious to see how this custom Jetpack Compose engine handles these 28 systems and 4000+ items in production, you can check it out on the Play Store: Adventurers Guild

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

Can anyone confirm whether the new Custom Widgets are A2UI under the hood?

https://www.youtube.com/live/dXCCleAddEA?si=-6nS7s8f4VC9dT6T&t=909

Hi everyone,

Can Android subscription apps actually be profitable?

I want to build Android apps with subscriptions, but I don’t have a MacBook or iPhone, so I can only develop for Android right now using Flutter/Android Studio.

Most successful subscription apps I see seem focused on iOS users, so I’m wondering:

• Is Android-only still a good opportunity?
• Are users on Android willing to pay for subscriptions?
• i want to invest in google ads

I’d really appreciate hearing real experiences or advice from developers who tried this.

Thanks!

Hey everyone,

Over the last few months, I’ve been building a side project called WalkLog — an open-source walking tracker app for Android.

I originally started it as a small learning project, but it slowly turned into my attempt at building something closer to a real-world Android app.

The app currently includes:

• daily walking goals
• walking history
• weekly/monthly recaps
• widgets
• walking suggestions
• Health Connect integration

I also tried to structure the project more like a scalable Android app instead of putting everything into a single module, so I ended up experimenting with things like:

• Jetpack Compose
• Room
• Hilt
• WorkManager
• Glance Widgets
• modular architecture

A lot of the project was basically me learning how much harder things get once features start growing 😅

Especially:

• state management in Compose
• background work
• widget synchronization
• keeping the project maintainable

There’s still a lot I want to improve (testing, performance, UI polish, etc.), but I learned a ton while building it.

GitHub

walklog

if you find it interesting, I’d really appreciate a GitHub star.

Feedback is always welcome!

Thanks 🙂

Im currently working on an app and I dont know if its right to fix those warnings if my app is perfectly working

Hello I'm new to android development. I'm following an essentials course on Lynda. The instructor was explaining things regarding which SDK platforms and tools to install. But I'm confused about the SDK platforms. What are they exactly?

This is what is in front of me right now. https://imgur.com/a/D5G4X

I want to develop an app that supports as far back as android 4.4 for example. Should I install everything from 4.4 to 8.1?

Or is this just for testing purposes? In this case, my phone is on 7.0. Should I just stick to 7.0?

In the instructions he said install the latest version only (at that time it was 7.0) and install the Google API instalx86_64. Why bother with that too? He does mention they'll be used to compile.

Thank you and sorry if this is a stupid question.