This is where the idea for Compose Bridge came from. It's an open-source plugin, now officially available on the GitBrains store, designed to radically accelerate the interface building and modification cycle.

The tool allows you to connect your app running directly on your device or emulator to the Android Studio environment, enabling you to modify design elements, color schemes, and dimensions in real time from your phone's screen. Its key feature lies in its code rewriting process. The plugin surgically rewrites and modifies the source code within Kotlin files with precision and security, allowing you to review differences and revert to the previous version with a single click.

The tool also provides an integrated model context protocol server, enabling AI tools and agents to inspect the live interface tree and provide accurate and responsive solutions that are compatible with your actual screen.

The project is available for everyone to use, contribute to and develop via GitHub and the GitBrains Add-ons Store. I would be very happy for you to try it out and share your feedback and opinions to further develop the experience.

Hi everyone! I’m currently working on porting the Flash game Armor Mayhem (.swf) to Android.

My previous background is in web development and building test apps in Expo (React Native). That’s why I initially chose the WebView + Ruffle approach, thinking a web-based environment would feel more familiar. However, I’ve hit a critical performance wall.

Build Status & Architecture:

• Current Route: Native Android Studio (WebView) + Ruffle (WebAssembly player).
• Configuration: hardwareAccelerated="true" + LAYER_TYPE_HARDWARE on GPU. Served locally via WebViewAssetLoader.
• Previous Optimization: I mitigated initial CPU overheating by implementing throttling (requestAnimationFrame) on the touch joysticks (NippleJS), which prevented the touch event flood from maxing out the CPU.

High Priority Issues (Performance & Playability):

• Menus: Runs smooth at 60 FPS.
• Transitions / Map Loading: Freezes and drops drastically to 1 – 5 FPS.
• In-combat (Gameplay): Stabilizes at only 9 – 12 FPS (handling real-time AS3 physics, AI, and vector rendering), causing progressive thermal throttling.
• Secondary Symptom: Due to low frame rates, virtual joysticks experience input delay or occasional missed touches.

Test Device Specs:

• Device: Infinix Hot 30i (Unisoc T606 / Mali-G57 GPU / Android 11 API 31).

Questions for the community:

1. Is this low FPS a hard CPU bottleneck for heavy AS3 games running Ruffle inside a mobile WebView on entry-level chips, or is there any extra WebAssembly flag/config (e.g., multithreading/SharedArrayBuffer) to better utilize CPU cores?
2. Coming from a web/Expo background, if I decide to pivot to Adobe AIR (Harman SDK) to get a native ARM .apk running at a stable 30–60 FPS, how steep is the learning curve for packaging?

Thanks in advance for any tips, insights, or advice!

Android Recovery currently uses Minui, which directly manipulates the framebuffer: Minui source code.

This project aims to use Minui as a backend for the Compose Runtime, enabling the development of UIs for Android Recovery, battery charging screens, and other system-level interfaces that operate completely independently of the Android Framework.

The Play Console is flagging my app with the DEX code optimization warning (requiring R8 shrinkage and obfuscation on release builds).

Here's the catch-22: Whenever I enable R8 for a release build, the app runs completely fine locally across my physical and virtual test devices. However, as soon as I submit it to Play Console (even on Closed Testing), the automated review bot rejects it for "Unresponsive app / Broken Functionality."

• Telemetry Gap - Neither Android Vital nor Firebase Crashlytics records any crash or ANR during the review window.
• Support Wall - Support refuses to provide stack traces, logcat dumps, or even clarify which version code failed.

Disabling R8 entirely and resubmitting allowed the app to pass review, proving R8 is triggering something specific on Google's automated test harness.

My app is an edge AI tool with a large local model footprint (2 GB). I suspect the R8 build might be breaking reflection in a background dependency or causing a thread lock or startup delay on their test labs that triggers an ANR.

Questions for the community:

• Has anyone successfully debugged an R8-only rejection when Play Console refuses to provide logs?
• How can I simulate the exact environment Google's automated review bots use during pre-launch?

Hey everyone,

I'm facing a massive issue with my dad’s old Google Play developer account and want to see if anyone here has gone through something similar.

Back around 2010, my dad had a freelancer build three Android apps that ended up getting 23 million downloads combined (the biggest one has 21M and 80k+ reviews). The last time they were updated was in 2015.

Recently, the apps got delisted because we didn't pass the new legacy account KYC yet (working on fixing that right now). But the real disaster is that the original developer lost the keystore file years ago. Because the apps are so old, they were never enrolled in Google Play App Signing.

I’m a developer myself now, and I want to completely rebuild his apps from scratch under the same package names, modernize them, etc.

Has anyone here ever lost an old legacy key on an account with millions of downloads? Were you able to get a human from Google support to manually enable Play App Signing for you, or is it completely hopeless and we have to start from zero with a new Package Name?

Would love to hear any stories or experiences.

Thanks!

recently launched my first Android app on the Play Store.

Before publishing, I tested the APK multiple times. Google Sign-In worked perfectly. Everything looked good, so I pushed it to production.

Downloaded the app from the Play Store and tried logging in.

“Google sign in cancelled.”

Tried again. Same thing.

Meanwhile, the APK installed directly on my phone still worked perfectly.

I spent way too much time wondering how the same app could work when sideloaded but break when installed from Google Play.

Turns out, they weren’t technically signed with the same certificate.

Google Play App Signing was signing the distributed version with its own app signing certificate, while the SHA-1 fingerprint I had configured in Google Cloud Console was from my local/upload keystore.
So Google OAuth basically saw the Play Store version as a different client and rejected it.

Added the Play App Signing SHA-1 to the OAuth configuration, and suddenly everything worked.

First app launch lesson learned: if Google Sign-In works in your local APK but mysteriously dies after downloading from the Play Store, check the SHA-1 fingerprints before questioning your entire codebase.

Would’ve saved me a few hours of thinking I had somehow broken authentication by publishing the app.

Anyway, the app itself is a job-focused community platform with skill-based communities and a karma system similar to Reddit. Basically, I wanted to combine job hunting with the community aspect that most job platforms are missing.
I’ll drop the Play Store link in the comments for anyone curious. Would love to hear your feedback.

Can anyone know me right way of publishing android apps using fastlane or any other tool you use?

We use Fully Kiosk app on an Android Tablet (Lenovo) and we have an issue where text on our website is auto corrected to something completely different to what is on the website.

When we test it on Chrome on the same tablet, it does not happen. It seems to be specific to the Fully Kiosk app. When asking their support they say that Fully Kiosk uses Android Webview provided by the device and it’s most likely caused by it. Does anyone has any experience with similar issue and how to update/stop Webview from doing the auto correct?

Is there a setting to prevent that?

Hi, I’ve been working on an app that has one main Activity and uses other Composables as screens.

I need to prevent screenshots and ensure that the app content is hidden or replaced with a black screen when it appears in the Recent Apps thumbnails or task switcher.

1. "FLAG_SECURE"

"FLAG_SECURE" helps prevent screenshots and screen recordings, but it doesn't seem to solve the issue with Recent Apps thumbnails on all Android versions.

1. Android 13 (API 33) and above

I was able to make the Recent Apps thumbnails display a black screen on devices running API 33 and above by using "setRecentsScreenshotEnabled()" and "Activity.setTaskDescription()", with the background color set to black.

1. Android versions below API 33

However, on devices running Android versions below API 33, the Recent Apps thumbnails still appear white or black instead of consistently displaying a black screen.

Is there any way to reliably display a black screen in both Recent Apps thumbnails and screen recordings across Android versions, including those below API 33?

TL;DR: Minicraft is a free, open-source Android app that runs a Minecraft Java

Edition server on the phone itself. No root, no Termux, no PC. Vanilla or Fabric,

Modrinth/local mods, worlds, live console, resource monitor, and an optional

playit.gg tunnel. Android 8+, arm64 only.

I've vibe coded it. I wanted a real Java server on a spare phone without leaving

a PC on all day, so I built this.

What it does

- Installs and runs the official Minecraft Java server (Vanilla or Fabric).

- Downloads a bionic OpenJDK 21 runtime on first launch (~250 MB) and provisions

the server.

- Fabric mods: search Modrinth or import local .jar files.

- Import, export and delete worlds.

- Live console with quick commands.

- CPU/RAM/temperature monitor.

- Foreground service + wake lock, so it keeps running with the screen off.

- Optional playit.gg tunnel for friends, or LAN-only mode.

- JVM heap, thread count, port, view/sim distance and a server.properties editor.

Requirements and caveats

- Android 8.0+ and an arm64-v8a phone. No 32-bit, x86 or emulators.

- No root. First setup needs internet and ~250 MB free for the JRE, plus the

server and world files.

- A recent phone is recommended: Vanilla uses ~1 GB heap by default; Fabric with

mods needs more.

- 1.21.1 is the verified version. The app also lists 1.21, 1.20.6 and 1.20.5, but

1.20.5 is known not to start right now. Forge/NeoForge are not supported.

- It is still a phone: expect lower TPS with many players/mods and thermal

throttling on long sessions. Keep it charging.

- playit.gg exposes the server to the internet. Use whitelist/online-mode and

don't post the tunnel address publicly.

- Swiping the app from Recents stops the server on purpose; if Android kills it

in the background, the foreground service tries to recover it.

Tested on a Snapdragon 870 and a Snapdragon 8 Elite. Both were usable. I'd like

more data from other devices.

Links

- Source: https://github.com/leonaryto/MiniCraft

- Latest APK: https://github.com/leonaryto/MiniCraft/releases/latest

- GPL-3.0-or-later. Not affiliated with Mojang or Microsoft; you need to own

Minecraft Java Edition and accept the EULA.

If you try it, tell me your device, Android version, server type/version, RAM,

TPS and thermals. Bug reports and PRs are welcome.

Implement the brand new API which allows your Android apps to behave just like an on-device MCP server.

Your apps and AI have been side by side on your device for a while. It’s time to introduce them!

I created some that should be helpful for Android and made this demo with them.

I'm interested in hearing other ideas.

Hey everyone! I'm Adel, Co-Founder and COO of VAZA, a Toronto-based consumer technology startup. We're looking for a talented Full Stack Mobile Software Engineer to join our growing engineering team and help us build and scale our native iOS and Android apps.

A little about VAZA:

We're building the world's first monetized opinion market, turning debates across sports, music, entertainment, anime and culture into interactive, community-driven markets.

Users can vote for free or back their opinions with money, with outcomes determined through community consensus.

Since launching, we've grown to 450,000+ registered users worldwide, driven primarily by organic social media and creator partnerships.

We're now focused on building a world-class mobile experience and expanding our engineering team.

What you'll be working on:

• Building and shipping features across our native iOS and Android applications.
• Creating polished, animation-rich interfaces and real-time experiences.
• Working on core product features, including matchups, voting, profiles, gamification and payments.
• Owning mobile testing, performance improvements and App Store / Play Store releases.
• Collaborating with our backend, infrastructure and data teams.
• Working directly with our founders and technical leadership on product decisions and the roadmap.

Our tech stack:

• iOS: Swift 6, SwiftUI, async/await.
• Android: Kotlin, Jetpack Compose, coroutines & Flow.
• Backend: Rust, Axum, PostgreSQL, REST APIs and WebSockets.
• Infrastructure: AWS, Docker, Terraform and GitHub Actions.

Who we're looking for:

Ideally, someone who has experience shipping native mobile applications, is strong in Swift/SwiftUI or Kotlin/Compose, and is comfortable working across both platforms.

We're especially interested in engineers who have a strong product mindset, care about great UX, take ownership and enjoy building things from the ground up.

Experience with consumer apps, gaming, social platforms, fintech or real-time systems is a plus.

Rust experience is great, but not required.

Why join us?

We're still at an early stage, but already have a substantial global user base. You'll have meaningful ownership over the mobile product and the opportunity to build features that can reach hundreds of thousands of users.

We're a small, ambitious team with big plans, and we're looking for engineers who want to grow with the company rather than simply complete assigned tickets.

Role details:

• Location: Toronto / GTA (Hybrid).
• Type: Full-time, 40 hours per week.
• Compensation: Competitive salary + performance-based bonuses.

Interested?

Feel free to DM me directly or email me at [adel@vazainc.com](mailto:adel@vazainc.com) with your LinkedIn and résumé. I'd love to hear about your experience and what you personally worked on.

You can also check us out at https://vaza.vote or @vazainc across socials.

Happy to answer any questions!

Did anyone else get the new google play console? Is there any way to switch back to the old design?

They removed "pin app", added only sort modes "recently updated" and "recently viewed", how about giving me a way to custom sort? Or sort by stats?

The filters are basically useless:

• "Production": All apps
• "Policy tasks": Always showing issues from decade old abandoned apps.
• "Publishing submissions": Always showing submissions stuck in decade old abandoned apps.

There is no way to hide or filter abandoned apps. This feels designed by someone that just added a few apps and thought "this looks fine", completely ignoring that any real developer account will collect abandoned apps over the years.

I'm not going to update a 10 year old app to API37 which will break it's functionality. Let apps age gracefully and die in peace.

This new console will permanently show "X policy issues" on the dashboard, likely causing me to overlook an actual issue with an app...

Our app was on a personal account, stuck behind the closed testing requirement. Common advice: "transfer it to an org account, those are exempt." We did. The requirement stays with the app, not the account.

What worked: creating a new app (new package name) directly in the org account. No testing gate, straight to production review.

Cost: new package, so users must reinstall and you lose reviews/installs.

Either do the 14 days or start the app on an org account from day one. Don't bother transferring.

I use an old phone Android 10 with 3GB RAM I was under the impression that setting the background process limit to 1 or 2 will speed the phone up is this really true or is it just a myth and what does it actually do

I have optimised the phone to the best of my knowledge but I dont understand this setting fully for example I use a VPN with kill switch and Gboard these 2 are always running in 'running services' no matter what so if I select 1 limit does it really affects Gboard or the VPN or slow my phone down and apps

I have noticed whenever I set it to 1 apps/system apps in 'cache' (in running services) are not activate as much but if I bump it up to 4 or standard they're all active so I assume leaving it on 4 or standard let's random apps take up RAM

So I needed to remove permissions from one app and release new app.

Update app: permission removal was the most painful thing, because of my silliness, I kind of forgot publishing channels, because I came from time where there was no internal, beta, etc. and permissions must be removed in ALL channels (I had open beta), there is like small mention somewhere. It would be nice if review process specifically said - you have release in beta channel that must be updated or so.

New app: new app occurred with the new console UI and filling out declaration is ultra annoying because it is not progressing like before, it goes after each piece to app landing and I could not find where things are. Otherwise review process was ultra fast and app online very soon.

I created 2 ticket for update thing which were unnecessary, it is that I release with years pauses and it is not clear when there is issue exact place where issue occurs and where specifically correction must be done. Google can save a lot of time for themselves in the make more precise messages.

But in the end ok-ish.

i'm a student at university and teacher asked us to prepare our laptops for next lesson and i need to setup my vs code to be able to develop android on it and i don't know how to start or what to do
im running on arch linux since i want to learn that too
thank you all for ur hrlp

I've been building WormaCeptor for a while. It's an open source debug toolkit that lives inside your debug build: network inspector for OkHttp and Ktor, crash log, logcat viewer, database and SharedPreferences browser, file browser, WebSocket monitor, CPU/memory/FPS overlay, GPS mocking, push simulator and more. It's all debugImplementation, so none of it ends up in your release APK.

Lately most of my debugging happens with an agent in the terminal, and the annoying part was always the same: the agent can read my code but not my app. So I added an MCP server to WormaCeptor. The agent talks to the running app over adb and sees the same data the in-app screens show.

What it can do:

• list requests, read full request and response bodies, replay one or export it as curl
• create a mock rule from a real response, then edit it to test the error case
• read crashes with stack traces, tail logcat, list leaks and StrictMode violations
• run SELECT queries on your Room/SQLite databases, read prefs and app files
• wait for a specific request or crash while you tap through the app
• check CPU, memory and FPS, fake a GPS location, send a test push

What changed for me is that I stopped being the middleman. I used to copy a response body, then the stack trace, then a DB row into the chat, and the agent only knew what I remembered to paste. Now it goes and looks, and after a fix it checks the app again instead of telling me it should work. The database and prefs are read-only for the agent, and tokens, cookies and auth headers come back as [REDACTED] by default.

The clip demonstrates the flow: checkout fails, Claude Code finds the failed POST, reads the 422 body, sees the currency field is wrong and fixes the code.

How to use it:

1. Add it next to your existing WormaCeptor dependencies: debugImplementation("com.azikar24.wormaceptor:wormaceptor-mcp-server:3.4.2")
2. Register it with your agent (Claude Code below, any MCP client works): claude mcp add --transport stdio wormaceptor -- npx -y wormaceptor-mcp
3. Run the app on a device or emulator, keep it in the foreground, and ask "why did the last request fail?"

The server only listens on 127.0.0.1 on the device. Auth is off by default, which is fine for your own emulator; turn it on for shared devices (one config flag, covered in the docs).

Repo: https://github.com/wormaceptor/WormaCeptor

Curious what you'd want an agent to see in your app that it can't today.

Hey folks, looking for some advice regarding app review on Google Play. I published my first app about 6 weeks ago. Had one rejection to deal with, but no big. Since then, I have submitted updates twice. They seemingly go through in very little time, which is awesome compared to the lengthy review times on the Apple side of the fence.

BUT...

I noticed on my 1.1 review that very shortly after submission, I got 4 user accounts created in quick succession via Sign in with Google. The user data came in with a first and last name, and the email address was formatted like `firsttlast.8675309@gmail.com`. I thought to myself, that's kind of annoying that they are spamming new accounts when I gave them test credentials to use, but not the biggest annoyance ever.

Then, last night, I submitted version 1.2. About half an hour later, my husband shows me his phone, and he got a "friend request" from a user that looked spammy as hell...

The user had listed themselves as 1205555 cm tall and weighing 85135 lbs. This profile had also updated their profile name to be `test_credentials@my_app.com`. So obviously google is using AI to run their app review, which at face value, I don't have a problem with. HOWEVER, I find it absolutely unacceptable that they are running these bots to perform real user interactions on the app that affect other human user's accounts.

So, the question is how do I stop this? I've seen other threads advising to re-route logins to a different server based on the provided test credentials, but Google is creating new accounts for their testing, so its not something that can be predicted.

The cherry on top is that there is no way to get in contact with the team responsible for this, so I'm feeling really in the dark here. Hoping one of you will be able to point me in the right direction.

These Google Play reviewers are driving me nuts. I keep submitting builds for review, they keep rejecting them saying that they can't get past the splash screen.

Thing is, I can't repro what they are saying. App works fine on multiple different AAOS emulators and runs fine on actual running AAOS head units in a vehicle. They keep providing these inane messages of "For example, the content of the application is not able to load" which is totally unhelpful.

Are these guys running an environment that isn't consistent with Android Studio or actual devices?

Help needed please.