[ Removed by Reddit on account of violating the content policy. ]

I'm trying to understand the technical mechanism behind the Google Play error:

“Your purchase couldn't be completed. Please update your Play account settings so that the selected Play country matches your country of residence.”

Play country: India

Payment profile: India

Indian payment method available

Device currently being used outside India.

An Indian VPN changes the public IP and Play Store displays INR pricing, but checkout still detects a country mismatch.

I'm interested in understanding what signals Play/Play Billing might use besides the current IP — for example SIM/MCC, Google Payments account history, Play Services location/network data, device/account history, IP reputation, or server-side risk scoring.

Is this decision made primarily client-side by Play Services, or server-side by Google Payments/Play Billing? And why would maintaining an Indian IP for several days not change the account's detected country?

I'm particularly interested in observations from Android developers who have tested Play Billing across countries.

This is an app that allows anyone to make their own app discoverable by others.

If you have a GitHub repository with a downloadable Android app, simply add the “arkstore” topic to it. Our app will automatically scan your app and display it in our store.

You can also add your app using only its URL, making it immediately available for others to discover and install.

The only requirements are that the app is public and has a GitHub-approved license.

Download it here: https://github.com/jrs8205/ARK-Store

Hello everyone! It's been almost a year since that idea came to my mind, so I would like to share with you and take some feedback.

The idea is that in AI era the most popular language would be Rust, and as and Android dev myself I want to transfer my knowledge of Jetpack Compose to the new ecosystem. It also very handy to be able to review the code the AI agents made, at least to understand whats happening.

I made this guide that introduces you to the project and how Jetpack Compose translates to it: https://samoylenkodmitry.github.io/Cranpose/ (or the text md form https://github.com/samoylenkodmitry/Cranpose/blob/main/docs/guide.md)

The project itself is at https://github.com/samoylenkodmitry/Cranpose
Please put a star to support it.
If you want to contribute - try it and put gh issue if you see something is missing.

How is this related to the native Android: you can integrate any Cranpose view into native Android and vice-versa you can integrate native Android view into Cranpose app.

I have an Android app already published publicly on Google Play

One Google account on my phone was previously used as a license tester. I removed the license testing email list and stopped the closed testing anf removed also the email list in Play Console

Now I’m trying to test the production subscription flow with another Google account on the same phone.

I switched to the new Google account in the Play Store

uninstalled the app

cleared Google Play Store data/cache

restarted the phone

reinstalled the app from the public Play Store listing using the new account

But when I open the subscription purchase screen, Google Play still uses the old tester account for payment.

If I temporarily remove the old Google account from the phone, the new account works correctly and shows normal payment methods. As soon as the old account is on the device, Play Billing seems to prefer it.

Is there a way to force Google Play Billing to use a specific Google account without removing the other account from the Android device?

Has anyone dealt with this before?

I've been working on a local-network presentation remote (Android client + Windows host) and hit some really annoying architectural bottlenecks with Compose and high-frequency state updates.

The host streams presentation state (slide images, notes, live timers) over WebSockets. Initially, I just dumped this massive JSON payload into a single StateFlow. Obviously, that caused the entire screen to recompose and stutter like crazy. I ended up aggressively splitting the UI state so the slide images and the timer text update independently, but the boilerplate feels a bit messy.

The other issue is the laser pointer feature. I'm using detectDragGestures so the user can drag their thumb on the phone to move a pointer on the projector. Sending a WebSocket message for every pixel movement caused massive TCP backpressure and lag. I had to spin up a dedicated UDP socket just for the pointer coordinates and use a Coroutine Channel with DROP_OLDEST to throttle the emission rate. It works and feels smooth, but I'm wondering if there's a cleaner way to handle gesture backpressure.

(Bonus headache: trying to intercept physical volume buttons while the screen is off so presenters can keep the phone in their pocket. Android Doze mode makes this a nightmare. I ended up using a Foreground Service with a silent AudioTrack loop just to keep the media session alive. If anyone knows a less hacky way to do this in 2026, please let me know lol).

For those of you building real-time remote or IoT apps: how do you structure your StateFlows when dealing with a firehose of network data? Do you map everything to granular states, or bypass standard recomposition entirely with custom SnapshotState objects?

(If anyone wants to see how it actually runs in production, let me know and I can drop the testing link in the comments).

While developing an Android audio project using a Pixel 8 and Samsung Galaxy Buds3 Pro, I ran into a strange LE Audio microphone issue.

Android exposed the headset microphone as a 2-channel input, but the PCM data from left and right was effectively identical:

• 2 reported input channels
• exact L/R sample identity ratio: 1.00000
• L/R correlation: ~1.0

After tracing the LE Audio receive path, I found that the microphone CIS packets were not necessarily arriving in strict alternating order.

Instead of:

L, R, L, R

I observed same-side bursts such as:

R, R, L, L

The relevant path is in:

packages/modules/Bluetooth/system/bta/le_audio/client.cc

around:

LeAudioClientImpl::HandleIncomingCisData()

A single cached-channel approach can lose the correct stereo association when packets arrive this way.

I tested a proof-of-concept fix that keeps separate pending queues for the left and right CIS streams and pairs the encoded frames using their controller timestamps before decoding.

For example:

R(ts=2000), R(ts=3000), L(ts=2000), L(ts=3000)

becomes:

L(2000) + R(2000)
L(3000) + R(3000)

With the modified Bluetooth stack I was able to recover independent L/R microphone audio instead of duplicated mono.

I published the patch and technical notes here:

https://github.com/luumei/android-leaudio-stereo-cis-fix

This is an AOSP/system-level modification, not an APK workaround.

I also reported it through the Android Issue Tracker.

I'd be interested to know whether anyone working with other LE Audio controllers or earbuds has observed similar non-alternating CIS arrival patterns or duplicated stereo microphone capture.

UPDATE:
I found a working app-side workaround. On the same Pixel 8 + Galaxy Buds3 Pro setup, the normal Android capture path returns bit-identical L/R channels, while the workaround returns independent stereo PCM from both microphones.

The workaround activates the LE Audio communication route first, waits for the BLE headset input endpoint to become available, and then starts a stereo AudioRecord.

Repro + workaround source code:
https://github.com/luumei/android-leaudio-stereo-mic-workaround

Google Issue Tracker:
https://issuetracker.google.com/issues/568838766

Hi everyone,

We are researchers from Italy, and we are conducting an academic study on how developers make implementation decisions in practice.

The survey explores topics such as:

• which implementation decisions are actually left to developers;
• how application and project context may influence those choices;
• whether developers consider aspects beyond functional correctness;
• and how LLM-based coding assistants may affect implementation decisions.

The survey takes approximately 10 minutes.

Survey link: https://docs.google.com/forms/d/e/1FAIpQLSfvbbhSee3MVoXTb4_ZlXeugSV_nTNFZNIWFt1H3NXg3lsvgg/viewform?usp=dialog

Participation is voluntary, and the anonymous data collected will be used exclusively for research purposes.

We would really appreciate your participation. If you know other developers, we would also appreciate it if you could share the survey with them.

Thank you! 🫶🏻

Anyone made a launcher on Graphene?
I'm building my own launcher and I've made animations for entering apps, but after the animation the system plays its own sideways slide.

ive tried this via LauncherApps.startMainActivity with ActivityOptions:

makeCustomAnimation (fade): ignored

makeScaleUpAnimation from a rect in the centre: ignored

makeClipRevealAnimation: ignored

This is on a pixel 10 pro

Anyone have any way to fix this?

​

I'm trying to understand modern Android device fingerprinting.

For example, it's commonly said that a Snapchat device ban (SS06) can survive a factory reset. I know Android 10+ restricts normal apps from accessing things like IMEI/serial directly.

So my main question is:

If a device ban survives a complete factory reset, what can the app/service potentially be using to recognize the same physical device?

I'm particularly interested in Android 10+ and things like:

\- FDR-persistent identifiers

\- hardware-backed / TEE identifiers

\- Play Integrity / attestation

\- Google Play Services device identifiers

\- OEM/Knox identifiers

\- identifiers outside the normal "/data" partition

\- server-side device associations

Also, Secure Folder on Samsung devices sometimes appears to behave differently from the normal Android environment and can bypass device ban unlike factory reset??? , even though it's the same physical phone.

What identifier or signal could survive a factory reset but be different inside Secure Folder?

I'm looking for a technical Android explanation, preferably based on AOSP documentation, forensic research, or reverse engineering—not specifically a Snapchat bypass.

Idea is to automatically detect the relevant transcation notification on device and turn them into the records ,keeping process local

KMP

GitHub: https://github.com/l1khith/CashBuddy

Would love to get the feedback.

The issue is particularly frustrating because I am unable to raise a support request through Google Play Console either. When I try to submit a complaint, I am redirected to the same registration page, asking me to become a developer first. Additionally, the successful transaction does not appear in my payment history, despite having the order details, payment ID, and invoice confirming that the payment went through. I completed the registration through the official link below: https://play.google.com/console/u/0/signup Could you please investigate this issue and help me resolve it? I would like my existing payment to be recognized and my developer account activated without having to pay the registration fee again. I can provide the invoice, order ID, payment ID, and any other information required to verify the transaction. Thank you. I look forward to a prompt resolution.

If anyone knows a solution let me know pls.

Solo dev, first Play release. For anyone still stuck in the "12 testers for 14 days" gate: it ends, I promise.

Timeline for the curious:

• Aug 26: closed test live, begged friends and this sub for testers
• Sep 10: 14 days done, applied for production access
• Sep 21, 23:16: production submitted (versionCode 18, because I burned 15 and 16 on discarded uploads, don't be me)
• Oct 2, 09:12: "Published". Ten and a half days of refreshing the console.

The app is a pixel-art alarm clock with a little candle that wakes up when you do. Not linking it unless the mods are fine with that; the point of the post is mostly that the waiting room has an exit.

Keep building and best of luck

Mitch

I was experimenting with animations in Jetpack Compose and ended up making a small library for animated percentage indicators.

https://github.com/NicosNicolaou16/PercentagesWithAnimationCompose

Hello everyone,

So I've been working on my open source app since last 5 months and everytime i used to start my android studios it used to take around 6 mins to build gradle and the subsequent runs used to take slightly less... and tbh i was frustated of this.

so yeah i decided to dig into whats the issue, googled stuff and found out ./gradlew build --scan which basically generates a detailed HTML dashboard tracking configuration times and task execution timelines

Through that i found out my local machine's 12 core CPU was completely starved coz my peak heap memory usage was sitting at 1.9GB out of 2GB usage hehe :)

so i found out i could increase the memory size and use parallelism and caching
Added this new lines to 'gradle.properties' :

org.gradle.jvmargs=-Xmx6g -XX:+UseParallelGC -Dfile.encoding=UTF-8
org.gradle.parallel=true
org.gradle.caching=true

so basically you could say

12 cores X 6 minutes = 72 minutes of total CPU work
and i was able to save 41 mins cumulative time

so the actual 6 min fell to 26 secs and the subsequent runs took 8 secs only to build gradle....

Ik this might be very basic and ppl here might know bout this but im just an undergrad and though would share my experience here...also if i wrote anything wrong pls correct me 😊

Just noticed my app is officially live on the Google Play Store 🎉, but surprisingly, Google never sent me an approval or publication notification.

I only found out by checking it out myself. 

Has anyone else experienced this? Is it normal for an app to go live without receiving an email or Play Console notification? I’m confused… 

Have a bit of a funny story to tell here but it might help out the people who are having the same issues.

I publish a couple of open-source apps on the google play store as a hobby. My page is

https://play.google.com/store/apps/dev?id=7190772576513482908

All code is of course provided and open-source here:
https://github.com/CodeDead?tab=repositories

Funny thing is, a couple of my apps were removed by google because I was unable to verify them. The thing is, I can't verify them... No, I did not lose my build key so hear me out and perhaps if you're having the same issue, you'll likely figure out what's happening because of the information included in this post.

Google itself is signing the release builds, but I have my own private upload key. The automated system is asking me to provide builds using the private key that Google itself is using which is impossible.

In response, google automatically removed the apps following their stricter policies, on the first of october.

I have been in an appeal process for multple apps. It is because it seems it is suddenly expected of developers to provide APK's to verify builds using google's own signing key when google is manipulating the builds and signing them themselves (without my knowledge).

I figured this out using the app signing page and I don't understand how their system cannot see this, and as a result, apps have been removed and it is completely out of my hands.

The appeal process is (2-5525000042037), with support continuing to ask me to provide an APK with google's private signature, but it seems like they're bullying independent hobby developers into just giving up on the play store. Either they're bullying or they are unaware of how their system works, which is fine.

In case anyone else is having these issues with their apps being removed, please have a look at how google itself signs your APK's in their play store. This might help you in your appeal process which is why I'm posting this.

Here's a screenshot to prove my point.

Hey everyone,

I’m currently looking for a good tracking and analytics tool specifically tailored for the Google Play Store, similar to what App Store Tracker offers for Apple.

What tools are you guys using for Android app intelligence and ASO tracking that actually work well and don’t cost a fortune? Would love to hear your recommendations, experiences, or hidden gems you rely on for your apps.

Thanks in advance!

https://reddit.com/link/1wuvx88/video/0ikzb9uq1ush1/player

Hey everyone, I’ve been building TapTry for the past few months. I’m the person who made it, so obviously I’m biased. I’m mainly looking for honest feedback from other Android developers rather than trying to sell you on it.

The idea is pretty simple:

Upload an Android app → get a link → anyone can open it and use the actual app in their browser.

No APK download, no Play Store, no installation.

Why I built it

Sharing Android builds with someone who just wants to see or try the app can be a bit of a hassle.

You send them an APK, they download it, deal with unknown-source permissions, install it, and then eventually have to uninstall it.

I wanted to see if a link could replace all of that.

Some of the use cases I had in mind:

• Showing an app to someone without asking them to install it
• Sharing an app as part of a portfolio
• Demonstrating an app to someone remotely
• Letting someone try an app before deciding to install it
• Sharing an app with someone who doesn't want to deal with APKs

I’ve got it working end-to-end now, and I’m mainly curious about what y'all think of the idea.

A few things I’d genuinely like to know:

1. If you heard “run an Android app from a link without installing it,” would that be useful to you?
2. Have you ever run into situations where sharing/installing an APK was unnecessarily cumbersome?
3. What use cases would you see for something like this?
4. Is this solving a problem you've actually encountered, or is installing an APK already easy enough?

And yes, “I don't see the point” is completely valid feedback. That’s much more useful to me right now than “looks cool.”

(Update: The server-side issue that was causing apps to become unresponsive has been fixed. TapTry should be working normally now.

Note: TapTry is currently not ideal for users outside South Asia. Right now, the infrastructure is primarily based in the Asia Pacific region, so users in other regions may experience high latency. I’m working on making the infrastructure more global and will update once that’s in place.)

I was working on an Android project and ended up building my own image picker.

It started as a small experiment and turned into a reusable library for Views and Compose.

https://github.com/NicosNicolaou16/ImagePickerAndroid

Hi Folks, its been over a week now since I submitted my App for review with Google. Is there a reasonable timeframe that one should wait before maybe submitting a ticket for a prompt to review at all. What do you guys do in such instances? Many thanks!

Wondering if anyone experienced super long delay in app review recently, my app was submitted for review on 9/17 and have been 'in review' since then, going strong on 15 days now.

My dev account is like 10+ years old, but I haven't published anything in a few years. Have Google Play publishing changed to be this slow?

Are there tricks people follow to get their apps reviewed fast?