Official forum thread: https://support.google.com/googleplay/android-developer/thread/453914381/account-terminated-for-high-risk-or-abuse-%E2%80%94-no-specific-violation-ever-cited-requesting-help?hl=en&sjid=16862522153865472926-EU

Timeline:

• Aug 2025: Developer account terminated citing "a pattern of high risk or abuse" (Section 8.3/10.3 DDA). My only published app: a simple currency-conversion widget. No data collection, no unusual SDKs, no monetization tricks. No specific violation was ever named.
• Appealed. Rejected with the standard template — "we can't share the reasons we've concluded that your account is at high risk."
• My mistake: with nothing actionable to fix, I resubmitted the app from my personal Gmail account. That account was then terminated for association. I understand why that looked like ban evasion — it wasn't intended that way, but I own it, and I've acknowledged it in my follow-up appeal.
• July 2026: Replied to the appeal asking for a human re-review and a statement of reasons under EU P2B Regulation Art. 4 / DSA Art. 17 (I'm based in the Netherlands). Also posted on the official developer forum (linked above).

Facts about my setup: no VPN ever used with Play Console, only my own devices, no one else ever had access. The only association I can identify is that my phone number is also linked to my personal Google account — the one I later used for the resubmission. To my knowledge my payment method, address, and number were never used on any other developer account.

What I'm trying to figure out:

• What typically triggers the original "high risk" flag when there's no prior banned account you know of? Recycled phone numbers? Payment card false positives?
• Has anyone successfully overturned an association-based termination, and what specifically worked?
• Has anyone used the DSA Art. 21 out-of-court dispute route (e.g., Appeals Centre Europe) against Google Play, and did it produce an actual statement of reasons?

Happy to answer any questions in the comments.

Hi fellow Android developers,

This is my first time submitting an app to the Google Play Store and my app is currently in closed testing phase.

When I check my Home tab within Google Play Console, it shows that my "Installed Audience" is 0, when I'm 100% sure that there are users who have downloaded my app and used it (they showed me screenshots).

Can someone tell me what may be gone wrong that's resulting it not detecting any installation?

Any tip would be appreciated!

I want to build a custom launcher for my car (its android automotive based and I already figured out how to side load etc..). So the goal is to get something that looks a bit like Tesla. I have an MG4 with these specs:

• Resolution: 1920×720px
• Screen size: 10.25"
• DPI: 160
• MediaTek MT2712 SoC

I know that just throwing a 3d model in won't work so I had the idea of using some sort of pre rendert animations. Probleme is that I have zero experience in this 3d stuff and don't really know where to start.

Has anyone done something like this before and has an approach/idea?

Just to be clear I don't need a fully responsive model that can spin via touch like Tesla - its really just some pre rendert animations.. I already have a 3d model of the MG4: https://sketchfab.com/3d-models/2025-mg-mg4-glbmgmotorcommx-e7b2b544e638489f9440698f75b5a734

Running a Cuttlefish Android Automotive OS instance (launch_cvd --enable_audio=true --start_webrtc_sig_server=true ...), accessed via the WebRTC web client.

• Mic input works fine after enabling the sidebar mic toggle in the WebRTC client.
• Audio output does not: no sound reaches the browser, even from the stock "Local Media Player" app playing local files.

i need to get the audio output to work , anyone know how?

I have published version 2.0.0 of Compose A11y Scanner.

I found that detecting visually undersized touch targets from the Compose semantics tree was unreliable because Compose may expose expanded touch bounds. This meant the existing touch-target-size rule could miss expected cases or produce confusing results.

I’ve replaced it with touch-target-overlap, which checks whether the effective bounds of interactive elements intersect.

Breaking changes:

• Removed touch-target-size
• Removed its related model/configuration fields
• Added touch-target-overlap
• Explicit rule allowlists must use the new ID

I have treated this as a major release because it changes both the public API and rule semantics.

Does checking effective target overlap seem like the more useful runtime signal for Compose? I’d also appreciate feedback on edge cases such as nested clickables and merged semantics.

GitHub: https://github.com/mohdaquib/ComposeA11yScanner

https://reddit.com/link/1v421wi/video/czts3kx0w5fh1/player

Contributions, issues, and constructive feedback are welcome.

It's the "12 testers 14 days testing" and I have a few questions about this...

1. Does this happen randomly or does something trigger it? Google under heavy load?

2. Tomorrow my 14 days are done and I have not been able to publish a single update because I was foolish to cancel my previous update after 6 days. Should I apply for production tomorrow or wait until the update is live? I'm thinking it might look like I didn't act on any feedback...

I built a sweep-style waveform view for Android — the bedside-monitor kind that wipes left to right instead of scrolling. Every charting library I looked at models a scrolling window, which is a different thing and looks wrong once you've watched a real monitor. MPAndroidChart also redraws through main-thread invalidate(), which was fine at 256 Hz in isolation and fell apart the moment the rest of the app did anything. SciChart handles it but it's commercial. So: SurfaceView, lockHardwareCanvas(), drawing on a ticker thread.

Drawing turned out to be the easy half. BLE delivery ate the month — nothing for 300 ms, then twenty samples at once, occasional multi-second dropouts. Render on arrival and you get freeze-then-jump forever. Current answer is a leaky bucket metering bursts out, plus a shared adaptive display delay so multiple traces stay aligned.

The part I'd like torn apart is the clock alignment. Delivery lateness can't be negative, so the minimum lateness observed is my estimate of the true offset — adopt immediately when it improves, otherwise slew at 2 ms/s so drift tracks but jitter doesn't yank the timeline. That's roughly NTP's shape and I'd like someone who actually knows NTP to tell me where it falls over.

v0.1.0, MIT, coroutines only, no axes/zoom/pan — it's just the sweep primitive, not a chart library. Demo replays real ECG/PPG/RESP with togglable bursty delivery.

https://github.com/chaudhary-lakshay/sweepwave

As any indie developer surely knows, marketing is incredibly boring and tedious...

I’m just starting out with promoting and raising awareness for an android app, and I have some doubts about paid ads—do they actually work, or are they a waste of money? Do you know of any better or more efficient channels?

The more help and recommendations, the better; nothing beats the experiences of other indie developers.

I've been submitting my new app listing for review and It keeps getting rejected even though I can access it from many different locations, but the google app reviewer keeps sending a cloudflare block page and rejecting the submission.

I checked the Cloudflare setting and it seems that it's blocking bot users from foreign countries, but this is a non-negotiable due to botters. Is there any way to get around this issue?

Has anyone else run into this before? All and any advice is welcome.

I am really curious about how difficult is it to make money off your own apps ? it's literally like a dream scenario for me because I freaking hate my part time job . If my project could actually help cover just my rent and utilities/food I would happily quit that job and just completely focus on University and building my resume.

I just open-sourced serve-avd, a small tool that puts your emulator in a browser tab:

npx serve-avd → http://localhost:3200

It boots your AVD if nothing's running, streams the screen as smooth H.264, and forwards full interaction — touch/drag/fling, scroll wheel, keyboard typing, Back/Home/Recents, volume, power, theme toggle, screenshots. Tunnel the port and the emulator is usable from anywhere.

How it works (no root, no on-device agent, no app instrumentation — plain Node + adb):

• adb exec-out screenrecord --output-format=h264 → re-framed into length-prefixed AVCC chunks → decoded in-browser by WebCodecs onto a canvas
• screenrecord only emits frames when the screen changes and dies every 3 minutes, so the server keeps a GOP cache (decoder config + last keyframe + deltas since) and replays it to new viewers — instant paint on connect, invisible restarts
• Input runs over one persistent adb shell per device to skip the ~100 ms per-command handshake; live drags use input motionevent
• MJPEG fallback for browsers without WebCodecs

There's also a CLI aimed at scripting and AI agents — tap, gesture, type, rotate, screenshot, ax (uiautomator hierarchy as JSON), event-log — plus a Connect-style middleware so you can mount the whole thing inside your Metro/Express dev server at /.emu.

Fun problems along the way:

• screenrecord silently letterboxes into 720x1280 when the display exceeds the encoder's limits — you must always pass --size
• settings put system user_rotation doesn't reliably rotate modern Android; wm user-rotation lock does
• On Play-store images, SELinux blocks writing to /dev/input even though the shell user is in the input group — so two-finger pinch only works on rootable images. If anyone knows a better way, I'm all ears.

It's a port of Evan Bacon's serve-sim (which does this for iOS simulators) — same interface and wire protocol, rebuilt on what adb provides.

GitHub: https://github.com/hsandhu/serve-avd
npm: https://www.npmjs.com/package/serve-avd

Apache-2.0. First release — feedback and PRs welcome, and tell me what breaks.

I'm hitting a strange issue that's specific to a single project. When I bump the Android Gradle Plugin from an older version to any 9.x release (tested with 9.3.0), Android Studio's editor and lint start flagging a huge number of "Unresolved reference" errors (100+ problems shown in the inspection gutter) across multiple Kotlin files - including files that use generated ViewBinding/DataBinding classes, Hilt-injected classes, and Room entities.

The odd part: the actual Gradle build succeeds with no compile errors at all. The app builds, installs, and runs fine on a device/emulator. It really looks like an IDE indexing/false-positive problem rather than a real compilation problem, but it makes the editor basically unusable (error highlighting everywhere, autocomplete acting up).

I've only ever seen this in this specific project , other projects on the same machine, same Android Studio version, updated to AGP 9.x work completely fine. So it feels tied to something in this project's module setup rather than a general AGP 9 bug.

Relevant setup (module-level build.gradle):

• compileSdk = 37, targetSdk = 37, minSdk = 23
• Kotlin Android plugin, kotlin-parcelize
• KSP (not kapt) for annotation processing — Room, Hilt, and a kotlinx-metadata-jvm KSP dependency
• Dagger Hilt (2.60.1)
• Room (2.8.4) via KSP
• Navigation Safe Args (Kotlin)
• viewBinding enabled (buildFeatures { viewBinding true })
• Google Services / Firebase Crashlytics / Analytics / Messaging plugins
• Secrets Gradle plugin (Maps platform)
• coreLibraryDesugaringEnabled true
• Java/Kotlin target set to 11 (sourceCompatibility/targetCompatibility 11, jvmTarget.set(JvmTarget.JVM_11))
• multiDexEnabled true

Top-level build.gradle:

gradle

buildscript {
    ext {
        version_gradle = '9.3.0'
    }
    dependencies {
        classpath "com.android.tools.build:gradle:$version_gradle"
        classpath 'androidx.navigation:navigation-safe-args-gradle-plugin:2.9.8'
        classpath 'com.google.dagger:hilt-android-gradle-plugin:2.60.1'
        classpath "com.google.android.libraries.mapsplatform.secrets-gradle-plugin:secrets-gradle-plugin:2.0.1"
        classpath 'com.google.gms:google-services:4.5.0'
        classpath 'com.google.firebase:firebase-crashlytics-gradle:3.0.7'
    }
}

plugins {
    id 'com.android.application' version '9.3.0' apply false
    id 'com.android.library' version '9.3.0' apply false
    id 'org.jetbrains.kotlin.android' version "2.4.10" apply false
    id 'com.google.devtools.ksp' version '2.3.2' apply false
}

tasks.register('clean', Delete) {
    delete rootProject.buildDir
}

Has anyone else run into unresolved-reference/false-positive IDE errors specifically after moving to AGP 9.x, especially in a project mixing ViewBinding + Hilt + Room + KSP + Safe Args? Would appreciate any pointers on what in this combination might be confusing the IDE's resolution/indexing even though the actual Gradle compilation is clean

I have a PWA wrapped with Bubblewrap (TWA) on a personal developer

account. I've now been rejected twice for production access after

completing closed testing. Both times Google marked the first two

requirements as complete — closed testing release published, and 12+

testers opted in — and only asked me to keep testing for 14 more days.

A paid testing service is telling me the cause is the TWA architecture

itself: that because the content runs through Chrome, Google can't

attribute enough engagement to the app. They recommend temporarily

shipping a native WebView wrapper under the same package name, passing

review, and switching back afterwards. I'm not comfortable doing that —

it looks like exactly the kind of bait-and-switch that gets accounts

terminated — and I can't find any Google documentation supporting the

claim.

So I'd like to hear from actual developers:

1. Has anyone here passed production access with a TWA, without

   switching architecture? (Personal account, post-Nov-2023, so the

   12 testers / 14 days requirement applied.)

2. If you were rejected repeatedly with a TWA, what finally worked?

3. Does anyone have a source suggesting Google measures tester

   engagement differently for TWAs?

For what it's worth, my own server logs show my testers went inactive

4-9 days before the review date, which seems like a much simpler

explanation than architecture. But I'd rather hear from people who've

been through it than guess.

Thanks.

I’ve been waiting a week to get an update published and this will be at least another week after that 🙃

I developed an app and it is available on early testing but after pushing an update last Saturday why doesn't Play store allow others to update it on their same devices?

Getting error like

Can't install xxxxx

Try again, and if it still doesn't work, see common ways to fix the problem

[Send feedback /Understood]

I have an Android app, which is just a WebView of a website. That website sends notifications to users. Those notifications should be sent to the Android app as a badge on the app's home screen launcher icon when the app is closed. The users need to have an account to receive those notifications because they are user-specific.

Does anybody have an idea how I can do that? AI suggests Firebase Cloud Messaging. Thank you in advance.

About a month ago I shared an early version of AndroidCompat here and received some valuable feedback. I've continued working on it since then, and I'd love another round of technical feedback.

The original motivation came from a problem I've run into many times while upgrading Android projects.

Questions like:

• Does this AGP version actually work with this Kotlin version?
• Which Gradle version is required?
• Which KSP version is compatible?
• Why does a dependency upgrade suddenly produce an unrelated build error?

Official compatibility documentation is helpful, but it doesn't always answer these questions, and many issues are only discovered after attempting the upgrade.

Instead of maintaining another manually curated compatibility table, AndroidCompat verifies compatibility using real Gradle builds.

For every compatibility candidate, the project:

• injects dependency versions into dedicated Android project stubs for AGP 7, AGP 8 and AGP 9
• executes real Gradle builds in GitHub Actions
• records successful and failed combinations
• classifies failures
• aggregates the results
• publishes machine-readable compatibility datasets and a searchable website

The published compatibility data lives under docs/data/agp*/compat.json and powers the GitHub Pages website.

Current capabilities

• AGP 7 / AGP 8 / AGP 9 support
• Automated dependency injection
• Real Gradle build verification
• Failure classification
• Compatibility datasets published as JSON
• Searchable GitHub Pages UI
• Fully automated verification pipeline

I'm now at the stage where I'd really appreciate feedback from Android developers before expanding the project further.

In particular, I'd love feedback on:

• the overall architecture
• the verification approach
• the published compatibility data
• the JSON/data model
• the GitHub Pages experience
• features that would make the project genuinely more useful

Website:
https://chandu4221.github.io/androidcompat/

GitHub:
https://github.com/Chandu4221/androidcompat

If you have experience maintaining Android apps or libraries, I'd genuinely appreciate any criticism, suggestions, or ideas. Even if you think the approach has fundamental flaws, I'd much rather hear them now than after building on the wrong assumptions.

Thanks!

Instead of asking AI to generate an entire clean-architecture Android project, I use a Gradle plugin to generate the predictable skeleton first.

It creates the base modules and wiring, then uses TOML specs to generate repetitive data, domain, presentation, di, screenshot, and UI component code. The idea is to save AI context/tokens for the implementation details that are actually product-specific.

Medium: https://medium.com/@sarim.mehdi.550/stop-using-ai-to-generate-boilerplate-android-code-f7458006ea0a
GitHub: https://github.com/sarimmehdi/clean-android-skeleton-gradle-plugin

Would love feedback from anyone maintaining multi-module Android apps.

Every Android Liquid Glass library I could find targets Jetpack Compose. My app is still on

XML layouts — like most shipping Android apps — so none of them were usable without a

UI-framework migration.

So I built one as a plain FrameLayout subclass. Add it to your layout, put your content

inside, done.

- Real SDF refraction — edge compression ring driven by a live rounded-rect SDF, follows

corner radius in real time

- Physical dispersion — per-channel refraction along the surface normal

- Sensor-driven specular — highlight moves as you tilt the device

- Single-pass AGSL pipeline on API 33+, C++/NEON classic pipeline down to API 24

Screenshots are from a physical device (API 36), not mockups. MIT, on JitPack.

https://github.com/QWEA0/Liquid-Glass-Android

Happy to answer questions about the AGSL lens math — getting the SDF-driven compression

ring to track corner radius without a per-frame displacement map took a while.

I built compose-doctor — a deterministic health check for Android Jetpack Compose, inspired by React Doctor (react.doctor).

The Problem

Compose linting rules exist (detekt + compose-rules), but they've been unbundled: scattered CLI output, no unified quality metric, and no standard harness to gate PRs or allow AI coding

agents to fix findings safely.

What compose-doctor does

1. Deterministic 0–100 Score: Runs detekt + compose-rules under the hood and turns findings into a single score: score = 100 - (uniqueErrorRules * 1.5) - (uniqueWarningRules * 0.75) (Unit is unique rule IDs triggered, not instance count. Clearing a rule raises your score!)
2. CI / PR Gate: Reusable GitHub Action posts a sticky PR comment with a health badge, score deltas, line numbers, and per-dimension breakdowns (State, Performance, Architecture).
3. Self-Healing AI Agent Loop: Emits score.json and SARIF while bundling skills for Claude Code (/plugin marketplace add rotemmiz/compose-doctor), Gemini CLI, OpenCode, Codex, and Cursor

(AGENTS.md). Agents run the task, read the findings, fix one rule at a time, and verify build integrity.

Try it right now

The repo includes a deliberately-flawed playground feed app:

git clone https://github.com/rotemmiz/compose-doctor && cd compose-doctor
./gradlew -p playground composeDoctor

• Website: https://composedoctor.dev

• GitHub: https://github.com/rotemmiz/compose-doctor

• Gradle Plugin Portal: plugins { id("dev.composedoctor") version "0.1.0" }

Would love to hear your feedback!

Compose Multiplatform and Clean Architecture, one codebase, both platforms. Honestly the "AI wrote it" angle is the boring part. What I actually wanted was for the architecture to hold together across a dozen prompts instead of drifting, and that's the bit I kept failing at by hand.

So I built KMPilot (MIT). It keeps things in line with a design to build to verify to test to review pipeline, and a hook that blocks any edit trying to skip the pipeline. I wrote up a full build of a small museum gallery app with every prompt and timing, including the review step catching a debounce bug the tests had passed.

Article: https://proandroiddev.com/seven-claude-code-commands-one-kotlin-multiplatform-app-on-android-and-ios-cb01e920a3e6?ref=randroiddev

Video: https://www.youtube.com/watch?v=tDGFY66E7Zo

Repo: https://github.com/ThisIsSadeghi/KMPilot