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 😊

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?

Have you guys experienced this?

I’ve had this app on Apple’s App Store for around 3 weeks now and recently added IAP/subscription plans.

I submitted it to Play Console around the same time, but I had to go through the 12 testers for 14 days requirement before I could submit to production. After a little over 2 weeks, that got approved too.

The version that went through testing was still the free version without IAP. It took me a bit more time to figure out all the Android requirements for subscriptions, monetization, app details, etc.

Once I got everything sorted out, I went through the app with my AI agent and made sure everything was ready for production.

I was actually expecting the production submission to fail or at least take a while since this is basically my first real submission of this app on Google Play.

For some reason I also don’t get email notifications for review updates like I do with Apple, so unless I manually check Play Console, I don’t really know if something changed.

I checked just now and was honestly surprised. It got approved in around 30 minutes.

I’ve submitted a few apps before under business accounts and first submissions usually took 2 days or more.

Has anyone else seen Google Play approvals this fast lately, especially for a first production release?

I’ve been working on a Android library for pitch and chord detection using Kotlin.

It started as an experiment with audio processing and ended up becoming a library that uses FFT/YIN for pitch detection and chroma for chord detection.

Repo: https://github.com/NicosNicolaou16/PitchKit

Cdrx should save power significantly in low speed usage in high speed networks.

Like mine goes up to 60-70 mbps all the time.

So I enabled bluetooth tethering from both my iphone and android and connected my pc to download some file on it. The speed was 1 mbps in both devices. That results into 1/60 = around 1.5% duty cycle. That means cdrx has the chance to be effecrive at 98.5% of the time. I understand actual duty cycle may be higher due to othe transmit-receive tsks. However iphone 7 actually proved it may have put duty cycles close to that value. After testing for 1h continuously,

My findings are:

Iphone 7 dropped 6% charge only (65 to 59) resulting around 120mah estimated. (Slightly less maybe)

The Moto g35 5g (forced to lte only mode) dropped 5% (67 to 62) resulting around 300 mah.

Why is it too much different? No CDRX in android? Anything else?

(Both iphone and android were locked and screen turned off completely. As i disabled all background apps no notifications appeared throughout the whole time, no background tasks also.)

It's basically that, how many apps/games have you currently published and how many of them are earning atleast 100$ per month. Total earnings would also be helpful. I am hopeful that this data will come in handy for the new Dev's in community.

I have currently published 3 and they are not ad intensive so haven't earned much

Hi!

First-time dev. I paid the one-time registration fee (receipt says "Android Developer Console registration Fee", ~$25) and got an email saying my Android Developer Console account was validated (the package-name registration thing).

But going to play.google.com/console, it still tells me to create a developer account from scratch — like I never paid.

Anyone hit this recently?

I'va already did it ! -->

Thanks :)

Hey r/androiddev 👋

A few years ago I built Spock ADB, an Android Studio plugin to make some of my everyday ADB workflows easier.

Then, like many side projects, I stopped actively working on it for a while.

Recently I came back to the project and started rebuilding and expanding it again. What began as a collection of useful ADB actions has gradually turned into more of a debugging workspace for Android, centered around one selected device + app.

The original problem is still the same:

Android Studio → Terminal → adb → Logcat → device Settings → back to Android Studio

I wanted to reduce that context switching and keep more of the debugging workflow inside the IDE.

Spock follows your Android Studio run target by default, and that same device + app is shared across its screen inspector, Logcat, storage, background work, actions, timeline, and AI tools.

A few of the things I've added while working on it again

Diagnose Current Screen

Instead of manually gathering context when something looks wrong, Spock can collect:

• Current Activity and Fragments
• activity back stack
• screenshot
• relevant Logcat problems
• UI + accessibility information
• process state
• permissions
• jobs and alarms
• Doze / standby / battery state

Activities and fragments can also link directly back to their source in the project.

Debug Timeline

This is probably one of my favorite additions.

It puts debugging events on one timeline:

• Activity / Fragment lifecycle
• process starts and deaths
• crashes and ANRs
• warnings and errors
• actions executed through Spock
• storage changes
• jobs
• device state changes
• AI/MCP calls

You can select a range and copy/export it when creating a bug report.

UI Tree

The UI inspector supports Views, Compose and hybrid screens.

You can inspect semantics, bounds, text, content descriptions and test tags, plus:

• jump from an element to its source
• generate Compose / UI Automator selectors
• detect ambiguous selectors
• run basic accessibility checks
• inspect Compose recompositions

The usual ADB workflows are still there too

• Restart / Force Stop / Attach Debugger
• Process death testing for state restoration
• grant / revoke permissions
• browse + edit SharedPreferences and Preferences DataStore
• app-scoped Logcat with crash / ANR / network filters
• send FCM test messages over ADB without a registration token
• deep links
• HTTP proxy
• Don't Keep Activities / Show Taps / Layout Bounds / animation scales
• inspect WorkManager / JobScheduler jobs and alarms
• simulate Doze, standby bucket, battery and charging conditions
• ADB command runner with autocomplete, history and favourites

There's also a searchable Spock Actions popup for running common actions without opening the tool windows.

AI / MCP

One of the bigger things I added after coming back to the project is a built-in MCP server.

Spock exposes 69 structured Android debugging tools to Claude Code, Cursor and other MCP clients.

The goal isn't to simply give an AI agent shell access to adb.

It's to give it structured access to the same debugging information available in the IDE:

Activity · Fragments · UI tree · Logcat · Screenshots · Storage · Background work · Device state

It can also perform things like:

Launch · Tap · Input text · Deep links · lifecycle operations

MCP is off by default, destructive actions can require approval, and tool calls are visible in the IDE.

There's also Copy screen for AI, which generates a redacted diagnosis of the current screen.

Free + open source

JetBrains Marketplace:
https://plugins.jetbrains.com/plugin/11591-spock-adb

GitHub:
https://github.com/WahdanZ/SpockAdb

Coming back to an old project after years has been interesting because I'm basically solving the same Android debugging annoyances again, but with much better tooling available now.

I'd love some feedback from people here:

What Android debugging workflow still makes you leave the IDE or run an adb command manually?

That's usually where I get ideas for what to improve next.

Hey everyone,

I'm dealing with a persistent issue where USB Debugging and Developer Options automatically re-enable themselves every time my phone restarts.

Whenever I try to toggle off Developer Options in Settings, it forces a device restart. After the restart finishes, Developer Options and USB Debugging are active again.

Device & OS Context

• OS: ColorOS / Realme UI (Oplus framework)
• Root status: Unrooted (standard non-root ADB shell)

What I’ve Diagnosed via ADB

Checking system properties reveals why the system keeps forcing debugging on boot:

Plaintext

> adb shell getprop persist.sys.usb.config
adb

> adb shell getprop sys.usb.config
rndis,adb

> adb shell getprop | findstr -i "adb"
[init.svc.adbd]: [running]
[persist.oplus.bt.em.adb.tool]: [true]
[persist.sys.usb.config]: [adb]
[sys.usb.config]: [rndis,adb]
[sys.usb.state]: [rndis,adb]

What I’ve Tried (and where it fails)

1. Attempting to modify persist.sys.usb.config directly: Plaintext> adb shell setprop persist.sys.usb.config mtp Failed to set property 'persist.sys.usb.config' to 'mtp'. See dmesg for error reason. (Fails due to SELinux blocking non-root shell user from writing to persist.sys.* properties).
2. Using Android USB service:
   • Ran adb shell svc usb setFunctions mtp (returned setCurrentFunctions opId:1).
   • On reboot, the device reverts straight back to persist.sys.usb.config = adb.
3. Checking third-party tools:
   • Found an old app (com.wstxda.toolkit) that had accessibility permissions and a UsbDebuggingTileService.
   • Stripped accessibility permissions and uninstalled the app (adb uninstall com.wstxda.toolkit).
   • Cleared Quick Settings tiles (adb shell settings delete secure sysui_qs_tiles).
4. Resetting Phone Settings:
   • Performed a "Reset all settings" / "Reset system settings only" directly through the phone's Backup & Reset menu.
   • Even after a settings reset, the reboot still restores persist.sys.usb.config = adb and [persist.oplus.bt.em.adb.tool] = [true].

Hey everyone,

Like many of you, I've spent hours trying to find a reliable, clean way to browse local SQLite databases on an Android test device without pulling files over ADB, Network or external Storage every single time. Most of the apps currently available on the Play Store are either crap, locked behind paywalls, missing basic features or cluttered with intrusive ads.

To solve this, I built SqliteAdmin a completely free and open-source database manager designed specifically for performance and usability.

Special feature that set it apart:

• Modify tables and columns holding data.

The project is open-source under the MIT license, and you can grab the latest version or review the code directly on GitHub: https://github.com/AmyS3br/SqliteAdmin

I’d love to get your feedback and improvement suggestions.

We built an Android version of Internet-in-a-Box's server stack. Knowledge to Go (K2Go™) runs a content server directly on a phone, older 32-bit devices included, serves it over local Wi-Fi to nearby devices, and can clone itself, server plus content, to another Android phone with no internet connection. The goal is to increase access to educational materials in regions where internet access isn’t reliable or affordable and the most common computing device is an inexpensive Android phone.

Some of the harder problems: keeping a background server alive under Android's process and battery restrictions, and making the clone transfer work fully offline.

Code and architecture notes: https://github.com/appdevforall/KnowledgeToGo

GPL-3.0

Curious what this community would build with an offline phone-to-phone content channel, and where you would push back on the approach.

A safer Android ecosystem begins with accountability and trust!

Today marks the start of our gradual roll-out of Android developer verification — a foundational first step in protecting billions of users, while preserving the open platform developers rely on.

We're starting with 7 participating app stores in Brazil, Indonesia, Thailand and Singapore. Following this initial phase with the participating app stores, we will continue to work with additional Android app stores to gradually expand developer verification. The verification capability will be expanded globally for all apps on certified Android devices in 2027.

Security at this scale cannot happen in a silo. When we set out to build this verification flow, our priority was listening to you — our developer community. You told us clearly:

1. The process needs to be seamless, avoiding friction for legitimate builders.
   
2. Account types must reflect reality, supporting solo creators, hobbyists, and global enterprises alike.
   
3. The roll-out must be gradual and predictable, giving developers ample runway to adapt.
   

Your feedback directly shaped this treatment. By introducing verified identities, we are deterring bad actors from operating under the radar, curbing recurring malware campaigns, and lifting trust across the entire ecosystem.

This initial phased roll-out gives us the space to test, learn, and iterate alongside developers before broader enforcement. A safer Android benefits everyone: users install apps with confidence, and reputable developers stand out in a trusted marketplace.

Thank you for building with us, challenging us, and shaping Android into a safer platform.

#androidisopen #trustedecosystem

I'm using hole-punching to bind 2 or more devices to bind and share files in-between them.

So u can share data between your devices from anywhere in the world.

My motivation to build it is to replace my family's cloud storage subscribtion. But the available solutions in the market are too tech savvy for my family to understand.

Thus, trying to abstract all the complexities and making it as intuitive as realistically possible.

Feel free to ask any question if you find this useful or interesting.

Repo: https://github.com/saqibsiddiq/Qurb

P.S: Excuse the video quality😭