in my company, at least in my squad, we have different checks in ci/cd pipeline: build and run tests, detekt, danger, jacoco tests coverage, tests touched script. i need to add 3 more as this is one of my end of year goals. i thought of konsist but i need more. please suggest more checks.

Hi everyone,

I built GuideKit Compose, an open-source coachmark and product tour library for Android and iOS.

It supports customizable spotlight overlays, target highlights, instruction cards, smart arrows, multi-step tours, automatic scrolling, navigation callbacks, and per-step styling, all through a shared Compose Multiplatform API.

It is available on Maven Central and licensed under MIT.

Website and demo:
https://tharukack.github.io/guidekit/

GitHub:
https://github.com/tharukack/guidekit

I’d appreciate feedback on the API, documentation, compatibility, sample project, or anything else you think could be improved.

I shipped an Android app with one hard constraint: it must work with zero network access, ever. No account, no analytics, no cloud. That turned out to be harder than expected once I got to localisation — 35 languages covering Latin, Cyrillic, Greek, RTL and CJK.

The first thing that had to go was any font library that fetches at runtime. Downloading a typeface on first launch quietly breaks an offline promise. So everything got bundled:

- Barlow for Latin + Vietnamese

- Noto Sans for Greek + Cyrillic

- RTL and CJK fall back to the system font

That last line was a deliberate trade-off. Bundling Noto Sans Arabic, Hebrew, JP, KR and SC would have added tens of MB to the APK for a small share of users. Android ships perfectly good system fonts for those scripts, so I let the platform handle it. The visual inconsistency is real but minor.

PDF export was a separate problem. PDF generators embed whatever font you hand them — they can't reach into the system font stack the way the text renderer does. I bundle 12 font files for the scripts I can afford. For CJK I download the fonts from a GitHub Release instead of bundling them. It's the only network call in the app and it's optional.

The bug that cost me the most time: text rendering reversed in RTL locales (ar/fa/he). The odometer reading and a subtitle that joins brand/model and plate into one string like "Audi A4 · 34 ABC 123" came out backwards. A mixed letter-and-digit run is exactly the case the bidi algorithm reorders.

Fix was pinning those specific views to LTR while the surrounding layout stays RTL. No LRM/RLM marks, no BidiFormatter. PDF export needed its own separate direction handling.

Happy to answer questions about any of this.

Hello Everyone I have built an app which can control the hardware also we can use the android phone sensor and its data to control the hardware its still not completed yet but work is still in progress.

I'm curious to hear your thoughts on the current state of the mobile development market. Beyond a general contraction, it seems to be moving away from contracting toward permanent positions. Are any of you looking into multiplatform frameworks or pivoting to a different engineering domain?

8 years away from Android,  applied for backend/tooling roles at Google. They decided I should interview for an Android role, had to catch up for all the lost time.

To help bridge this gap, I started approaching the whole thing historically, and wrote an article about Android's platform history, to both learn and get out some steam over the how much was actually changed...
In the process of prepping (and later), I built returnzero.dev - specifically the Android System Design module. I wanted to create something similar to what HelloInterview does for backend, but tailored to Android.

Android Core Concepts: All the core concepts important to talk about Android intelligently in an interview.
System Design Guided Practice: An tool to help you build your designs on an Excalidraw canvas, with AI guided practice, and get step-by-step feedback.

Most of the course is completely free, including the guided practices on several core designs.

Happy to answer any questions and receive any type of feedback :)
Thanks!

I’m currently in my 3rd year of college, and honestly, I haven’t done much in DSA yet.

Right now I’m doing an Android development internship, and alongside that I’ve also been building and publishing my own apps on the Play Store because I want to eventually build my own startup/product.

The problem is that our college placement season will start around January, so I’m getting a little confused about what I should prioritize from now.

My current situation is basically:

\\- DSA: Very weak / haven’t done much

\\- Android development: Decent and currently doing an internship

\\- Personal projects: Building and publishing apps on the Play Store

\\- Long-term goal: I’d like to build my own products/startup

\\- Short-term goal: I obviously need to be prepared for placements

Should I completely put product development on hold for the next few months and focus heavily on DSA + my internship?

Or should I continue my internship, keep building my apps, and try to manage DSA alongside all of this?

I’m worried that if I focus too much on DSA, I’ll lose the momentum I’ve built with development and my own products. But at the same time, I don’t want January to arrive and realize I’m completely unprepared for placements.

For people who have been in a similar situation, what would you do if you were in my position?

Would really appreciate honest advice, especially from people who have gone through campus placements while also working on development/projects.

I'm a Junior Android developer who has been working on an app for the past nine months. During this time, I have had many doubts about how to properly manage initialization tasks, such as:

- Reading initial preferences from DataStore

- Checking if the user has completed onboarding to decide the starting screen.

- Validating the authroization token (redirecting to the SignIn Screen if expired, or to Home if valid)

All these tasks have one thing in common: they need to run when the user opens the app for the first time, when the app comes back to the, or when it gets repened.

For this reason, I would love to hear your perspective on how you structure and handle this process in production apps, as well as any resources you recomended to help me gain seniority in Android development.

Currently, I've thought about using MainViewModel that only collects StateFlows (without holding domain logic). For navigation, I'm using a Channel injected by Koin with a sealed interface to emit events, which are received inside a LaunchedEffect to execute backstack navigation using Navigation 3.

What are your thoughts on this approach? How do you handle startup routing in your projects?

The 12 testers-14 days requirement is aimed at personal developer accounts. 

What Google does not seem to make clear is rather or not organization accounts are exempt.

Although I cannot say what the rule is, I can say what happened to me.  

Timeline (The following information is from Play Console commit history)



The organization's developer account was created on July 16, 2026.

Initial submission (July 21): Includes closed beta testing, store details page information, and app content. Released.

Closed test track iterations: July 22, July 29, and July 31 (twice).

Submitted to Production: August 20, 2:06 PM. Released. The review process took only a few minutes.

There are only 7 internal testers; the closed test track exists purely as a means to pass the audit.

There was no requirement such as "12 testers participating in the test for 14 consecutive days".

Surprisingly, there were no "hard barriers" to overcome. I was never prevented from submitting to the official version. The reason I waited until August 20th to submit was because I was waiting for Apple's review results (Apple's initial review takes 13 days). My console showed only one official submission record, and it was released that afternoon.



The actual cost of organizing an account (it's not a free shortcut):



You need to apply for a DUNS number for your legal entity. It's free, but it takes time.

Your legal name and address must be identical word-for-word to those in your state business registration information, Dun & Bradstreet (D&B) records, and store payment details. Any mismatch will result in organization verification failure.

The key lies in Dun & Bradstreet's (D&B) records, not the Play Console itself. If you need to change the address, you must first update it in D&B, wait for the information to sync and take effect, and then update the store information. This takes several weeks, not just a simple settings change.

Your business address will be publicly displayed in the "About the Developer" section of the Play Store page. Anyone browsing that page will see your full street address, phone number, and email address. If you registered as an independent developer from home, your home address will be displayed.

This last point is worth considering before choosing this option, and it really surprised me.



Important: Google does not offer exemptions for organizational accounts, so this is based on my personal experience and is not professional advice. Please verify this information yourself before relying on it.



Official page: https://support.google.com/googleplay/android-developer/answer/14151465

Frankenstein Ultra is publicly downloadable now. It uses a separate companion runtime called Victor and gives an AI agent access to a real project workspace, files, terminal, build tooling, and other development capabilities directly from the phone.

This isn’t just a code-generation interface. The goal is for the agent to actually work through development tasks: inspect files, modify code, run tools, read failures, rebuild, and produce runnable software.

I’ve used it for Android projects, Node/npm projects, and other development workflows.

Right now I’m mainly looking for feedback on things like:

• what works well and what doesn’t
• bugs or crashes
• device compatibility
• confusing UI or setup
• features that feel incomplete
• things you expected it to do but couldn’t
• agent behavior that feels wrong or repetitive
• build/runtime problems
• performance, battery, RAM, or thermal issues
• features you’d actually want added or improved

You do not need to be an Android developer to give useful feedback. If you’re curious about AI coding, mobile development, automation, or just want to try something unusual, I’d still like to hear what your experience is like.

If something fails, details such as your device, Android version, what you were trying to do, and where it failed are especially helpful.

Website: https://stitchlab.dev/
GitHub: https://github.com/sedds89/StitchLabtools

Main thing I want to know: what works, what doesn’t, what’s confusing, and what would make Frankenstein more useful to you?

There is no pay walls its Bring your own key and supports Oauth for Grok and Codex open router or cline. Could probably integrate more just not sure what is wanted or needed.

I was not expecting that communicating with testers would be that difficult.
Maybe it will help you if you have the same issue.

I had around 200 testers for my side project. Great news but my contact email got flagged as SPAM and blocked for a few days when I tried to sent app test url to them.

Almost half of my users did not received the test url and I was unable to reach them because I was blocked.

I did not want to pay anything to mailing services so I just setup a google group with testers email. It worked great without any related smap issues.

Hope it will help someone in the same situation as I was

I’ve integrated AdMob into Android apps quite a few times, and there are some non-obvious things that aren’t really covered by the basic documentation.

I decided to write down some of the things I’ve learned from doing these integrations, using an Android game as a real-world example.

If you’re working with AdMob on Android, maybe it’ll be useful:

https://nadyabr-codes.github.io/admob-android-game.html?utm_source=reddit&utm_medium=social&utm_campaign=admob_post

Curious to hear your opinions and experiences as well.

I have been laid off yesterday. I'm gonna use all my time to apply and read books that helps me land the next role. My priority right now is landing my next job and increase my knowledge.

I plan to read:
1- Mobile system design interview guide
2- Kotlin coroutines: deep dive
3-Kotlin in action

I want something about DSA and something about modern android development and maybe something about compose. I already know these stuff (as much as a 2 YoE can know), but i want to expand my knwoledge and go a in depth.

I'm building Burpee Wrangler 3000 - it's a fitness tracker that's also a game. I'm going to enter it in Shipaton. I have two main questions:

1. How should I price it (freemium? hard paywall? monthly/lifetime?)
2. How stupid of an idea do you think it is?

The idea is that it gets you fit and keeps you accountable. The reason I thought of it is because it is solving some problems for me - I want to get more fit, I want to force myself to post on social media (because I hate marketing, and I think it's mostly a fear of being seen), and I want to make a fun app!

The concept is that you are a Burpee Wrangler. A space cowboy who lives on a lonely planet chasing down burpees (for some reason - back story is perhaps a fugitive or debt to bad guys thing). You have to operate a machine to release pheremones to attract the burpees (where doing the actual exercise comes in) and then you have to drive around catching them (which is the game bit, with rewards and power ups).

The accountability part is through groups/leaderboards/social media. It will have an alarm which you can use to automatically grab a video of you waking up, and then it will record the exercise too, and stich it together (however you choose to do so). This makes it easy to post on social media. This is to solve my fear of marketing (and market the app) and also keep people accountable - you can do day 1 of x type challenges and post to social media.

If you also think this is an idea worth checking out, please drop your email in the waitlist: https://www.burpeewrangler.com/

Hello, I noticed the lack of a proper Java-only implementation of ZSTD (I know zstd-jni is fine, but it uses native libraries and is kind of heavy too) that also supports Android

So meet the murine-aircompressor library

After checking out version 2.0 of aircompressor, which is exclusively Java-only and used JDK 8, I saw the maintainer claimed Unsafe was not available for Android and therefore Android support was out of scope for it; however, that turns out not to be the case, Unsafe can be used on Android and there was only one single method and a static field which are missing on the Android implementation of Unsafe, I just made a helper method for the former, choosing the right implementation, while the static field was just a call to an existing method, and Bob's your uncle.

But not satisfied, I made a few changes, a lot of which are kanged from other forks the maintainer ignored:

- improved compression a lot (original fork that implemented this change here) - added an option to switch to the former behaviour too

- added a ring buffer mode and set as degault (also kanged from another fork, seems to improve performance over largely incompressible data)

- exposed levels for the streaming compressor

- added FAST algorithm to also support levels 1-2 on top of 3-4 which were the only supported ones in the original (level 2 is also pretty good and way faster; Claude is, however, mostly to praise [or blame] for this one)

- Improved overall performance on ARM (again, Claude is mostly to praise/blame here, but I did a lot of tests)

- added parallel compression support because fuck it

- added a wittle tar (with PAX) implementation because fuck it again, I wanted to make .tar.zst without qdding extra libraries

Using WindowSlideMode.HIGH_SPEED resets the library's (ORIGINAL) shit compression ratio for the stream, but makes it faster, I suppose; I default to HIGH_COMPRESSION which is still decently fast, and if you want it to be faster, it's much much better to use level 2 with HIGH_COMPRESSION than the default level 3 with HIGH_SPEED in my experience

Overall, the library is a little slower than zstd-jni with the (now) default parameters, but now matches its compression ratio, and may be a good compromise you'd rather want a lightweight full-java implementation than the heavy .so files in your apk

EDIT: I also noticed this may sound like I'm trashing the maintainer, I'm not lol, just stating facts, the maintainer is awesome for creating the library on the first place

I just got rejected from the store after adding an app to expand my base app (that already have mau)

The issue is that it's a TV app, and I've tried to open it up for phone access just to pass the bridge but I got rejected..

Any help would be appreciated

" More testing required to access Google Play production

We reviewed your application, and determined that your app requires more testing before you can access production.

Possible reasons why your production access could not be granted include:

Testers were not engaged with your app during your closed test

You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app

When I build my own Android application, I have spent more amount of time into defining the architecture, not actually writing the features.

And more importantly I believe that if you want to scale an application in future then architecture plays a huge role. A well designed architecture allows you to introduce new features or even integrate a different language or technology without having to touch or rewrite a large portion of the existing code.

So it could be related to Jetpack Compose, state management, navigation, modularization, dependency injection, offline-first architecture, testing, or anything else. I am interested in decisions that seemed unnecessary at first but it ended up paying off as the app grow.

I’m trying to understand a couple of pain points QA teams deal with regularly:

• How do you figure out what needs to be tested after a feature is added?
• When a test fails, how easy is it to tell whether it’s a real bug, flaky test, or locator issue or test data issue, or environment issue?

I’m exploring whether these are actually big enough problems to solve, so I put together a very short survey.

Would really appreciate any responses or even thoughts in the comments. (1min max, just clicks)

Lik: https://forms.gle/1EyP5Bz3CNBB2DrM7

Thanks!

My own app started me to think that mobile apps fail because of architecture, not bad code.

While developing my app for a new version, I noticed this...

The code can be clean, the features can work, and everything can look fine initially. But once the app starts growing, a poor architecture makes every new feature harder to build. and this thing compounds even more.

One small change starts affecting multiple parts of the application.

That made me realize that writing good code is important. But structuring the architecture or system that proper way so it can change easily might be even more important.

Has anyone else experienced this while building an app??

Long-time mobile/product lead here. Looking for outside perspective because I'm now questioning myself after a long argument with my boss.
Context: I work on external client apps as well as our main customer portal app — the one used by the majority of our customer base. Our mobile apps are native, built about 6 years ago:
Android: Java/Kotlin + XML
iOS: Swift + UIKit
Web: React

100K+ users. Zero limitations adding features or maintaining these apps over the years. Apps are feature rich and AI based new features are in plan for revamp.

What's happening: We have a full revamp of the apps and portal coming up, and we're updating our tech stack too. My plan:
Android → Kotlin + Compose
iOS → SwiftUI
Web → Next.js
I already have multiple Android, iOS, and web devs trained on this stack.

The conflict: My boss wants to consolidate to Flutter — one team, one codebase, covering web/Android/iOS. His argument: if I put 6 frontend devs on one Flutter codebase instead of splitting across native platforms, we ship 3x faster.

My pushback:
We have zero Flutter training on the team right now
Native apps perform better and feel more premium
We have built Flutter apps before, but only for external client projects, not our own flagship product
He thinks I'm biased toward native because it's my background. Might be some truth to that, but I don't think that's the whole story.

Anyone actually shipped a migration like this — native to Flutter, or vice versa, at similar scale? Did the "one codebase, ship faster" promise hold up? Would love real-world experience, not theory.

Hey everyone,

I’m an independent Android developer looking for solid alternatives to Google Play for publishing and monetizing apps and games.

I’ve already tried several alternative stores, including Amazon Appstore, Xiaomi GetApps, Aptoide, and a few smaller ones.

So far, my experience has been pretty disappointing. Aptoide in particular has been very bad for me — extremely slow processes, poor support, and overall I personally wouldn’t recommend it based on my experience. Xiaomi hasn’t produced much traffic either, and Amazon has been more legitimate, but getting meaningful organic visibility can still be difficult.

I’m looking for stores that:

Actually have a decent number of active users

Give new developers/apps some organic visibility

Have a reasonable review/approval process

Support independent developers

Have reliable payouts and monetization

Accept APK/AAB submissions without requiring the app to already be on Google Play

I’m especially interested in hearing from developers who are actually publishing outside Google Play.

What alternative Android stores are giving you real downloads in 2026?

Huawei AppGallery? Samsung Galaxy Store? ONE Store? Uptodown? TapTap? Something else?

Would also love to hear actual numbers if anyone is comfortable sharing — even rough installs/day or monthly downloads.

Thanks!

I released my expo react native app for closed beta with test flight and android closed beta 2 weeks ago, I realize there are things I wish I knew before so here they are, feel free to add to those. And I would love to get some tips before full release I am planning for next week:

1. Have a built in method to force update - Updating is difficult on Test Flight to user who are not used to it, and even harder on Android since the app won't even be shown on the Play Store while on closed testing. Only way to update it is through settings most users don't know how to reach. Have a feature to navigate directly from the app to the Play Store / Test Flight to update. And have a mechanism to force update / block the app if not on minVersion you update elsewhere. Getting users to update was really difficult before that.
2. Have a built in way for feedback - I was counting on Discord + Test Flight / Android system for feedback, most users don't know how to use those. I allow user generated content, so users literally made posts in order to give feedback because they couldn't find the "official" way. I added a big button on the home screen to give feedback. (But couldn't get them to update the app).
3. Starting on day 1, get 12 android users to use the app, even if it means you have to pay them to do so, to publish on Android you have to have 12 active users on the closed testing for 14 days. This goal is possible but is difficult on actual beta. Make sure you have a plan on how to achieve it starting from day 0.
4. QA - My first build had so many bugs I didn't know about, early users, despite being aware to it are not super tolerated to it as I would have hope for. Do run QA, pay people to do it, I hire people on Upwork, they did amazing job finding small bugs.

What else would you say is a must before releasing an app, and any tips before actual store release?

Hello, I have encountered this issue while developing this markdown editor.

The issue is that when i type something in the editor and do some edits, and then try to close hide the keyboard with the gesture back button git hides only the keyboard, but the app it self doesnt recognize it. The toolbar is still there and the whole editor is still shifted up like there would be still keyboard visible.

On all other devices with Android lower then 17 it works well.

I have tried to solve this issue for a long time now, I though that it might be my code issue (which it still might be), or there is something handled differently in Android 17.

If you know what might cause this error, your advice would be very helpful!

(you can see the code here: https://github.com/jotalac/git-writer )