r/androiddev

I checked the Aptoide documentation. My reading of it was that Google Identity Verification is only necessary to have your app continue to work on 'genuine devices'. My assumption is that after Sept 30th they'll have a genuine badge on the store and filter your app from genuine devices.

The Aptoide-Connect guide says this:

>'Register every package name you distribute so your apps stay installable on certified Android devices once verification is enforced for the stores and channels you use - see the rollout below.'

[...]

>What happens if I don't complete it?
Once verification is enforced for a given store, region, and channel, apps that are not registered by a verified developer can be blocked from being installed and updated on certified Android devices

The AptoideConnect APK submission form however suggests that its mandatory?

>Verify your Android developer identity
Required by Google for alternative distribution. Complete the verification steps to proceed.

Clicking the 'I Have Already Done It' button 403's without any visual feedback. For new app distributions is this crap already required now?

I will definitely contact support and update my post regarding this issue 'cuz I'm not wasting time filling out the entire form just for this to be a blocker. Hope this can help others choosing what app store they want to distribute on

I would be disappointed if a major 'alternative' appstore played ball with google

I have been currently assigned a project which needs to be cross platform + dynamic feature delivery (business requirements)

I'm thinking about writing my feature modules/business logic in rust to create native binaries which I can include with the android and IOS build and then include those .so/.a files with the build and communication between them will be from ffi (don't know which ffi approach works best raw JNI, UniFFI, or hand‑rolled C ABI)
Apple doesn't allow dynamic features installation so only android build will have that, IOS will just install everything at once
For UI I'm thinking to either go with Compose Multiplatform or just Compose for android side and Swift UI for IOS side (The app only has 3 screens so ui doesn't really matter as most features work in background)

Has anyone tried anything similar , where should I start experimenting, I don't want to waste time in approach that will be in vain, would love to hear your experience.

PS: Using rust as equivalent windows and MacOS app is also made in rust + imgui and I can use lots of code from there to make mobile app dev easier

I work at Gradle, and we're building agent skills. We currently have five candidates:

1. Run Gradle correctly (gradle-cli) — right task, right flags, version-aware
2. Best-practices lint (gradle-bestpractices) — flag legacy patterns, suggest the current one
3. New project bootstrap (gradle-init) — Android/KMP scaffold, version catalog
4. Upgrade + deprecations (gradle-update) — bump the wrapper, rewrite what broke
5. Configuration cache migration (gradle-cc) — find what breaks CC, refactor it

Which would you actually use? What do you want to see instead?

[removed]

I am making an Android math game in Kotlin with Jetpack Compose in MVVM architecture. Right now it is currently local-only using SharedPreferences for testing purposes, and I am looking to add a backend for cross-device sync and login, with it coming down to Firebase and Supabase. I am leaning more towards Supabase but the AndoidSDK part is the one part I am mostly unsure about.

I am leaning more towards Supabase because the main feature is using teacher viewing class reports on how students did, which is one big reporting screen which I saw could potentially be quite a bit expensive with firebase, as it is billed per read, whereas on Postgres it's a single join with a group by. The data is also relational as it is teacher, class, students, etc. and I will not store almost anything by students on purpose, except their first name, which is easier with Supabase.

It seems to favor Supabase but what I want to know is:

Does the flow and coroutines integration work cleanly in a compose app, or are there issues like lifecycle or reconnection issues once you get past a demo? How reliable is realtime compared to firestore? Any issues or things to know about when the persistence across the app restarts? If I hit a strange edge case would I have to dig through a library source?

I am a little worried that I would save money on the reads and then I would lose just about all that time fighting an immature client. If anyone has shipped an app on supabase-kt, would you do it again, or would you go a different direction? Or perhaps there is something I am missing about Firebase, and if so, I would love to know.

I recently soft-launched a new utility/security app on Google Play and am doing some in-my-network outreach to test build stability before my main launch.

I’m collecting anonymous telemetry data, including unique users and simple activity metrics (just firing a hashed device/session ID on first launch for internal telemetry). So far I have ~8 distinct active installs over the past week.

But on my Google Play Console, the dashboard and acquisition stats are still sitting at a flat 0, and Reach metrics, Android Vitals, Ratings and Reviews all show "Data unavailable."

I know batch processing, UTC timezone rollups, and anti-fraud filters mean Play Console statistics lag anywhere from 24–72 hours (or even longer for fresh apps/accounts without a baseline traffic volume). I also know Android Vitals requires a minimum sample size of users opted into "Usage & Diagnostics" sharing before anything populates.

Support mentioned it can take several days or SEVERAL WEEKS to catch up on a new listing, but I’m curious about real-world developer experiences here:

1. How long does it typically take Play Console to start displaying initial install numbers for a brand-new package ID?
2. When you do soft launches or pilot runs, what custom telemetry or analytics setups do you rely on for real-time visibility instead of waiting on Google’s pipeline?

I’m interested to hear how folks here handle early-stage launch tracking without relying purely on Console stats!

Thanks for any feedback

Hi Everyone,

I have a question on how to approach the situation im currently in.

I got a software developer role in a banking solution company which uses mifos opensource tools and im currently working in the mifos Android client .

I have basic understanding and basic knowledge of android development i learned from udemy and youtube but i was just given a massive codebase which uses concepts i dont know and it overwhelming me.

So, I need guidance from experienced professionals how did you tackle this situation or how will you do it to get a better understanding of Codebase and improve my skills and develop quality code .

Also im a beginner,so if you dont understand my question feel free to ask for clarification i will provide it and help me to get a better understanding of Android development itself and how professionals do their work.

Thankyou

Hello everyone!

Im a solo dev based in Morocco, and I built an app and I finished all the steps to publish. I had wired in in-app-purchases (1 time fee, pro forever) there is no subscription or anything like that. Then when I went to configure my merchant account to collect payments, Google stopped me because that isn't allowed in Morocco.

I can run ads with admob or 3rd party providers, but I can't use google play payments or sell the app for a price on Google. I can just do "free with ads".

I personally HATE ads, especially ones that breka immersion (full screen), I do have another game that uses ads but it is 100% optional and you can literally finish the game in a couple of hours without seeing a single ad. No timers, no special currency or any crap like that.

Back to my app. I really do not want to use ads in the app, (I will if it's my last resort) but I prefer a one and done payment.

After some research I found a couple of workarounds but they're all tedious:

1. Setup an LLC in the UK or US or Estonian digital residency and create a new account. 200 - 500 Euros minimum in fees plus a lot of extra work at the start, and more work to maintain that.

2. Build a website with the entire functionality and users can manage their "license" through there. Less tedious than LLC route, but I do have to create and maintain a whole separate branch of my app. Also it takes the users out if the app, and requires paying outside on a separate website and I think that will cause people to trust it less, so less conversion.

3. Have a relative or a friend abroad open another Google play account and transfer ownership. Easiest, but also a huge risk. I don't plan on the app making 1 million dollars on year one, but still it's a risk to consider if I get in a dispute or something were to happen to that person, especially since they're in another country.

4. Accept my faith, redo the whole thing and use ads and just accept that I can't give the same clean pro experience and my users just have to deal with it because "everyone else does it"

What are your thoughts people? What do you think is of the best option for me? Did I miss something? And is there someone in a similar situation that found a better workaround?

I teach Introduction to Android Programming at a community college. I stress to my students the importance of learning the basics to build a foundation of knowledge in terms of developing apps, writing in Kotlin, designing app architecture, etc. At the same time, I do allow them to use AI tools because I also understand it's important for them to know how to do that. (I ask that they use them to help, not do.)

If anyone has any advice or words of wisdom to pass along to my students (who are new to Android), please share. In particular, I am hoping to reinforce the importance of learning the material for themselves (rather than relying on AI to do it for them) at this early point in their development.

I truly believe they have to learn the basics in order to be able to successfully use AI tools down the road. If anyone has any real-world anecdotes or thoughts that back this up, please share! (Or, if you disagree or have stories that contradict this, I'd love to hear those, too!)

Thanks in advance.

in our mid sized startup, we have over 100 android engineers on one app, divided by squads, so we have a lot of squads, each one is working on a feature, a library needed, design system and custom components libraries etc, all these modules/libraries are published to maven and added as dependencies on the core app repo, my squad works on an isolated feature so it's easy to integrate into core app repo, but i attended guild meetings and saw RFCs mentioning circular dependencies, hexagonal, onion, plugin etc architectures because some modules/libraries depend on each other, communicate with each other, initialization order problems of modules etc etc etc, i feel stupid tbh and i'm glad i'm working on an isolated feature library in which we use usual architecture stuff. anyone has resources: talks, books, articles etc that cover this kind of topics and architectures and engineering problems in big scale apps with big scale teams and modules/libraries?

I'm genuinely curious how teams are handling this in larger apps, because I'm not convinced we've fully solved it.

Before Compose, MVVM/MVI gave us a fairly clear direction: keep the screen state in the ViewModel, expose it, render it, test the transitions.

With Compose, we now have local state, state hoisting, state holders, StateFlow, snapshot state, rememberSaveable, and plenty of different ways to split ownership.

That flexibility is useful, but on a large screen it can also get messy pretty quickly.

If you keep everything in one UiState, it can become huge and start coupling unrelated parts of the screen together.

If you split state too much, you can end up with ownership spread across the ViewModel, composables and state holders, which can make the screen harder to reason about as a team.

Then testing adds another layer. What do you keep centralized because it makes behaviour easier to test? What do you leave local because it is really just UI state? Where do side effects fit without turning the ViewModel into a coordinator for every tiny interaction?

I don't really have a strong answer here.

For people working on large Compose codebases with multiple engineers:

How are you structuring state today?

One UiState per screen? Multiple state objects? State holders? Mostly ViewModel state with some local Compose state?

And more importantly, has that approach actually held up well for testing, maintenance and team ownership?

Sometimes I wonder whether Compose solved the old state-management problems, or just gave us more ways to distribute them.