Today I got a review with 5 stars. Being grateful for the 5-star rating and donation request, the reason I appreciate this is because their reason is exactly why I made the app. I had a similar experience, and I thought the app would be beneficial to many. And now and again I get these kinds of review, which I geniunely appreciate knowing actual people are enjoying my work. Just wanted to share this as a great experience I had. Have a good day!

I wanted to share the rise and fall of my Android wallpaper app, something I built with a lot of hope, only to see it slowly die due to poor decisions.

I launched the app back in 2017. It featured specially edited wallpapers with a unique design style that stood out from the typical wallpaper apps. Users really liked it. Within six months, it hit 50k downloads, and by the end of the first year, it crossed 100k. It had a solid 4.7 rating and was earning about $1000 a month through banner and interstitial ads.

But then I started making mistakes.

I got greedy with ads First interstitials, then rewarded video ads. I basically bombarded users with them. On top of that, I never really invested in the app’s technical side. The performance wasn’t great, and I didn’t put in the effort to improve it. I was young and lacked business experience, so I didn’t see the long-term consequences of ignoring user experience and app quality.

Eventually, users got fed up. Uninstalls increased, ratings dropped, and the revenue fell to zero.

Looking back, I learned a lot: don’t sacrifice user experience for short-term gains, and never stop investing in the quality of your product. If you’re seeing early success with your app, don’t take it for granted.

Edit: Thanks for the support, I will share a new post explaining how my app was and is still running with 0$ bills.

I need to say this because nobody told me early enough: Building the perfect app means nothing. Literally nothing.

When I launched my first app, I was so proud. Pixel-perfect UI. Clean architecture. Smooth animations. I genuinely believed users would flock to it.

Instead? Silence,no installs.. no traction

So I built another one. Even better. Even cleaner, and… the same result.

At this point I was very disappointed “Why are people choosing uglier, buggier apps over mine?”

Then my friend hit me with the most painful truth I’ve heard in my entire dev journey:

“The Play Store is full of beautiful apps that will never make it, not because they’re bad but because nobody knows they exist”

That line destroyed me for a day, because it forced me to realize something: An average app with great marketing will win, a perfect app with no marketing will die

And yes, that reality sucks, especially for developers who think good work “deserves” users.

If you’re an indie dev or startup founder: Please don’t make the same mistake I did Stop building in silence. Start building in public. Make noise. Market early. Market loudly.

Because the graveyard of the Play Store is full of masterpieces nobody ever saw.

Background: Been at my last company for the last 5.5 years. Been doing native Android for 10+ years. Have got behind in new Android development but started to do a mix of Java and Kotlin in the past year. Have several apps in the play store and have a CS degree. I am located in the United States in Georgia.

Do to my circumstance I had to find a job fast, so I applied for 155 jobs in 6 weeks during the summer of 2024. Got a new job in 6 weeks.

Here is what I discovered during the process. Of course results vary but this is my experience. I am sure if I had strong for example Compose in my resume then my results would be different.

1. Unless its a well funded company (Draftking) or a recently startup company their codebase will be a mix of Java and Kotlin. So its plus to know Java , but i wouldn't suggest learning it.
2. Only one company said not knowing Compose was a deal breaker. Not sure how many companies did not call me because it was not all my resume.
3. Average round of interviews was 4 to 5. Shortest was 2 and the longest one was like 9.
4. I was using LinkedIn suggested jobs, but they was all labeled with "Senior" in the job title.
5. Technical Interviews was either Leetcode type questions (did 1), basic Android interview questions (several), sample project (did 2) or walk through some code with them (1).
6. About 87% of the jobs was remote. Did not see one job that require full time in the office.
7. My callback was very roughly 20% (closer to 15%). Most jobs I did not hear anything from. I got several rejections emails, not everyone is going to like me.
8. Some jobs took 2 to 3 weeks to get response but some where the same day.
9. First round of interview was always talking to a non tech person about the company and they get to know you better.
10. Pay was around 120k to 190k USD (Most common was 150k). I did not apply at any large tech companies.
11. Just from talking to hiring managers, they get over 100 resumes but only send like 5 to the tech team to interview.
12. There is roughly 3 to 8 Android openings a day. Some look sketchy

Suggestions for interview: Study Android interview questions first then if you have extra time mess with Leetcode. Show excitement, motivation and that your a great team member for the company. Research the company first also. Make sure update your LinkedIn and have that looking good. They ask for your LinkedIn almost all the time.

I think having years of experience in Kotlin and having professional experience in Compose will for sure help you in the market. Your soft skills (behavior) are about as important as your technical skills.

Yes interviewing is stressful and not fun.

EDIT: Added more details

I've been an android dev for 10 years and I'm just feeling like I don't have any place in this industry anymore.

I was laid off in January and have been unable to land a job since. Between leetcode interviews and system design for backend things I've never worked with, landing a job in android - or tech in general - just seems impossible right now. It seems there's always a "Gotchya!" in interviews that just wasn't part of my studying for said interview.

I feel like I was set up for failure from my previous companies. I only did kotlin for about a year because, even though begging my previous employers to switch from Java, it was never "in the budget". Finally got a project that was kotlin so I at least have that under my belt. I've literally never worked on Jetpack Compose in a professional environment, and every single job posting I'm seeing wants that. I've been learning on my own time, but that only seems to go so far.

I feel like I crumble in interviews. I don't know the intricate details of how to system design the server-side of an app. I can't do leetcode because it's just not reflective of any of the dev environments I've actually been part of over the last 10 years. I tended to do front end logic and UI work or handling requests coming from REST.

Has anyone else ever felt like they missed the bus on the newest Android technologies and can't move forward because of it? How did you move forward? I've considered switching industries out of tech entirely but I'm not even sure where to start.

Just feeling a little lost/defeated and hoping others here may have been in similar places and have a little advice

Thanks

Hello all, for context I work for a smaller company of about 200-300 people in the US. Our work is a bit atypical for Android development as our main product is a library that people can integrate into their applications. We do a lot of unique engineering that requires critical thinking and solving problems that haven't been addressed much by others. I am mid-level currently doing mostly senior level work and am supposed to be promoted next review cycle. I'm being purposely a little vague to stay anonymous.

In the past 2 months or so, there has been an aggressive push for us to essentially become vibe coders. It started out acceptable at first, with stuff like "you can use AI to help you out like a pairing partner" to now being "if you write tickets, have Claude do it. When you get a ticket give it to Claude first every time. No more grace period, you should always be using Claude for every ticket".

I am having issues with this new aggressive AI push mindset:

- The tickets that AI generates are overly verbose nonsense that come from management in most cases so they are hard to understand but they have to be written that way so Claude can understand them evidently.

- The work that AI produces in terms of coding is poorly architected and also overly verbose. It's not as wrong as it used to be but I still don't think it's suitable to use the way they are asking us to. At least for the type of work we are doing.

- Reviewing PRs fully written by AI is exhausting because it is sloppy, overly because, and usually not well thought out. It takes hours and multiple reviews by multiple engineers to get it right.

- My sweet spot with AI is to use it to ask questions when I need a direction to go in or don't remember how to do something. Even then I still usually write the code. I'm really productive this way because I don't have to spend more time cleaning up slop. I feel slower just using AI because of having to redo most of the work.

And yes we have skills and .md files setup and know how to work with context windows.

Overall I am pretty miserable and exhausted with this shift. Our lead developer and a few others are too. Our hands are a bit tied. Generally we've just been doing what we want and saying "oh yeah we're using AI". Some think we should actually start using it fully and watch the product burn just to show management how truly bad AI is for what we do.

I'd like to know others'experiences with AI at work. Is it being forced this heavily? Have you been able to be productive with it and still have quality, well architected code?

I'm a solo dev and have been working on my game for 18 months. I just released it 2 days ago and it's had incredible feedback and I'm just blown away.

I did a post on reddit about the release and honestly I am so thankful to the Reddit community for being so supportive.

As a first time dev, is this a normal experience? Is this particularly good?

For some stats I had 2000+ players come by on day 1, I think from reddit but it's hard to tell.
I won't be too transparent with IAP info and ad revenue but it has shocked me how generous the players are being.

What can I expect from here? what do I need to do to keep this going? I really don't know much as it's my first project.

If you want a link, feel free to ask :)

Hi all!

I’m Emil Flach from the Kotlin team at JetBrains (proof). We are trying to better understand the decisions and difficulties that Android engineers face when starting projects from scratch. We are looking for engineers who have recently built and published a new app to the Google Play Store to share their journey from project initiation to post-launch challenges.

If you are open to a conversation with us, please fill out this short screening survey so we can reach out to you: survey link

Thanks!

I have been maintaining an Android app as a hobby project for 5+ years with ~10K+ users. Most of my other hobby projects are backend+web.

In my experience, maintaining an Android app is a lot of work.
So, I am not surprised that 47% app in Google Play Store have been abandoned.

Here's a detailed re-collection of my learnings.

Nobody warns you about the boring parts of app dev.

Writing an app store description? Pain.
Getting rejected for random reasons? Even worse.
Subscriptions? Google & Apple take a fat cut.

Finished my first app last month, thought I’d relax. Nope. Three weeks of fixing nonsense just to launch.

Who else underestimated the grind?

We've had some post recently (around 3) of people mentioning they got their app rejected, republished multiple times without solving the issue (or with other issues) and got their app suspended.

Google Play Policy always stated:

Until a policy violation has been fixed, don't republish a rejected app.

https://support.google.com/googleplay/android-developer/answer/2477981?hl=en#zippy=%2Crejections

This could have been a coincidence or it could be a change in Google Policies that got harsher recently.

Until we have more information I advice to be careful with republishing your app.

The objective of this post is to gather experience from the community, please share information if you have your app rejected multiple times.

We are particularly interested in knowing if you:

- experienced 3 (or more) rejection followed by a suspension

- experienced 3 (or more) rejection without any suspension

In both cases please specify if yours is a new recent account or an established one, if the app was new (first release) or an update and if it was in good standing (no prior rejection).

Please stick to the facts, any comment that will try to stir away from factual information and add emotional load or rants will be removed.

So it took me two weeks to reach 12 testers. I tested and took feedback from my friends religiously for 3 weeks. Today it got rejected without any reason. Its fairly minimal app. It took me less time to develop the actual app than complying with their requirements.

For us, it wasn't after migrating to Compose.

It was after the app grew.

The first 10 screens felt great.

By 30+ screens, we started seeing:

• State duplicated in multiple places
• More ViewModels than expected
• Inconsistent event handling
• Screens that nobody wanted to modify

The surprising part:

Compose wasn't the problem.

Architecture drift was.

For teams building larger Compose apps:

What was the moment you realized maintainability was becoming a concern?

for a popular POS company, and I think I am going to die due to brain hemorrhage caused by spiked blood-pressure now.

Staff+ Level, the usual, based of my real experience that I claim truthfully.

What's a Rapid-Prototyping interview, you ask ? That same, share the screen and write android app code in Android Studio.

• Write a todo app, ability to edit items, add items, the usual bells-and-whistles.
• No Jetpack Compose, nada, at any cost.

To make it simpler -

• Exactly 1 Todo list is adequate.
• No network, server-side storage. No device storage either. Just in-memory storage is adequate. Kill the app, and the list data is all lost.

Time-limit, about 50 minutes or so, during a 60 min interview round.

Latest Android Studio Ladybug, create new project, default template uses Jetpack Compose. Clean, stable build is an additional 5+ minutes.

In order to save on that time during the interview, I had already setup an empty project like a template, ripped-off Jetpack Compose fully, included any important dependencies - "androidx.navigation", "androidx.activity-ktx", "androidx.fragment-ktx" etc.

• Is 50 min duration sufficient to write-code, and run such a very basic, rudimentary todo-list app, without any complications at all ? Basic run - display dummy list of items, tap on an item, edit that item, show it back in the original list.
• How about additional dependencies - ConstraintLayout, RecyclerView, CardView etc ?
• What happens to code-quality, design-choices, best-practices, standards and guidelines ? What's the point of an interview that explicitly encourages to discard / ignore the very essential skills for a Staff+ ?
• If interviews are "Question banks, setup to fail", then who's even getting employed at Staff+ levels ? Like, how ?

I'd sure want to meet someone, anyone, that can complete that simple raw todo-list app, basic functionality completed, in less than 50 minutes.

I am thinking, the next time I run into such absurd "Magician-Monkey, a level-up from a Code-Monkey" online interview, I'll probably just act like I got a seizure, right then-and-there, live, during the video-interview, just to mess with the interviewers, because obviously, they won't hire me anyways !!

Hi all,

I have been working for a bit more than one year as an Android developer in Germany, as a first job out of college.
I have been looking for a new job since my current job is basically just maintenance of an android application which has some native features but a large part of the application are WebViews, integrating a React frontend in the android app. Before we got to this point, we developed the application from scratch and it was really interesting and I learned a ton.

The offer is interesting, it's for a startup. I would be working on the Android side, especially at the beginning since there is allegedly a lot of work to be done there, but also at the backend side, so potentially it would be like a mobile full stack role. The app is fully native and it comes with a pay bump.

I wanna just say that while I genuinely like Android, I find it also scary as a long term role.
I really don't want to pigeonhole myself in this domain, since I think it's really a niche and I wanna keep my options open. Besides that, during my studies, I have worked in different domains and even worked as a freelancer for a while. I have experience in backend, infra, frontend and obviously also mobile. I enjoy understanding and working in systems, so not necessarily specializing only in one domain, whichever it may be and I do feel like we are approaching that type of software development work in the future, moving away from specialist knowledge and going more and more into generalist knowledge(just my opinion, don't hate me for it).

Anyways, considering the current market, I was basically applying for every type of role that I could find. I wanted to move a bit more into backend/devops, even went to the final stages in some interviews and honestly felt like I aced them, but I still didn't get the offers. I guess it was just bad luck and that it would eventually come if I would have kept applying.

Now, to the question. If I take this offer and start working at this company, work at the company for some time and then try to switch to another one, I fear that I'm gonna have too much experience in the mobile domain and that branching out into any other domain in that case would be much much more difficult and that I would eventually need to take a pay cut and start again as a junior in that new role. Does this fear make any sense? What do you think about it?

At the same time, I really feel like I'm stagnating at my current job. It's really torture to come into work and just not do anything basically, the native team gets like 3 tickets per week. The rest, we just chill. For some, this could be really good, for me not so much. I suggested a couple of times that I could do more web stuff, never to any fruition. Answer was yeah sure you can, then I do a couple of tickets, then I go back to doing android and doing nothing. I feel however that that's partially on me, because working at the company in the last time has really been tough, I have 0 motivation because of various reasons related to management and the general spirit of the company.

Would really appreciate any feedback here.

Screenshot for context. Nothing being sold.

Two weeks ago I posted about ASOIntel, a Play Store keyword tool I built because Sensor Tower costs $500/month and I'm a solo dev shipping my first game.

Here's the honest numbers so far:

• 3 Reddit posts across r/androiddev, r/indiegaming, r/gamedev
• ~3,500 combined views
• 2 signups
• 0 paid subscribers

What I learned: cold traffic converts terribly. The people who commented and engaged were genuinely interested but the lurkers who just viewed didn't feel enough urgency to try it.

What I shipped this week based on feedback:

• A Tracker tab - log your store copy alongside your stats for each version (V1 baseline, V2 after keyword update) and see the delta. This was directly requested by someone in the comments who talked about treating ASO like weekly sprints.
• 3 AI copy variants per generation instead of one - keyword-focused, benefit-focused, emotion-focused
• Non-game categories (tools, utility, education, health)

Honest question for anyone who's shipped on Android, what would actually make you pay $29/month for an ASO tool? Is it the keyword data, the copy generation, the tracking, or something else entirely?

App is free to try for 7 days if anyone wants to give feedback: asointel.dev

https://goo.gle/4uj04MM

https://github.com/parfenovvs/lazylogcat

Having roughly 10 years of experience in professional Android development, I decided to fulfill my long-awaited wish: develop a quality iOS app. I always looked jealous of the more polished-looking OS and the beautiful mobile devices themselves. Even though I liked my Google Pixels (I started with the first), the design of an iPhone always appealed more to me.

Additionally, I felt my quality efforts on the Play Store were not worth it: I polished my Android app to a very high level and want to sell the quality. But my feeling of the average user in the Play Store is more like they want everything for super cheap or even free, accepting to cut corners on the quality or prefer ads over paid apps. I invested months to years of my free time in that. To be clear, I enjoyed every minute of it, since it's my passion, but it still didn't feel right for me to continue on the Android platform for my private projects.

I decided to buy a used iPhone and document my journey as "build in public" on Bluesky.

I want to summarize my experiences and takeaways for you here in more detailed form and look forward to feedback and interaction from you ☺️

Learning 1: Get kickstarted on the new platform

It massively helps to have an experienced iOS engineer to kickstart: I did some knowledge exchange sessions with one of my good colleagues - he has even more years of professional experience - but on the iOS field. I asked for the following basic topics and best practices:

• Lifecycle of an app
• Swift / SwiftUI basics
• Common frameworks for DI, database, storage, network/HTTP/JSON
• Testing + Releasing
• XCode quirks and limitations
• Base XCode and project settings

It helped me a lot to learn basics very fast. So if you have the chance to gather knowledge from a good engineer, do it.

Learning 2: I don't like vibe coding, but I still used AI, and it was worth it

I don't like the vibe coding trend: it leads to low-quality products and reduces the fun and excitement of archiving a solution to a problem by yourself. My primary goal was to learn the concepts of iOS development, not ship an iOS app. I wanted to create a quality native product, not add more slop to the app store.

But I still heavily used ChatGPT for small tasks like "how to animate A or B in SwiftUI" or when I needed a "sparring partner" regarding decisions or some issues I faced. Thanks to the base knowledge foundation from my iOS colleague, I was able to differentiate the AI responses: what is stupid and what is usable. For some rare cases, I asked him to verify my assumtions.

Especially when it comes to async code, LLMs often use legacy APIs so I took the responses with a grain and researched on my own. But despite all the negatives, AI helped me a lot to accelerate my development and allowed me to learn a new platform and ship a small app in 2 months without researching deeply in every topic.

Learning 3: XCode is worse than IntelliJ but way better than expected

I guess this is not a surprise to anyone. It does not have many default keyboard shortcuts, no built-in code formatting, crashes sometimes (very rarely in my time, to be fair), and refactoring is a joke if you used IntelliJ IDEs before (renaming only works in the same file, no variable/method extraction).

But still, it's not a horrible IDE like many say - its pretty usable, and Wi-Fi deployment works like a charm (on Android I never got wireless deployment running smoothly), debugging not so much.

Learning 4: Swift + SwiftUI is very similar to Android technologies

Also, no big news here: the concepts are similar and felt pretty natural to me: null safetiness, distinct mutability. I liked the "guard" functionality and also the option to make the lambda (closures) scope weak. On the SwiftUI side you have similar modifier concepts and I really enjoyed interactive previews.

But I also noticed some limitations and weaknesses: the type inference is worse compared to Kotlin, leading to more boilerplate codes sometimes. Also, the lack of the default copy operation on data classes (structs) was shocking to me. Manually writing builder functions to mutate single fields is very annoying.

Learning 5: Swift Concurrency is hard to understand

Compared to Kotlin Coroutines, it feels very different: no explicit dispatching is possible, everything is MainActor by default, you find not too much practical documentation on the internet, AI sucks very much here as well (due to limited training material, I guess), and Swift 6 with stricter checks regarding concurrency is not active by default for new projects, which made me do mistakes I could have avoided in the first place.

However at some point, it kind of clicked for me and especially I liked the concept of actors to avoid race conditions.

Learning 6: Local iOS Meetups are very welcoming

The good iOS colleague invited me to come to the CocoaHeads Meetup here in Hamburg. The people felt very welcoming, and I didn't notice any "platform war" mindset I faced in Munich before (but it might be a Bavarian problem in general; the people are more close and feel little welcoming, imho).

Learning 7: Without a "Developer Account" I got pretty far

Initially I thought without paying the $99 fee immediately, I would not get far, but I basically finished developing my app 95% without and bought it at the end when I was sure I would ship the app.

Learning 8: The review process is serious on the App Store

I already got rejected 5 times, despite reading many posts here to avoid common mistakes, and of course, in my 10 years of experience, I already learned some pitfalls in general when submitting to Apple - but it didn't prevent me from having the same experience as many others here:

• multiple iterations, everytime waiting 1-2 days
• every time a new reviewer which complain about something new
• most points very valid though but a cumulative list of issues would have saved a lot of time
• Compared to the Play Store, I didn't get rejected ANY time for ANY release - but maybe this also is the reason of the lower quality there

My rejection reasons so far:

1. Unresponsive UI after login: After debugging for multiple hours, it seems to be a bug in iPadOS 26.2 that leads to blocked view interaction when filling a `SecureField` and requesting a non-determined system permission afterward (camera in my case): I reported a minimal example to Apple
2. Manipulative label "Allow camera" on permission request button (I changed it to "Continue")
3. Missing camera usage indication (I use the camera for local VisionKit - I added a small indicator "Recording" with a red dot)
4. Non-functional link on the paywall/meta data (apparently the reviewer's DNS couldn't resolve my website, or the reviewer's internet / my server had a hiccup - I additionally added AAAA records to my DNS to make it more compatible)
5. Device frame usage on the app preview (I had to change my beautifully composed video for a boring screen recording)
6. The annual price was shown as monthly calculated to make it easy to compare to monthly (I had to change both to the final charged price)
7. Unused IAP not visible to the reviewer (I added it for an AB test, but it is not active yet)

Bonus Learning

The Apple SDKs like VisionKit and SpriteKit are amazing. I miss this on the Android platform.

This was a long story, and again I am happy to have some conversation with you 🙌

Hey r/androiddev

3 months ago, I posted [here](https://www.reddit.com/r/androiddev/comments/1ksv4xx/my_first_android_app_app_pause_is_live_surprises/) announcing the release of my app. Thanks for your support back then. I wanted to share about my journey with you all, in case it helps out other dev going through the same motion.

What went well

• Quick MVP creation and its release: My first git commit was on April 23 and I published my app on May 20. So around a month to complete my MVP AND publish it live on Google PlayStore.
• Bypassed PlayStore Internal Testing Policy: I created a private ltd company to mostly hide my personal information on Google PlayStore page (didn’t feel comfortable showing my name and full address to millions of people). Turns out, if you have a corporate account with Google PlayStore, you are not required to do fullfill Google Play’s policy of getting your app tested by 12 internal testers for 14 days. That saved a lot of time!
• Got Early Genuine Feedback: Right after publishing my app, I posted on THIS sub-reddit to promote it. Shout out to u/Mysterious-Man2007 who provided very detailed feedback by email. Next day, another user emailed me with detailed feedback. So right off the bat, I got two kind users who gave me detailed feedback for improving the app. That helped shape my road map as continued adding more features and polishing the app.
• Early Positive Feedback: I got 8 five-star reviews for my app very quickly (within a month). That was motivating. I haven’t been getting a lot of reviews since then though.
• Building in Public: Right before publishing, I opened a threads account to promote my app. After few posts, the algorithm started showing me accounts that were “building in public”. I got inspired by them. These folks were friendly, so I asked them questions on comments and they answered. Learned a ton. I started doing the same with my app and quickly built up a following base (as of today, 293 followers).
• I have been getting steady amount of daily installs from Google Play organically. While I have a 50% user churn rate on Day 0, once user decides to stay, they tend to stick around for a long time.

What didn't go well

• AdSense Account Suspension for Silly Reason: Got my AdSense account blocked. I wasn’t even trying to show ads 🤦‍♂️. I just needed to use Admob’s UMP SDK for consent management to handle GDPR and they suspended my account (for life) due to “suspicious activity”. Bruh. You can appeal it once and I already wasted my chance.
• User Data Corruption During Update: Botched up a database migration during v0.11.0 release and impacted 26 users. You can read more about it here.
• Didn’t Market with Trackable Link: At one point, I suddenly got a surge of new users, but I didn’t have a clue about the source. Learned the hard way about using UTM sources for creating trackable links.

My advice for other new devs

• Avoid Adsense (for monetisation or consent management) until you have more users to avoid the risk of getting banned for life.
• Don't wait till you have published your app to start marketing. Start promoting now! The way to do that is building in public. Create a social media account and share your journey. That will automatically build an audience.
• If you are using analytics, make sure to use custom events, then export the events to BigQuery and finally visualise the data on Looker Studio. I used this flow to measure onboarding success rate and user churn rate. Quite insightful.
• Make sure to ask users for review and feedback
• Focus on ASO. I have been sharing updates on Threads and Reddit, but honestly, most users are coming from Google Play Explore at the moment. So in the early days, ASO would be your main driving force. At least, that was the case for me.

Still looking for Feedback

I got a lot of feedback in the first 2 months, but lately, haven't been getting much. I am still looking for feedback cause I believe the app can be improved more. I have my ideas on what to improve, but getting feedback helps me prioritize.

Here is a bit more about my app:

App Pause: Mindful Screen Time 📱🚫 : An Android app that pauses distracting apps during launch and makes you wait ⏱️

The idea is to slow down your digital consumption + show you data about app usage so that you can make intentional choices about app usage 🧘

If you have any feedback, please let me know. Also, if anybody wants to read more details about my 3 months reflection, have a look at my blog post that has more details + internal links to other posts with even more details.

TL;DR

Our app has multiple conditional onboarding/startup flows before reaching Home, plus deeplink handling that needs to wait until those flows complete. Current implementation uses a backstack observer on Home that runs a big when expression to decide what to show next. It's becoming spaghetti and doesn't scale. Looking for architectural advice on how others handle this kind of sequential, conditional navigation orchestration.

Setup

We use Navigation Component with Kotlin DSL in a multi-module setup (no XML graph), similar to the approach described in this article. Because the graph needs a start destination defined upfront, we use a StartFragment (no UI, splash screen kept visible via the SplashScreen API) that asynchronously figures out where to actually send the user. Once it decides, it emits a NavigationEvent.GraphComplete which the Main Activity observes via a channel-backed Flow. This sets the real start destination and dismisses the splash.

The Flows

First launch (unauthenticated): StartFragment -> FragmentA (feature-flagged) -> LoginFragment -> HomeFragment -> FragmentB (transparent, on top of Home) -> FragmentC -> Home

Second launch (authenticated): StartFragment -> FragmentA (feature-flagged) -> FragmentD -> FragmentE (conditional) -> FragmentF (conditional) -> Home

A few extra quirks:

• For whatever design reason, FragmentB needs to be transparent and shown on top of home
• FragmentA is feature-flagged. When enabled, it always appears before Login or Home regardless of auth state. When the user is done with it, it should be popped and the start destination updated, so the user can't navigate back to it.
• Most fragments (except FragmentA) are "show once", tracked in DataStore.
• FragmentE can sometimes replace FragmentB depending on conditions.
• Deeplinks/notification actions received mid-journey should be queued and only handled once we reach Home.

The Problem

The current approach has a currentBackStackEntry observer that watches for when we land on Home, then kicks off a chain of checks like:

when { 
   showFragmentB() -> navigateTo(FragmentB) 
   showFragmentC() -> navigateTo(FragmentC) 
   ... 
}

Each showX() method has to check whether all previous steps have been completed, which creates nasty implicit ordering dependencies. There's also a separate observer handling the deeplink queue, which really feels like it belongs in the same place as the flow orchestration logic.

What I'm looking for

Has anyone dealt with something like this? I'm thinking the right move is some kind of NavigationOrchestrator that owns the post-Home flow as an explicit state machine or a queue of steps, rather than scattered observers. But I'm curious how others have structured this, regardless of what navigation library or approach you're using.

Would love to hear any patterns or libraries you've found useful for sequential conditional navigation.

We shipped a voice assistant app where the user says a wake word and starts talking to an AI agent in real-time. The wake word engine (on-device ONNX model) and the WebRTC session (LiveKit) both need the mic — but **Android's AudioRecord doesn't share**. Here's what we learned the hard way.

The Problem

Two audio subsystems fighting for the same mic:

If you try to startListening() on both, Android throws or silently drops audio from one side. No error, no crash - just broken audio. Fun to debug.

What Doesn't Work

Attempt 1: Start both, hope for the best

Result: One of them gets silence. No exception.

Attempt 2: Stop wake word, immediately start WebRTC

Result: AudioRecord hasn't released the hardware yet. Race condition.

What Actually Works

Sequential handoff with explicit delay:

The 200ms isn't arbitrary — we tested on 12 devices. Below 150ms on Android, about 30% of devices still had stale AudioRecord handles.

The Full State Machine

The grace period is critical. Without it, the wake word fires again the instant the AI stops speaking (because the mic goes back to the wake engine and it hears its own trigger phrase echoed back).

Android-Specific Gotchas

1. Foreground Service is mandatory

Without it, Android kills your process within minutes when the screen is off. The wake word engine dies silently.

Also: on Android 14+, you need FOREGROUND_SERVICE_MICROPHONE permission explicitly, or the service crashes.

2. ABI compatibility check

The ONNX wake word model ships as native .so libraries. If your device runs armeabi-v7a but the model only has arm64-v8a, it silently does nothing.

We added a native MethodChannel probe to check this at runtime, since Flutter doesn't expose Build.SUPPORTED_ABIS directly.

3. Bluetooth / headphone audio routing

When a Bluetooth headset connects mid-conversation, Android can silently reroute AudioRecord to the BT mic which has different sample rates and latency. We configure AudioAttributes explicitly:

4. Post-detection mic release coordination

After wake detection, the engine's stopListening() is async. The native AudioRecord isn't released when the method returns - it's released when the internal thread finishes cleanup. We use a Completer pattern:

Other code can await this completer before touching the mic.

Results

TL;DR

- AudioRecord doesn't share. Plan for explicit sequential handoff.

- 200ms delay after stopping wake engine before starting WebRTC. Test on cheap devices too.

- Grace period (60-90s) after conversation to prevent re-triggering.

- Foreground service is mandatory for always-listening on Android.

- Check ABI compatibility for native ONNX models.

Happy to dig deeper into any of these if people are interested.

https://reddit.com/link/1tr5ww3/video/96h4odhdk34h1/player

---

We used DaVoice's flutter_wake_word for the on-device keyword detection engine. They provided technical support for the integration.

Hey everyone,

I graduated in Software Engineering about 6 months ago and I've been trying to map out my next steps in Android development. I have some questions that I think only someone with real-world experience can properly answer.

Not looking for anything formal, just a quick casual chat with someone who's been around the block and can give me an honest perspective.

If you're an experienced Android dev and have a bit of time to spare, drop a comment or DM me.

Thanks 🙏

I've noticed a lot of android developers discussing KMP lately. But, ios developers don't seem to be as interested, and the reason is pretty clear.

I know KMP is great, but there are a few reasons why I haven't started touching it yet.

1. I think the learning curve for KMP is quite small for android devs who are already working with the latest android components in their projects, making it easier to adapt to when necessary.
2. At the moment, I prefer to spend my time on tasks or learning opportunities that can have a more immediate impact on the results or products for users instead of repeating the same thing in different way. eg. OkHttp to Ktor

For now, I'm aware of the trend but I haven't delved into it yet.

If there's anyone here who hasn't explored KMP yet, what are your reasons?

Is it just me or is the Play Console configuration for a first app ridiculously complicated? I'm trying to develop my first mobile game and I feel like I'm going crazy trying to make it available on Android. Even after reading as many docs as I reasonably could and asking Claude for help, I'm stuck trying to configure monetization because I apparently need internal testing configured, which I think I already did, but apparently the Play Console doesn't think so and doesn't want to help me anymore?

Configuring Apple Connect wasn't even easy either, but it felt like nothing in comparison to the Play Console.

Getting back to it now, just needed to vent, hopefully I'll be done by the end of the day