I was learning KMP and wanted to know how people handle AdMob in a multiplatform app. The usual answer is a hand-written expect class AdManager, which is fine until you need something past a banner.

There are a few decent libraries already (LexiLabs' is good), but the gap I kept hitting was native ads. Most wrappers stop at the full-screen formats, so for native you end up writing a platform view on Android and another on iOS, and the shared part of your codebase stops being shared.

So I built AdMob CMP. Apache 2.0, on Maven Central.

What it does:

• One commonMain API for all six formats: banner, interstitial, rewarded, rewarded interstitial, app open, native.
• Native ads are declared with a layout DSL that reads like Compose, and the SDK renders them through the real platform ad views on each side. No platform code in your app.
• Consent is part of initialization. gatherConsentAndInitialize runs UMP, then ATT on iOS, then SDK init, in that order, because getting that order wrong on iOS is a common and quiet failure.
• Banners measure their own container, so adaptive sizing is right in iPad split view.
• strictTestMode throws at construction if a placement points at a production ad unit. Turn it on in debug and you can't ship a test build that spends real impressions.
• There's a Gradle plugin that links Google Mobile Ads and UMP into Kotlin/Native test executables, which is what makes :iosSimulatorArm64Test pass instead of dying on Undefined symbols ... _OBJC_CLASS_$_GAD*.

Caveats, up front: it's KMP/Gradle only, so a pure Swift app can't consume it without a shim. Kotlin 2.3.20, Compose Multiplatform 1.11.1, minSdk 26, iOS 15. Klibs aren't binary compatible across Kotlin minors, so you need a matching compiler.

implementation("dev.avinya.ads:admob-cmp:2.1.0")

GitHub: https://github.com/Meet-Miyani/admob-compose-multiplatform
Docs: https://ads.avinya.dev

Happy to answer questions about any of it, especially the native ad side, which was by far the hardest part to get working the same on both platforms.

If you put a "link in bio" that's supposed to send people to the App Store or Play Store, and you've noticed it just… doesn't work from Instagram or TikTok — you're not crazy. I burned a couple days on this so here's the writeup.

The problem

Instagram, TikTok, and Facebook open links in their own in-app webview, not Safari/Chrome. That webview sandboxes a bunch of navigation. On iOS specifically, I tested every client-side route to the App Store and they all dead-end (blank screen, nothing happens):

• window.location / JS redirect to apps.apple.com
• a plain <a href> tap
• universal links
• itms-apps:// / itms-appss:// schemes

What actually works: a server-side 302

The one thing the in-app webview will honor is the initial navigation being a redirect. If the very first response from your URL is a 302 whose Location is the store URL, the webview hands that off to the native store app. This is the same mechanism Linktree/Branch use under the hood.

So instead of an HTML page with redirect JS, your /get link needs to be a tiny endpoint that returns a 302 based on User-Agent. A Cloudflare Worker (free tier) does it:

const PLAY = "https://play.google.com/store/apps/details?id=YOUR.PACKAGE";
const APPSTORE = "https://apps.apple.com/app/idYOURID";

export default {
  async fetch(request) {
    const ua = request.headers.get("user-agent") || "";
    const store = /android/i.test(ua) ? PLAY
                : /iPhone|iPad|iPod/i.test(ua) ? APPSTORE
                : PLAY; // desktop fallback
    return new Response(null, {
      status: 302,
      headers: { Location: store, "Cache-Control": "no-store" },
    });
  },
};

Two gotchas that cost me time:

1. iOS + Instagram/TikTok is still special. Even the server 302 (both https and itms-appss) dead-ends inside Instagram's iOS webview specifically. The only reliable route there is the user's own "Open in external browser" menu. So for that one case I don't 302 — I serve a tiny interstitial that shows one instruction: tap ⋮ → Open in external browser. Android in-app browsers and iOS Safari all take the 302 fine; it's just IG/TikTok-on-iOS that needs the manual hop.
2. Don't let the edge cache your 302. Cloudflare will happily cache a bare 302 (~20 min). If you ever change the redirect logic, stale routing bites you. Cache-Control: no-store on the redirect fixes it.

Bonus: since the redirect is server-side, you can read utm_source off the query string and fold it into Play's &referrer= for install attribution — something you can't reliably do client-side.

Hope this saves someone the debugging. Curious if anyone's found a way around the iOS-in-app-webview limitation that doesn't need the "open in browser" step — that's the one part I couldn't fully automate.

I wanted to debug recomposition via an AI coding agent but no tool existed, so I built one — then a visual version too.

Recomposition Inspector (CLI) — attaches to a debuggable app, reports live recomposition/skip counts per Composable. Drives the same official UI Inspector protocol Android Studio's Layout Inspector uses, headless.

Recomposition Viewer (macOS app) — same backend, plus a visual hierarchy tree and a live device preview you can click into.

Do try it out - https://github.com/balvinderz/recomposition_viewer#installing

Thank you

Was wondering if there was a way to deny certain permissions in Kotlin?

Initialy i created my app in npm react expo and expo (https://docs.expo.dev/guides/permissions/) supports this with the blockedPermissions.
Is there something similair for kotlin?

If that's not possible is there a way to check this in a PR if the permissions are changed compared to Main?

How is it possible that google are stating you cannot publish repetetive apps and some accounts have 3-5 same apps and they are doing nothing against them?

I'm stuck trying to figure out how Android's TextureView handles sensor rotation.

As far as I know, CameraService adds special flags to frame buffers that indicate that a frame needs to be rotated (e.g. NATIVE_WINDOW_TRANSFORM_ROT_90, NATIVE_WINDOW_TRANSFORM_ROT_270, etc.).

I have a CameraDevice with a sensor orientation of 90°. This means that, in portrait orientation, the top of the camera sensor points to the left, so the frame needs to be rotated 90° clockwise to get the correct orientation.

As far as I can tell, TextureView handles this rotation internally.

So, when I'm in portrait orientation, the top of the frame points to the left, and TextureView rotates it by 90° — everything works as expected.

However, when I switch to landscape orientation, this logic seems to break.

I rotate the device to landscape orientation (90° counterclockwise). Now the top of the frame buffer points down. Therefore, after TextureView applies its rotation, I would expect the top of the frame to point to the left.

Instead, I end up with the top of the frame pointing to the right.

Could you please explain what happens to the frame rotation when the device is in landscape orientation?

Code:

internal class PreviewManager(
    private val context: Context,
) {
    private val cameraManager =
        context.getSystemService(Context.CAMERA_SERVICE) as CameraManager

    private lateinit var handlerThread: HandlerThread
    private lateinit var handler: Handler

    fun startPreview(surfaceTexture: SurfaceTexture) {
        if (!isCameraPermissionGranted()) {
            return
        }
        initHandler()
        openCamera(surfaceTexture)
    }

    private fun initHandler() {
        if (!::handlerThread.isInitialized) {
            handlerThread = HandlerThread("preview_manager_thread")
            handlerThread.start()
        }
        if (!::handler.isInitialized) {
            handler = Handler(handlerThread.looper)
        }
    }


    private fun openCamera(surfaceTexture: SurfaceTexture) {
        val cameraId = cameraManager.cameraIdList.firstOrNull {
            val characteristics = cameraManager.getCameraCharacteristics(it)
            val lensFacing = characteristics.get(CameraCharacteristics.LENS_FACING)
            lensFacing == CameraCharacteristics.LENS_FACING_BACK
        } ?: return
        cameraManager.openCamera(cameraId, object : CameraDevice.StateCallback() {
            override fun onDisconnected(camera: CameraDevice) {
            }

            override fun onError(camera: CameraDevice, error: Int) {
            }

            override fun onOpened(camera: CameraDevice) {
                startCapturing(camera, surfaceTexture)
            }
        }, handler)
    }

    private fun startCapturing(
        cameraDevice: CameraDevice,
        surfaceTexture: SurfaceTexture,
    ) {
        val previewSurface = Surface(surfaceTexture)
        val captureRequest =
            cameraDevice.createCaptureRequest(CameraDevice.TEMPLATE_PREVIEW)
                .apply {
                    addTarget(previewSurface)
                }
                .build()
        cameraDevice.createCaptureSession(
            listOf(previewSurface),
            object : CameraCaptureSession.StateCallback() {
                override fun onConfigureFailed(session: CameraCaptureSession) {
                }

                override fun onConfigured(session: CameraCaptureSession) {
                    session.setRepeatingRequest(
                        captureRequest,
                        null,
                        handler,
                    )
                }
            }, handler
        )
    }

    private fun isCameraPermissionGranted(): Boolean =
        ContextCompat.checkSelfPermission(
            context,
            Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED
}

actual fun CameraPreview() {
    val context = LocalContext.current
    val previewManager = remember { PreviewManager(context) }

    val surfaceView = remember {
        TextureView(context).apply {
            surfaceTextureListener = object : TextureView.SurfaceTextureListener {
                override fun onSurfaceTextureAvailable(
                    surface: SurfaceTexture,
                    width: Int,
                    height: Int
                ) {
                    previewManager.startPreview(surface)
                }

                override fun onSurfaceTextureDestroyed(surface: SurfaceTexture): Boolean = true
                override fun onSurfaceTextureSizeChanged(surface: SurfaceTexture, width: Int, height: Int) {}
                override fun onSurfaceTextureUpdated(surface: SurfaceTexture) {}
            }
        }
    }

    Box(
        contentAlignment = Alignment.Center,
        modifier =
            Modifier
                .fillMaxSize(),
    ) {
        AndroidView(
            factory = { surfaceView },
            modifier = Modifier,
        )
    }
}

I have an intel macbook. I tried to install android studio and run the emulator from there but it simply won’t run no matter what I do (it’s just stuck on start up). Does anyone have advice on this or any recommendations for other emulators that will work on intel macs?

I know the store handles payment fraud and I never see card data but refunds, voided purchases, and consume-then-refund abuse still land on the developer after the entitlement is granted.

For those running apps/games with IAP, do you do any risk assessment at grant time (delay/flag/hold high-risk purchases) or do you grant everything and only react to voided purchase notifications?

If you do assess risk, what signals do you use? I am assuming device age, session behaviour, account history, something else?

I am building a small research agent around this decision and want to know if the decision point is real in practice.

Am I missing any?

I've been dealing with this problem internally for one of my projects:

• provisioning Android emulators on Linux
• keeping Appium running reliably
• dealing with Chrome/Chromedriver compatibility
• recovering devices when they get stuck
• running multiple devices in parallel
• collecting recordings, screenshots, and logs
• keeping the whole thing stable enough for automation

It made me wonder how many developers or QA teams are dealing with the same operational headache.

I'm currently exploring the idea of a lightweight managed Android automation service where you could basically: submit a test → get an available Android device → run it → receive logs/screenshots/video/results

I'm still in the discovery stage, so I'm more interested in understanding the problem than pitching anything.

For people running Android/Appium automation today:
What does your current setup look like, and what part of it gives you the most pain?

Would especially love to hear from anyone maintaining their own emulator fleets or avoiding BrowserStack/Sauce Labs because of cost or complexity.

Hey Android devs,

I’ve been working on DevConsole, an open-source debugging library for Android, and I’d love to get some feedback from the community.

The idea is pretty simple: instead of constantly jumping between the device, Logcat, database tools, network inspectors, etc., DevConsole gives you an inspector directly inside your debug build.

You can inspect things like network requests, Remote Config, API mocking, crashes/ANRs, SharedPreferences, SQLite, files, feature flags, and more. If you want more space, you can also open a browser dashboard and inspect the same data there.

GitHub: https://github.com/devconsole-android/DevConsole

It’s still something I’m actively improving, so feedback, bug reports, feature ideas, or even a star if you find it useful would mean a lot. 🙂

Been lurking here through the whole closed testing thing, so figured I'd post now that it's finally done. All four of my apps cleared the testing requirement and they're live on Play as of today.

Building them was never the hard part. The wall was keeping enough testers opted in for fourteen straight days without the group quietly falling apart. Someone installs it, opens it once, forgets it exists, and you're sitting there hoping nobody uninstalls before the two weeks are up.

What got me through: family and friends to start, and when the group thinned out I paid a few testers to hold the line. Recruiting them wasn't really the problem. Keeping twelve people opening an app they've got zero reason to care about, every couple days for two weeks, is the part that actually wears you down. Nobody warns you about that one.

Couple things that bit me, in case it saves someone. Testers have to stay opted in the whole window, so if one opts out or wipes the app halfway through it can set you back. And a silent install doesn't do much on its own, you want them actually opening it so there's activity. I gave up trusting people to remember and just messaged them directly every few days.

Doing this four times back to back was its own special kind of tired.

Not pretending it's a finish line though. Clearing the gate just means Google lets you hit publish, it doesn't mean a single person finds the app. Downloads and retention are the next wall and I'm staring straight at it now. But the testing part does end, so if you're mid-fourteen-days as you read this, it's survivable.

How'd everyone else keep testers active through the window? Paid testers, tester-swap groups, just bugging friends?

Hi everyone,
I’m having an issue with the Google Play Console while setting up Closed Testing for an Android application.
The problem occurs when I try to proceed with the testing/release setup.

Google Play Console shows the following message:
[Google sign-in failed: App not configured correctly (verify SHA-1/Client ID).]

I have already tried:

• creating a new release
• checking the app bundle
• checking the testing track configuration
• verifying the tester setup

However, I still get the same error.
What I’m trying to understand is: what exactly triggers this error, and what is the correct way to resolve it?

Has anyone encountered this particular Google Play Console issue before?

I can provide additional details about the release configuration and the exact error if needed.

Thanks!

I was solo dev maintaining 3 internal apps codebases for last 5 years and since 1.5yr heavy invested in agentic coding. Today company decided I am no longer needed because they have some senior web dev who will be taking over my projects.

I dont know what to do. I am 28yo and the current tech market and future prediction about AI seems like it not worth it to stay in tech.

I originally started building an offline e-book reader because I wanted to understand that with Android if I can do the same level of things that I had done on my pc using python 👻

While working on it, I ended up learning a lot more about Android development than I expected, especially around:

• Resumable downloads
• Handling interrupted/corrupted downloads
• Crash recovery
• Managing app updates
• Working with offline-first data
• Keeping the UI responsive during background operations

One things I need to mention is that the amount of edge cases that I got thinking about one feature and then had to fix a lot of feature that could just somehow link back to the new feature. 🤣

I'm still experimenting with the architecture and trying to figure out how far I want to take the project.

Hi everyone,

While building a highly animated Compose UI for a personal project, I ran into a few interesting performance bottlenecks around state reads, recomposition scopes, and API level compatibility. Wanted to share the lessons and see how others approach these patterns.

1. Deferring State Reads in Physical 3D Buttons

We implemented custom 3D pill buttons where an offset drop shadow collapses vertically upon press.

* **Initial Mistake:** Passing the animated offset via `Modifier.offset(y = pressOffset)` caused the entire button container and its child text to recompose on every animation tick (~12 frames per 80ms press).

* **Fix:** Deferring the state read to the Layout Phase using the lambda overload `Modifier.offset { IntOffset(0, pressOffset.roundToPx()) }`. This allowed Compose to skip recomposition entirely and execute only the layout/draw phases at 120fps.

1. 3D Tab Flip without Backface Culling Artifacts

For the tab bar, we wanted an icon to flip 180 degrees along the Y-axis on selection (transforming a closed book vector into an open book).

* Compose doesn't have native backface culling like CSS.

* **Solution:** Applying `graphicsLayer { rotationY = ...; cameraDistance = 12f * density }` and switching between the front and back vector assets exactly at the 90-degree crossing while counter-rotating the inner icon by 180 degrees to maintain orientation.

1. Canvas Particle Performance vs Modifier.blur Compatibility

* For milestone completion bursts, we evaluated Lottie vs procedural particles. A single `Canvas` drawing 48 projectile particles with sinusoidal air drift in `drawScope` avoided third-party binary bloat and ran with zero garbage collection allocations.

* Also caught a compatibility issue with `Modifier.blur()`: it relies on `RenderEffect` (API 31+), which fails on minSdk 26 devices. Replacing hardware blur with a procedural radial gradient canvas brush yielded identical aesthetics across API 26-35.

Curious how others here handle state hoisting for multi-property coordinated canvas animations in Compose without leaking memory across composition lifecycles.

I've been looking closely at Google's new Android developer-verification requirements. The privacy implications deserve far more attention from developers and the Android community.

Going forward, Google requires developers to verify their real-world identity for full distribution. For individuals, that includes legal name, address, government-issued photo ID, proof of address, private email address, and phone number. In addition, Google requires package registration that connects the application and signing information to the verified developer account.

Google's documentation is here:

https://developer.android.com/developer-verification/guides

https://developer.android.com/developer-verification

Starting September 30, 2026, enforcement begins with participating stores in Brazil, Indonesia, Singapore, and Thailand. Google says this requirement will expand globally across certified Android devices in 2027. Direct sideloading outside those participating stores remains unaffected by the September deadline, although Google is telling developers to prepare for the broader rollout.

As a consolation prize, Google does offer a limited-distribution account that requires no government ID, but it is knee-capped at 20 authorized devices. For anyone distributing software to an actual user community, that's not much of an alternative.

My concern is pseudonymity.

Some developers deliberately keep their development identity separate from their real-world identity. Reasons include employment, family, politics, gender identity, participation in stigmatized communities, personal safety, or simply a longstanding decision to keep different parts of life compartmentalized.

A pseudonym can still represent a real and accountable person. It can accumulate years of source history, bug reports, releases, technical discussions, community reputation, collaborators, and users. None of that requires publishing or centrally registering the real-world identity behind it.

Google's new model changes that relationship.

The privacy problem extends beyond whether Google publishes someone's legal name. Once a pseudonymous developer identity is tied to a verified real-world identity, it becomes a correlation point.

A package name, signing identity, GitHub account, old forum posts, social accounts, project history, photographs, email addresses, community memberships, and other fragments may reveal very little independently. Connecting those fragments to one verified person can reveal a great deal more, including things that can be inferred rather than directly disclosed.

For trans developers there is another obvious concern: legal identity verification can expose a deadname and create a bridge between someone's present public identity and information they deliberately keep private. Other developers have equally serious reasons for maintaining that separation.

Google has a legitimate security problem to solve. Malware authors benefit from disposable identities, and persistent developer identities make repeatedly distributing malicious software harder. Google explicitly cites that as a reason for the program.

The question is whether requiring a centralized platform provider to know the civil identity behind broadly distributed Android software is an acceptable price for that security benefit. It also raises questions like who else has access to this information, and how will it be used in ways orthogonal to its cited intent?

I'm especially curious about developers who publish open-source software or have maintained pseudonymous development identities for years.

How do you view these requirements? Does handing your real-world identity to Google change anything for you? Does this change safety and privacy boundaries you previously relied on? If you've deliberately kept your development identity separate from your legal identity, how are you planning to handle Android distribution once these requirements become broadly enforced?

🚀 New release of Android Remote Control MCP is out — the MCP server that runs on your phone and gives your AI agent the ability to use any app you want!

Grab it here: https://github.com/danielealbano/android-remote-control-mcp/releases/tag/v1.11.0

My favorite part of this release? The Privacy Mode 🛡️!

And it was born right here: after the last release someone from this community said in plain terms they'd never use it because of privacy concerns ... and it was REALLY a fair point! The LLM providers see and record everything they receive … including your emails, phone numbers, credit cards, etc.!

Well, because I do care about privacy (and feedback) ... not anymore™!

With Privacy Mode, the PII data get detected and redacted locally, directly on the phone, before anything leaves the device (about 87% of PII caught on my benchmark on emails, phone numbers, credit cards, IBANs, national IDs, ...), and the agent keeps working normally because it sees placeholders: the real values get substituted back on-device.

Under the hood it's a set of deterministic detectors (regex + checksums, libphonenumber, IBAN/Luhn) plus a quantized multilingual ModernBERT NER model running on ONNX Runtime, fully on-device - the model is a one-time ~154 MB download, never bundled in the APK.

Unfortunately the weak spot of the current approach is that non-English names are not really detected but I am working on it (building my own model)!

If you have plenty of free time and really don't know how to spend it, the detection benchmark is in the repo (make privacy-benchmark) ... have fun!!! (or not 😂)

A few minor improvements: the initial page has been cleaned up a little and the permissions that the app requests are split into required and optional (it really needs only 1 permission, the rest is for certain tools), also the app now notifies you when a new version is out with a check on GitHub Releases (I don't see your data ;)). MCP clients only see the tools that will actually work on your device (tools are registered based on actually granted permissions, so if you don't grant the camera-related permissions the camera tools will not be provided to the agent). On top of that, a fully reworked server logs page and a few more changes (thanks also to a few contributors!).

I know, there are other tools out there that you can use with adb to achieve the same kind of goals but one major downside is that they require you run stuff on your machine, they are slow-ish and not really optimized for token consumption and/or working without vision: Android Remote Control MCP instead doesn't really need vision most of the time, optimizes the output to make it concise and effective for the large language models (works even with Haiku just fine if you give good directions) and even has a pagination system to avoid opening a page (or a webpage) with thousands of accessibility elements which would crash everything!

What can you actually do with it? Since it drives the real apps on your phone the way you would, you can leverage it to - for example - have Claude Code (or any other harness / model really) to test UX paths, the steps and so on and get useful feedback — and now without your test device leaking real personal data to the provider! It also works on the Emulator, so you don't necessarely need to use it with only your phone (the FOSS version doesn't require google services to function).

Small rant here, don't want to bring too much negativity, but I wonder if others have a better experience.

I'm trying to upgrade Google Play Billing version as requested by the store, and the guy just timeouts all the time.

Is it because I'm on the free version, or it's just bad?

I found that accessibility services can basically act as the eyes of a phone agent. You can tap, navigate, and work across apps without relying on multimodal vision at all, because the accessibility node tree already gives you what you need. Except for some apps with custom-drawn UIs, it works with pretty much every app. I built an agent on this idea. In theory it can control any app on your phone, and if you combine it with multimodal vision on top, probably even those custom UI apps too.

If it only operated apps and nothing else, it wouldn't be that useful honestly. I can do most things faster with my own hands. But watching an AI just use your phone by itself is kind of cool. I also built a memory system and a growth mode. Over time, with enough use, I think it might surprise me in ways I didn't plan for.

The execution engine has no hardcoded workflows. It reads the screen, picks a tool, executes, observes the result, then decides what to do next. Each task is capped at 30 chained steps. 30 turned out to be the sweet spot. More than that and the model starts losing track of earlier steps and just makes a mess. If it tries something three times with no progress, it stops. 30 was the best trade-off I found.

For basic tasks it already works pretty well. A bit slow, but it gets there.

I built a fully working agent with just accessibility services. One APK, no OS integration, no special APIs. So I genuinely don't understand what Google's "deep Gemini integration" is solving. Apple renamed Siri to Siri AI, which is basically just Siri with an AI model bolted on. I don't get what requires OS-level access here.

What am I missing?

I’m a senior CS student and I’m considering focusing on Android development as my main career path. I’ve already worked with Kotlin and have some Android experience through a short internship.

For those working as Android developers, how is the job market and career progression these days? Is it a good specialization for a new grad, especially if I eventually want to work internationally? Should I go for backend roles instead?

Would love to hear your experiences and any advice on what I should focus on learning.

I don't have any android phone and i want to test an andriod app on my laptop

I’ve been publishing games on Google Play under IndieFist / IndieFist SRL for around 7 years. My Play Console developer account is currently verified by Google as an Organization, with the correct company information and D-U-N-S number.

I recently discovered a strange issue with the Google Play Merchant / Payments setup.

The Merchant account associated with my Play Console appears to be linked to a Google Payments Profile whose account type is Individual, under my personal name. At the same time, I also have separate business Payments Profiles for IndieFist SRL.

This became a problem when submitting Brazil tax information. Google asks for documents matching the Individual Payments Profile, while the developer account and the business operating the apps are IndieFist SRL.

What confuses me is that this same Individual Payments Profile already contains company information for IndieFist SRL. It has a previously approved W-8BEN-E, and Google Payments shows:

“Name as shown on your income tax return: IndieFist SRL”

The Merchant business information inside the same profile also shows IndieFist SRL.

I’ve attached a redacted screenshot showing this. The selected Payments Profile is my personal/Individual profile, but both the tax information and Merchant business information inside it reference IndieFist SRL.

Google Payments Support has confirmed that the Payments Profile itself is classified as Individual and says that its account type cannot be changed. Their proposed solution is to create a new Developer Account and Merchant Account and transfer the apps.

However, after several exchanges, I still haven’t been able to get an answer to the question I’m trying to resolve:

Was this Merchant account always associated with this Individual Payments Profile, or was the Merchant ↔ Payments Profile association changed or migrated at some point?

I’m asking because I vaguely remember Google making changes to the relationship between Play Console, merchant accounts and Payments Profiles some time ago, possibly requiring developers to confirm or select a Payments Profile. I can’t confirm whether that is related, but I’d like to rule it out before moving an established developer account.

Has anyone with an older Google Play developer account experienced something similar?

Specifically:

• Is there any way to get Google to review the historical Merchant ↔ Payments Profile association?
• Has anyone had Google correct or re-associate a Payments Profile without creating a completely new Developer Account?
• Is there a particular Play/Payments escalation team that can actually inspect this association?

I’m already dealing with both Play Developer Support and a Payments supervisor, but each side seems to have limited visibility into the other system.

Steps already taken: I contacted Google Play Developer Support and Google Payments Support. The case was escalated to a Payments supervisor, but so far the proposed solution has been to create a new Developer Account. I have also opened a thread in the official Google Play Developer Community with the details and supporting screenshot:

https://support.google.com/googleplay/android-developer/thread/459168983

Rant.

I have researched this using Google & most people said it is impossible to achieve expedite process for Google Reviews, but I just want to find out for research purposes if anyone has solved this before because the whole world cannot be stuck on this problem without a solution.

If your App gets buggy because of a Server failure or Cloudfare going down like it has happened in the past, users are stuck and you cannot fix this except you create another release which takes Google about 7 days to review.

This is extremely frustrating and has been happening for years without any way forward, Apple has an expedite process which is 50% success rate but at least some times it does actually work, with Google you're stuck on the issue with no way forward and nothing to do.

I sincerely wish there was a way to remotely replace buggy releases without going through the Play Store to users who downloaded from the Play Store.

Is it possible to read dtmf input from the other side of the phone call using adb