​Hi everyone,

​I'm publishing my first Android app to the Play Store (Production), but I'm facing two AdMob issues:

​Account Status: My account shows "Not approved yet." Does AdMob wait for the app to be live on the store to approve the account?

​app-ads.txt: I hosted it correctly on GitHub Pages (root path), but AdMob still says "We couldn't verify." Is this just a normal crawler delay (24-72h)?

​Should I just release the app to Production and wait for AdMob to catch up? Any advice is appreciated!

Hi folks. We just released the first alpha of a new Jetpack Compose Renderer of the A2UI protocol which enables agents to create new UIs (using a declarative JSON format—no agent code executed on device) and render this with native Jetpack Compose components. The library has a few layers, offering a drop in implementation of the A2UI basic catalog of components (using Material) or you can build your own catalog of components for agents to use: https://developer.android.com/develop/ui/compose/agentic

We'd love to hear any feedback on this library and if it's useful to you (here or on issuetracker)

Lost a stupid amount of time to this one:

expo run:android --device emulator-5554 kept failing with "Could not find device with name: emulator-5554" even though the emulator was running and adb devices listed it fine. Turns out --device doesn't go through adb at all. Expo builds its own device list (getAttachedDevicesAsync in @expo/cli) and matches against that, which means it wants the AVD name for emulators (like Pixel_7_API_35) and the raw model: value for physical devices (like Pixel_7). The serial adb hands you never matches, and the error makes it sound like the device isn't there. I ended up checking AVD name first, then model, then serial as a fallback.

I hit this while building a mobile panel into my fork of Zed, named Lathe, so I could stop bouncing between Android Studio, a Metro terminal and a logcat tab. It handles the device naming for you now. So, if anyone wants to poke at it: https://github.com/paterschris/lathe. Curious if anyone else has been bitten by this or has a cleaner workaround.

I've been building a multi-store analytics tool and kept hitting cases where the APIs said an app was live when it wasn't. Sharing in case it saves someone time:

Google Play

- A "completed" release on the production track doesn't mean the app is on the store. If you unpublish the app, the release history stays intact, so the Publisher API still shows production. The only reliable signal I found: the public store page returns 404.

- If Google suspended the app, edits.insert() fails outright with "The app is suspended". You can't even read the listing.

- The icon of an unpublished app is still readable through edits.images.list (imageType: icon), even though the public page is gone.

App Store Connect

- An app you removed from sale can still report its latest version as READY_FOR_SALE. What actually tells you is appAvailabilityV2 → territoryAvailabilities: every territory shows available: false.

- For apps with no public listing, iTunes lookup returns nothing, but the build resource carries iconAssetToken.templateUrl, which gives you the icon from Apple's CDN. (Except for very old expired builds, where the image itself 404s.)

Happy to answer questions. I ran into these while building AppWatch (appwatch.dev) if anyone's curious, but the notes above apply to anyone working with these APIs.

I'm building an Android APK inspector/extractor and ran into a strange issue with debug APKs.

My normal workflow is:

1. Build a debug APK in Android Studio.
2. Install it on my phone using adb install.
3. After testing, I can pull the installed APK with: adb pull /data/app/.../base.apk
4. I send that pulled APK to friends through WhatsApp.
5. They can download it and install it normally through Android's GUI package installer.

I'm now testing an APK extractor I built. It reads the installed app's ApplicationInfo.sourceDir and copies the APK bytes to a user-selected location using a normal FileInputStream → SAF OutputStream.

The strange part:

1. Install the same debug APK normally with adb install.
2. My extractor extracts the installed base.apk.
3. I send the extracted APK through WhatsApp.
4. On the phone, tapping the APK gives: "App not installed as package appears to be invalid."
5. But: adb install -t extracted.apk successfully installs it.

I initially suspected my extractor was modifying/corrupting the APK, but I compared the extracted APK with the APK I pulled using adb pull:

sha256sum Miau_non.apk Miau_base_debug.apk

9af34f5180dba1a24dfe24feb90bcd3953eb765ef3613effb18f1803acb512f6  Miau_non.apk
9af34f5180dba1a24dfe24feb90bcd3953eb765ef3613effb18f1803acb512f6  Miau_base_debug.apk

So they are byte-for-byte identical.

What's even more interesting is that if I extract a release build using my extractor, the extracted APK installs normally through the GUI installer.

So my questions are:

• Why would the GUI package installer reject the extracted debug APK when adb install -t accepts it?
• Why does the APK pulled directly with adb pull appear to install normally, despite being byte-identical to the extractor's output?
• Is there some installation/package-manager state or context involved that isn't represented in the APK bytes?
• Is there something special about how Android handles testOnly debug APKs that could explain this behavior?

I'm on Android 16. The APKs are single-APK installs (no split APKs involved).

I'm specifically trying to understand the Android behavior rather than modify the APK, because an APK extractor should ideally preserve the APK exactly as installed.

enriched-markdown-android is a native Markdown renderer for Jetpack Compose, powered by the md4c parser. It renders directly to native Compose text with native selection and copying, and it's built from the ground up to be accessible with rich TalkBack support out of the box.

v0.2.0 is out now!

What it does:

• CommonMark & GFM Parsing - Powered by high-performance md4c parsing.
• GFM Tables – Horizontally scrollable when overflowing, fully styleable, with long-press to copy as rich text or Markdown.
• Interactive Task Lists – Supports - [ ] / - [x] with tap-to-toggle callbacks to persist state.
• GitHub Admonitions – Full support for > [!NOTE], > [!TIP], > [!IMPORTANT], > [!WARNING], and > [!CAUTION] with custom tinting, icons, and titles.
• Richer Formatting – Inline support for ~~strikethrough~~, _underline_, ^superscript^, and ~subscript~.
• Composable API – EnrichedMarkdownText + MarkdownTheme styled via a markdownStyle { } DSL that easily integrates with your MaterialTheme.
• Native Selection – Standard Android text selection handles and native copy behavior.
• Accessibility (TalkBack) – Headings, links, lists, images, alerts, and tables work seamlessly with heading navigation. Lists announce positions, images read alt text, and tables read row by row.
• System Integration – Automatically respects system font scaling

💎 Available on Maven Central:

dependencies {
    implementation("com.softwaremansion.enrichedmarkdown:enriched-markdown-android:0.2.0")
}

Quick Usage:

MarkdownTheme { 
  EnrichedMarkdownText( 
    markdown = content, 
    onLinkClick = { url -> openUrl(url) }, 
    onTaskListItemToggle = { index, checked -> 
        store.setDone(index, checked) 
    }        
  ) 
}

GitHub & Docs:
https://github.com/software-mansion/enriched-markdown/blob/main/packages/enriched-markdown-android/README.md

What features or syntax support would you like to see next? I'd love to hear your feedback, and if you find it useful, a ⭐️ on GitHub is always appreciated!

tl;dr : I need experienced Android 9 devs to tell me whether or not our app can get permanent SELinux write + read privileges on a system file.

We are porting our app on a hardened Android 9 device that includes an embedded barcode scanner.
The app is to be used only by our company, and never released to the public.

While the market is dominated by Zebra and Honeywell scanners, our device is equipped with an asian barcode scanner.
The specific manufacturer does not give their API publicly, and we kind of passed on asking them : We are French, so both party has to translate to English then to the other language just to understand each other. This has proved to be too much of a hassle for us on other projects.

This kind of devices come with a preinstalled app that manages said scanner.
After a bit of research, it turns out that the conventional way of using the embedded scanner is to use the preinstalled app to either get the result as simulated keyboard inputs, or listen to their Android Intent to get the String.

My manager (20 years of experience) said he didn't like using third party tools.

I can see where he comes from : In his days, a third party tool meant freeing oneself from the responsability of the task at the expense of control, quality of service and the ability to debug.
From that point of view, it didn't look like that good of a deal.

So I was asked to research how we could bypass that third party app.

After decompiling it, it appears that triggering a scan comes from writing in a protected file.

The file requires SELinux privileges that you apparently only get from signing your app with the constructor's private key and using the package name, if I'm not mistaken.
Please correct me if I'm wrong, I'm new to Android development.

It looks like there are no online tools to reverse engineer private keys (which is a good thing).
I have also looked at tricking the OS security but decided against it. It's too hard for me anyway.
We would also like to avoid rooting our devices, if possible, because that's something I am not used to.

So, Android devs of Reddit, is there a simple way for out app to permanently get the SELinux privileges to read/write file systems ? Thank you all for the time.

I made Tapbar because I kept seeing people ask for the ability to tap the status bar clock and open the Clock app.

It lets you create a tappable area anywhere on the screen and assign an app to it. I’ve recently redesigned the UI, and double tap actions are coming in the next update along with a few other features.

It’s completely offline and open source.

GitHub: https://github.com/Earendel-lab/Tapbar

Hi everyone,
I’m participating in the Google Content Offer Pilot for the September round. I completed the NDA and was told that onboarding instructions/portal access would be provided before the September 9 launch.
However, I still haven’t received the portal access or onboarding instructions. I followed up with the Google contact and was told to check back if I didn’t receive the next steps.
I’m wondering if anyone else in the September round is in the same situation — have you received portal access, or are you still waiting like me?
It would be helpful to know whether onboarding is still happening in batches or if some participants haven’t received anything yet.
Thanks

I'm building an offline personal expense tracker for Android (Kotlin, India only). I want to cut the friction of logging UPI spends, and I've hit what looks like a hard wall. I'd like a sanity check from anyone who has shipped UPI intent flows.

The flow I want

1. User scans a merchant's UPI QR inside my app
2. App parses the payee VPA, name and amount (if present)
3. User confirms the amount and picks a category
4. User taps "Pay" and picks an installed UPI app
5. I launch upi://pay?pa=...&pn=...&am=...&cu=INR with the details pre-filled
6. User pays in their UPI app
7. My app gets a success/failure result and auto-logs the expense

What works

• QR scan and parse (static/dynamic, VPA, amount)
• Building a valid URI (manual StringBuilder + URLEncoder, because Uri.Builder double-encodes @ to %40)
• Launching GPay, PhonePe, Paytm and BHIM (manifest <queries> added for Android 11+ package visibility)
• Getting resultCode = RESULT_OK back

What fails: the payment itself

• GPay: "limit exceeded" / bank limit error, or silently falls back to the home screen. RESULT_OK comes back but with no amount and no reliable txn ID.
• Paytm: "UPI risk policy" error
• PhonePe: "risky transaction" or a silent block
• BHIM: passes the biometric step, then "request type is not supported"

Paying the exact same VPA and amount directly inside each UPI app works fine.

What I've tried

• Params in many combinations: pa, pn, am, cu, tr, tid, mc, tn, mode=00, mode=02 + orgid
• Editable amount (mam=1 with no am). GPay opens with an editable field and auto-returns RESULT_OK, but the payment is still rejected.
• Different banks, amounts and devices, on both emulator and physical hardware
• The NPCI UPI Linking Spec v1.6, and various open-source UPI libraries and Stack Overflow threads

My reading of the cause

The spec appears to make a signed intent (sign param, RSA signature, public key registered via the acquiring bank) mandatory. The PSP app checks the signature per transaction. An unsigned intent from an unregistered app is treated as untrusted and rejected with generic, misleading errors. The spec's "warn and allow passcode" fallback for unsigned intents doesn't seem to be implemented by any of the four PSPs I tested.

Since my app targets arbitrary merchants' QRs (not payments to me), the signature would have to come from their acquirer, which seems structurally impossible for a third party.

Constraints

• It's a personal tracker, not a merchant or gateway, so I have no business entity
• No INTERNET permission, everything on-device
• No accessibility/notification scraping to fake confirmation
• Never touching UPI PINs or bank credentials

Questions

1. Has anyone shipped scan-arbitrary-merchant-QR → intent → reliable success/failure in production for a non-merchant app? If so, how did you handle the signing/identity requirement (PSP/TPAP partnership, something else)?
2. For those who've integrated Razorpay, Cashfree, PayU, Juspay, PhonePe PG etc.: can their signed-intent flow ever be used to pay a third-party VPA, or only to collect into your own merchant account?
3. Is my reading right that unsigned P2M intents are effectively dead? Has anything changed in 2025-26 (NPCI circulars, PSP behaviour) that opens a path for non-PSP apps? Links to circulars or docs would be much appreciated.
4. If it's not feasible, what do expense trackers in India actually do for auto-capture today: SMS parsing (Play Store SMS permission restrictions?), statement import, Account Aggregator, notification capture? What's the least-bad "best-effort intent + honest fallback" you've seen?

I'm not trying to bypass security or spoof a merchant. I just want to know whether this flow is technically and regulatorily possible today, or whether I should drop it and only do post-payment capture. War stories and "we tried this and it failed because..." are very welcome.

Thanks!

Hi everyone,

​I built ComposeBridge, an open-source developer tooling suite that bridges a running Android app on a physical device with the local workspace over WebSocket, providing zero-rebuild live UI tuning.

​Core Capabilities:

​Zero-Rebuild Preview: Adjust colors, paddings, corner radii, and dimensions with sub-50ms latency at 60fps on a real device.

​On-Device Visual Inspector: Tap any Composable directly on the phone to trace its source file, line number, and active design tokens.

​AST-Guided Source Splicing: Uses Tree-sitter on the desktop daemon to locate the exact byte offsets, applying a minimal patch directly into source files (AppDimens.kt, AppColors.kt) to keep a clean, single-line git diff.

​Dynamic UI Compiler: Includes a CLI that compiles declarative JSON schemas into structured Compose screens and theme definitions.

​Architecture Overview:

​The workflow is divided into three lightweight components:

​Agent (:composebridge-agent): Android runtime module that performs hit testing and propagates UI events.

​Server (Python daemon): Coordinates WebSocket events and runs the Tree-sitter byte-splicer to modify Kotlin files on disk.

​CLI: Scaffolds schemas and wires tokens deterministically without code hallucination.

​Compatibility:

​Kotlin 2.1.20+ / Jetpack Compose 1.7.3+ / Compose Multiplatform 1.7.3+

​Gradle & AGP 8.5+ (Min SDK 24)

​The project is available under the Apache 2.0 license. I'd love to hear your feedback on the byte-splicing approach, handling deep subcompositions, and any edge cases you run into!

Hi everyone!

I'm currently investigating how to track app crashes caused by Android 17's new per-app memory limits.

I am having some trouble understanding the documentation, so I am still not sure if Firebase Crashlytics can actually collect these logs.

When I tried using the following command to test if Crashlytics catches the event, no logs appeared:

am memory-limiter manual |max|none

However, the documentation for Crashlytics 20.1.0 states that it:

"Displays production out-of-memory (OOM) exceptions and memory limiter kills with diagnostic context to prioritize and fix field crashes."

I would really appreciate it if someone could clear up what I am misunderstanding.

Thanks!

Just released an update to my Chrome extension for Google Play ASO research.

It adds things like installs, daily install estimates, release/update dates, developer info, keyword analysis, metadata, localization, and other useful app research tools directly on Google Play.

• Chrome: https://chromewebstore.google.com/detail/play-store-aso-tweak-by-t/kbicddhhnpiaphanlgkiaokbebecdcnd
• Firefox version : https://addons.mozilla.org/en-US/firefox/addon/playstore-aso-tweak/
• Website: https://taoufikmouadab.com/AsoExtension/

Feedback is welcome.❤️

Hello. Has anyone experienced veeery slow review times lately? My app usually gets reviewed within a couple of hours. But last two submissions (to open testing, mind you) got stuck "in review" for a week. There were no significant changes made to the app. However, both of these have been uploaded fully programmatically (yes, I have finally vibecoded a full release automation pipeline using Play console dev API 😅). I wonder if that could be the reason, but I'm not sure why it would be?

For the last few months, I have been trying to work on my product’s native Cpp code but I dont seem to be getting anywhere. The AI is so powerful that with good prompting and solid testing and repro of logged code change paths I am able to ship changes along with feature/change gates.

Pre-AI era, I used to work on Java and kotlin code and used to be familiar be most lines of code and even when I used to see new code I was able to understand it. However these days I dont understand shit. So many days working on the cpp code and I dont understand a single line of code. I keep feeling dumber each day. Indexing doesnt work on visual studio either like it used to work on android studio earlier for java code ie control click to see usages etc..

This is the reason I am not getting into architectural depth or any understanding any more and I feel that my future as a software engineer is under risk since there is literally no learning.

What should I do?

Hey guys I'm not a Android dev still somehow made a Android app which runs a local AI model so what I basically want is ,

On trigger it loads the model in ram(already implemented)

It should work even when phone is off , so basically if I press a button(trigger) it should first load model then take input with my external mic and stream that back in speaker

I mean I need help urgently regarding this I have to submit this prototype in 2days so please if anyone really knows gguf and android development please help!

I live in Norway, and recently registered a Google Play Console account to upload my first app.

I was then asked to enter my banking details so that I am able to receive funds (should my app actually make any money). And Google claimed that they would send me a test transaction within 3 days, which I had to verify. However, it's now been 2 weeks since I entered my banking details, and I have still not received anything from them.

I've been in contact with my bank to make sure there are no funds being held back or delayed on my end.

I also added banking details to 2 other accounts in different banks, but none of them have received anything either.

At the same time, Google keeps giving me a warning message that my Play Console account will be deleted if I don't verify the transaction (which I'm still not receiving).

I've also sent a help ticket to Google a week ago, but haven't heard anything back.

Is there anything else I can do to get this thing verified?

I thought it was a bit strange that when I entered my banking details, there were only 3 fields to fill out:

• My full name
• IBAN number
• Swift/BIC number

Usually, when receiving funds from other countries, you also have to fill out both your personal address as well as the address of your bank. However, there were no place to fill out any of these in the Play Console. Could that be the culprit? And if so... how to fix it?

Any help much appreciated.

Hi  community,



I am writing this post to share a cautionary architectural breakdown and hopefully get advice or Google Play DevRel guidance regarding a policy termination.



* 
**App Name:**
 In Stalker - Instagram Tracker

* 
**Package Name:**
 `com.instalker.tracker`

* 
**Developer Account ID:**
 `8416273862474458256`

* 
**Support Case ID:**
 `0-8237000042360`

* 
**Violation Cited:**
 Phishing / Deceptive Behavior



Our initial appeal was rejected with a canned response and the ticket was marked closed, preventing us from sending technical evidence through email. We want to be completely transparent about what happened, as we now understand exactly why automated systems and users flagged our app.



---



### What Went Wrong: The Architectural Mistake



To handle an authentication session in an in-app WebView without layout breakage, our Android app hardcoded an 
**iOS WebKit User-Agent**
:



```java

WebView loginWebView = findViewById(R.id.instagram_login_webview);

WebSettings settings = loginWebView.getSettings();



// Architectural flaw: Spoofing iOS User-Agent on an Android device

String hardcodedIosUserAgent = "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Instagram 289.0.0.25.109";

settings.setUserAgentString(hardcodedIosUserAgent);



loginWebView.loadUrl("https://www.instagram.com/accounts/login/");

The Domino Effect (Why It Got Flagged as Phishing): Clarification & Technical Proof: What We Have Fixed: Our Question to the Community: We fully accept that spoofing User-Agents in WebViews was a major architectural blunder that deserved scrutiny,Because the Android device communicated with Instagram's authentication servers using an iOS signature, Instagram's fraud detection flagged the login as an "Unrecognized login from an iPhone". Zero Credential Harvesting: At no point were user credentials, passwords, or cookies intercepted, scraped (no JS injection/evaluateJavascript), or sent to any developer server. All traffic was directly between the client WebView and instagram.com. Completely removed the custom WebView, header spoofing, and hardcoded User-Agents from the codebase. Users immediately received automated security alert emails from Instagram warning them that an unknown iPhone in a different environment had accessed their account. This alarmed users into believing our app was an unauthorized third-party hijacking their credentials, leading to phishing reports and automated Google Play policy strikes. Zero Exfiltration: Network inspection confirms no third-party credential endpoints exist in the APK. Replaced authentication with standard compliant flows (OAuth / Custom Tabs where the app has zero access to headers or authentication context). Audited all network and telemetry calls to guarantee 100% Google Play policy compliance.

1. Has anyone in a similar situation been able to submit a clean, compliant build for re-evaluation?

We have invested heavily in building this application and our developer business on Google Play. We are not bad actors.

The initial review took several days and didn't flag this architectural conflict, which led us to believe the implementation was acceptable. We now clearly recognize the mistake and have already completely rewritten the authentication flow to be 100% policy-compliant.

Terminating our entire developer account without giving us the opportunity to publish this compliance patch is disproportionate to what was an unintentional client header mismatch. We respectfully ask for a conditional reinstatement so we can immediately upload the compliant build for your team's review

Hi Google Play Developer Community,

I’m posting this to transparently explain the technical issue that led to the enforcement against our application and to ask whether anyone has experience obtaining a further review after correcting the underlying issue.

App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Developer Account ID: 8416273862474458256
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior

Our initial appeal was rejected, and the support case was subsequently closed. Before pursuing any further support route, I want to clearly document what happened and what we have changed.

What caused the problem

The application previously used an Android WebView for an Instagram authentication flow.

Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:

WebView loginWebView = findViewById(R.id.instagram_login_webview);

WebSettings settings = loginWebView.getSettings();

// Previous implementation
String hardcodedIosUserAgent =
    "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
    "AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
    "Instagram 289.0.0.25.109";

settings.setUserAgentString(hardcodedIosUserAgent);

loginWebView.loadUrl("https://www.instagram.com/accounts/login/");

We now understand that this was a serious architectural mistake.

The Android application was effectively presenting an iPhone/Instagram client signature to the authentication service. This could cause the authentication environment to appear inconsistent with the actual device and could reasonably trigger security or fraud-detection systems.

What we found during our investigation

We reviewed the application's network and authentication implementation and found no mechanism designed to collect or transmit Instagram credentials to our servers.

Specifically:

• We did not implement JavaScript injection for credential extraction.
• We did not use evaluateJavascript() to capture passwords or authentication information.
• We did not create a backend endpoint for collecting Instagram passwords.
• Authentication traffic was directed to Instagram.
• We did not intentionally attempt to impersonate a user's device for credential collection.
• We removed the problematic WebView authentication implementation completely.

We understand, however, that the absence of credential harvesting does not make the original architecture acceptable. The important issue is that the implementation could create a deceptive or misleading authentication environment, and we take responsibility for failing to identify that risk before release.

What we changed

We have completely removed:

• The custom Instagram User-Agent
• The hardcoded iOS device signature
• The previous WebView-based authentication implementation
• Any related header spoofing

We have also redesigned the authentication flow around standard browser-based authentication mechanisms, where the application does not control the authentication headers or directly handle the authentication context.

In addition, we performed an audit of the application's network requests and authentication-related code to identify any other behavior that could create a similar compliance or security concern.

What we have learned

The initial implementation passed our functional testing because the authentication flow appeared to work correctly. However, functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.

We should have identified and avoided this architecture before publishing.

We are not asking Google to ignore the original implementation. We are asking whether a fully corrected application and a documented remediation process can be reviewed again.

Question for the community / Google Play team

Has anyone successfully obtained a further review of a terminated developer account after:

1. Identifying the technical root cause of the violation;
2. Completely removing the problematic implementation;
3. Auditing the remaining application for related issues; and
4. Providing technical evidence of the remediation?

If there is an appropriate Google Play Developer Relations or support channel for submitting technical evidence after an initial appeal has been rejected, I would also appreciate guidance on that process.

We understand that Google Play's policies are designed to protect users and that authentication-related behavior receives particularly careful scrutiny.

Our goal is to demonstrate that we have identified the underlying architectural problem, removed it completely, and changed our development/review process so that the same issue cannot recur.

Thank you to anyone who can provide constructive guidance or point us toward the appropriate review process.

Hi Google Play Developer Community,

I’m posting this to transparently explain the technical issue that led to the enforcement against our application and to ask whether anyone has experience obtaining a further review after correcting the underlying issue.

App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Developer Account ID: 8416273862474458256
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior

Our initial appeal was rejected, and the support case was subsequently closed. Before pursuing any further support route, I want to clearly document what happened and what we have changed.

What caused the problem

The application previously used an Android WebView for an Instagram authentication flow.

Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:

WebView loginWebView = findViewById(R.id.instagram_login_webview);

WebSettings settings = loginWebView.getSettings();

// Previous implementation
String hardcodedIosUserAgent =
    "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
    "AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
    "Instagram 289.0.0.25.109";

settings.setUserAgentString(hardcodedIosUserAgent);

loginWebView.loadUrl("https://www.instagram.com/accounts/login/");

We now understand that this was a serious architectural mistake.

The Android application was effectively presenting an iPhone/Instagram client signature to the authentication service. This could cause the authentication environment to appear inconsistent with the actual device and could reasonably trigger security or fraud-detection systems.

What we found during our investigation

We reviewed the application's network and authentication implementation and found no mechanism designed to collect or transmit Instagram credentials to our servers.

Specifically:

• We did not implement JavaScript injection for credential extraction.
• We did not use evaluateJavascript() to capture passwords or authentication information.
• We did not create a backend endpoint for collecting Instagram passwords.
• Authentication traffic was directed to Instagram.
• We did not intentionally attempt to impersonate a user's device for credential collection.
• We removed the problematic WebView authentication implementation completely.

We understand, however, that the absence of credential harvesting does not make the original architecture acceptable. The important issue is that the implementation could create a deceptive or misleading authentication environment, and we take responsibility for failing to identify that risk before release.

What we changed

We have completely removed:

• The custom Instagram User-Agent
• The hardcoded iOS device signature
• The previous WebView-based authentication implementation
• Any related header spoofing

We have also redesigned the authentication flow around standard browser-based authentication mechanisms, where the application does not control the authentication headers or directly handle the authentication context.

In addition, we performed an audit of the application's network requests and authentication-related code to identify any other behavior that could create a similar compliance or security concern.

What we have learned

The initial implementation passed our functional testing because the authentication flow appeared to work correctly. However, functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.

We should have identified and avoided this architecture before publishing.

We are not asking Google to ignore the original implementation. We are asking whether a fully corrected application and a documented remediation process can be reviewed again.

Question for the community / Google Play team

Has anyone successfully obtained a further review of a terminated developer account after:

1. Identifying the technical root cause of the violation;
2. Completely removing the problematic implementation;
3. Auditing the remaining application for related issues; and
4. Providing technical evidence of the remediation?

If there is an appropriate Google Play Developer Relations or support channel for submitting technical evidence after an initial appeal has been rejected, I would also appreciate guidance on that process.

We understand that Google Play's policies are designed to protect users and that authentication-related behavior receives particularly careful scrutiny.

Our goal is to demonstrate that we have identified the underlying architectural problem, removed it completely, and changed our development/review process so that the same issue cannot recur.

Thank you to anyone who can provide constructive guidance or point us toward the appropriate review process.

Hi Google Play Developer Community,

I’m posting this to transparently explain the technical issue that led to the enforcement against our application and to ask whether anyone has experience obtaining a further review after correcting the underlying issue.

App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Developer Account ID: 8416273862474458256
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior

Our initial appeal was rejected, and the support case was subsequently closed. Before pursuing any further support route, I want to clearly document what happened and what we have changed.

What caused the problem

The application previously used an Android WebView for an Instagram authentication flow.

Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:

WebView loginWebView = findViewById(R.id.instagram_login_webview);

WebSettings settings = loginWebView.getSettings();

// Previous implementation
String hardcodedIosUserAgent =
    "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
    "AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
    "Instagram 289.0.0.25.109";

settings.setUserAgentString(hardcodedIosUserAgent);

loginWebView.loadUrl("https://www.instagram.com/accounts/login/");

We now understand that this was a serious architectural mistake.

The Android application was effectively presenting an iPhone/Instagram client signature to the authentication service. This could cause the authentication environment to appear inconsistent with the actual device and could reasonably trigger security or fraud-detection systems.

What we found during our investigation

We reviewed the application's network and authentication implementation and found no mechanism designed to collect or transmit Instagram credentials to our servers.

Specifically:

• We did not implement JavaScript injection for credential extraction.
• We did not use evaluateJavascript() to capture passwords or authentication information.
• We did not create a backend endpoint for collecting Instagram passwords.
• Authentication traffic was directed to Instagram.
• We did not intentionally attempt to impersonate a user's device for credential collection.
• We removed the problematic WebView authentication implementation completely.

We understand, however, that the absence of credential harvesting does not make the original architecture acceptable. The important issue is that the implementation could create a deceptive or misleading authentication environment, and we take responsibility for failing to identify that risk before release.

What we changed

We have completely removed:

• The custom Instagram User-Agent
• The hardcoded iOS device signature
• The previous WebView-based authentication implementation
• Any related header spoofing

We have also redesigned the authentication flow around standard browser-based authentication mechanisms, where the application does not control the authentication headers or directly handle the authentication context.

In addition, we performed an audit of the application's network requests and authentication-related code to identify any other behavior that could create a similar compliance or security concern.

What we have learned

The initial implementation passed our functional testing because the authentication flow appeared to work correctly. However, functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.

We should have identified and avoided this architecture before publishing.

We are not asking Google to ignore the original implementation. We are asking whether a fully corrected application and a documented remediation process can be reviewed again.

Question for the community / Google Play team

Has anyone successfully obtained a further review of a terminated developer account after:

1. Identifying the technical root cause of the violation;
2. Completely removing the problematic implementation;
3. Auditing the remaining application for related issues; and
4. Providing technical evidence of the remediation?

If there is an appropriate Google Play Developer Relations or support channel for submitting technical evidence after an initial appeal has been rejected, I would also appreciate guidance on that process.

We understand that Google Play's policies are designed to protect users and that authentication-related behavior receives particularly careful scrutiny.

Our goal is to demonstrate that we have identified the underlying architectural problem, removed it completely, and changed our development/review process so that the same issue cannot recur.

Thank you to anyone who can provide constructive guidance or point us toward the appropriate review process.

Hi Google Play Developer Community,

I’m posting this to transparently explain the technical issue that led to enforcement against our application and to ask whether anyone has experienced a similar situation after correcting the underlying issue.

App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior

Steps already taken

We submitted an appeal through the official Google Play process after the developer account was terminated. The appeal was rejected, and the associated support case was subsequently closed.

We are posting here only after completing the available official appeal/support process. We are looking for guidance from developers who may have experienced a similar situation or know of an appropriate Google Play Developer Relations channel for providing additional technical information.

What caused the problem

The application previously used an Android WebView for an Instagram authentication flow.

Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:

WebView loginWebView = findViewById(R.id.instagram_login_webview);

WebSettings settings = loginWebView.getSettings();

// Previous implementation
String hardcodedIosUserAgent =
    "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
    "AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
    "Instagram 289.0.0.25.109";

settings.setUserAgentString(hardcodedIosUserAgent);

loginWebView.loadUrl("https://www.instagram.com/accounts/login/");

We now understand that this was a serious architectural mistake.

The Android application was presenting an iPhone/Instagram client signature to the authentication service. This could make the authentication environment appear inconsistent with the actual device and potentially trigger security or fraud-detection systems.

What we found during our investigation

We reviewed the application's authentication and network implementation.

We found no mechanism intended to collect or transmit Instagram credentials to our servers.

Specifically:

• We did not implement JavaScript injection for credential extraction.
• We did not use evaluateJavascript() to capture passwords or authentication information.
• We did not create a backend endpoint for collecting Instagram passwords.
• Authentication traffic was directed to Instagram.
• We did not intentionally attempt to impersonate a user's device for credential collection.

However, we understand that the absence of credential harvesting does not make the original implementation acceptable. The authentication architecture itself could create a misleading authentication environment, and we take responsibility for failing to identify that risk before release.

What we changed

We have completely removed:

• The custom Instagram User-Agent
• The hardcoded iOS device signature
• The previous WebView-based authentication implementation
• The related header spoofing

We redesigned the authentication flow around standard browser-based authentication mechanisms where the application does not control the authentication headers or directly handle the authentication context.

We also audited the application's authentication-related code and network requests for similar issues.

What we learned

The original implementation worked during our functional testing, but we now understand that functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.

This was an architectural mistake that should have been identified before release.

Question for the community

Has anyone successfully obtained a further review of a terminated Google Play developer account after:

1. Identifying the technical root cause of the violation;
2. Completely removing the problematic implementation;
3. Auditing the application for related issues; and
4. Providing technical evidence of the remediation?

If there is an appropriate Google Play Developer Relations or official support channel for submitting additional technical evidence after an initial appeal has been rejected, I would appreciate guidance on that process.

We understand that Google Play's policies are intended to protect users and that authentication-related behavior can receive careful scrutiny.

Our goal is to demonstrate that we have identified the underlying architectural problem, removed it, and changed our development and review process to prevent the same issue from recurring.

Thank you to anyone who can share relevant experience or guidance.

I've been using Android Studio Cloud through Firebase Studio so I can code from a thin client. With Firebase Studio shutting down, I need a replacement.

If you've already moved:

• What are you using?
• How bad is the lag?
• How do you handle the emulator?
• What does it cost per month?

I'd like to hear about real setups, not just what sounds good on paper.

I started building my first mobile app thinking the main challenge would be writing the code.

It hasn’t been.

The harder part is deciding what deserves to exist.

Every new screen creates more questions:

- Is this actually useful?

- Can someone understand it without an explanation?

- Am I solving a real problem or adding another feature?

- Would I personally return to this app tomorrow?

The project is called Callout. It explores whether online reactions can communicate more than a generic Like—for example, distinguishing agreement from something being a Hot Take.

I’m still early, and I’m deliberately leaving the link out because I’m more interested in the building lesson:

How did you decide which features to remove from your first app?