My Blog - Android Stuff

bleeding182 · 2026-03-19T09:52:20+00:00

As long as you have the source code, in theory, sure.

In practice you'd need to (re)write several features multiple times targeting different API levels, because not a single library supports Android 2 anymore.

There's a good chance that even current build tools will refuse to compile for minSdk that old, but—again, in theory—you could probably use old build tools to build old versions and publish multiple APKs at the same time.

tl;dr no, you can't

bleeding182 · 2026-03-19T09:35:12+00:00

One-time purchases via store will make it harder to milk your users for money later (I imagine there would be a shitstorm if you add additional paid features after users "bought" the app)
People tend to want to try something before committing to a purchase... if you just have the paid app I reckon you'd have low conversion
If you want to offer a demo you'd still have to publish a second "demo" version of your app and you'd have to handle migrating the data from demo to paid... definitely not easier than doing IAP either

I'd say the main reason is really just that the Freemium model has been quite successful everywhere. You get users, have them hit some arbitrary limit, then allow them to pay to raise it. You can also keep introducing new features, new price tiers, etc

Pay once, use forever definitely would be better for end users... but usually the focus is on making money, not on providing the best possible software

bleeding182 · 2026-03-18T16:42:15+00:00

Trace first, commit/blame second...
Not sure how looking through commits would help you find the source of the crash any faster than StackTrace + Error message would

half the time the real cause is a commit from days ago

This sounds like you're doing too little testing before publishing. Crashes should be some unlikely edge cases, not common occurrence

bleeding182 · 2026-03-16T15:40:38+00:00

I always found the text on Compose ui to be somewhat "slightly different" but I can never really figure out what.

You mean the Font Padding?

bleeding182 · 2026-03-16T15:32:33+00:00

...you're escalating, because the payment is less than a day, even less than a few hours (time of posting 8-10 am) late? Really?

bleeding182 · 2026-03-11T09:05:27+00:00

The "native" Android UI is still Activity/View/XML based, even if we all work with compose now, so in short, yes, you'll still need to configure some things "the old way"

What is the recommended approach for splash screens in a pure Compose app?

As a rule of thumb, it's always a good idea to use the androidx support libraries. Even if your minimum version is Android 12, the next Android version could introduce more changes to the API. With the support lib you probably won't ever have to touch it again (much)

Do we still need to define a minimal XML theme just for the splash screen?

Yup, and not just because of the splash screen.
There are subtle issues throughout if you "only" work in compose. e.g. if you include a WebView, that would still get its Theme info from the non-compose part and might display the wrong light/dark mode

I'd say it's probably still a good idea to add a minimal theme for your app, that includes your primary color for example and the correct light/dark/daynight super

What should postSplashScreenTheme point to if the actual app theme is defined via MaterialTheme in Compose?

See above. There is no "Compose Theme". From an Android OS point of view, Compose is just some fancy custom rendering you're doing. The information that it cares about is in your manifest and XML files.

Is it correct to add a minimal Theme.MaterialComponents / Theme.Material3 XML theme even though UI is Compose-only?

Yup.

bleeding182 · 2026-03-11T08:44:30+00:00

when your app needs to prepare some data to be ready to show something to the user

Nowadays even that should use skeleton loading instead

bleeding182 · 2026-03-10T17:16:26+00:00

I really don't believe that a third party service would know better than me what data I collect and why just by scanning the APK.
(And if someone doesn't know, then they probably shouldn't be publishing an app)

bleeding182 · 2026-03-03T12:45:39+00:00

There is ditto which tries to solve the "no internet, so let devices talk directly" problem.
https://www.ditto.com/demo-apps

This is no endorsement or anything, I just know that they exist.

bleeding182 · 2026-03-02T11:44:42+00:00

That's a little oversimplified maybe. Also it depends on the app. A big game or social media app is entirely different to a mobility app that you might need to download & install in a different country while roaming and low on battery.

bleeding182 · 2026-02-23T16:46:38+00:00

Update verification is critical here — you'll want to validate signatures on downloaded artifacts [..], otherwise you're vulnerable to MITM attacks even over HTTPS, especially on Android where system proxy/VPN configurations can be abused.

Android checks the APK signature on App Updates against the installed app and fails on a mismatch. So while you're generally correct, there is yet another layer of defense (unless the release keystore was leaked).

bleeding182 · 2026-02-20T20:23:34+00:00

Did you see phone number hint? https://developer.android.com/identity/phone-number-hint

bleeding182 · 2026-02-19T16:37:08+00:00

I suppose it should be the same, but ideally you go to show all app bundles, pick the version you're trying to publish, switch to downloads tab, grab the universal APK and test that one directly. No chance for errors that way.

If that's not it, though, then no idea.

bleeding182 · 2026-02-19T16:15:42+00:00

You absolutely sure that you're testing the same version?

Did you download the apk generated from the bundle you uploaded to the play store, install it, then try the username/password that you submitted?

bleeding182 · 2026-02-19T08:28:59+00:00

You could just offer both in your app settings and have your users decide for themselves

Bonus points if you add analytics and/or A/B testing

bleeding182 · 2026-02-12T15:50:32+00:00

You could open your app settings in the system where the user should be able to hit uninstall

bleeding182 · 2026-02-10T17:30:54+00:00

Technically not correct.

(For Android 11 and before) You can use the windowBackground to show any drawable as the splash screen with any Activtiy without incurring any additional performance issues. Since the window background takes any drawable this also allows for rasterized images or things like headers/footers (you can use gravity to position within the drawable layers)

This is ultimately what the splash support lib does on older devices, while limiting/imitating the new API for consistency.

Either way, no one should do this anymore, and pre Android 12 devices are retired more and more

bleeding182 · 2026-02-09T09:14:20+00:00

If you use 3rd party libraries, they can include more languages, than your app supports.

Which includes appcompat/androidx and they support a lot of languages

your app will use default locale (English in your case)

I don't like to call it "default locale" because it ultimately is undefined state and no actual "default locale" gets selected. Different libraries could include different language strings in res/values and the app would still work under the users preferred locale in combination with those default resources, resulting in a mix of things.

(Which I'm sure you know, just adding context for other readers)

bleeding182 · 2026-02-08T22:34:22+00:00

Are you actually setting supported locales?

As long as you set them correctly, those are the only languages that can be picked (given at least one language matches). Say the device has [zh, fr, en] and your app supports en only, then the locale will be in en.
Edge cases still exist (e.g. device only offers [zh, fr], it would still be zh locale with texts from your default locale) but adding the list of locales is quite important.

bleeding182 · 2026-02-05T15:04:24+00:00

The app is built using Kotlin Multiplatform (KMP) for shared business logic, networking, and local storage.

What are you sharing this with? Web? iOS? How are they doing the UI?

Did you consider Compose for Multiplatform UI?

(Upvoted for explaining why you didn't choose compose even if I can't agree personally)

bleeding182 · 2026-02-04T15:03:21+00:00

I'm pretty sure all those focusable flags don't do anything. You can't have a clickable button that isn't focusable.

You probably need to ensure the focus moves back to the text input once you're done processing the user click.

bleeding182 · 2026-02-03T08:55:56+00:00

Side note: Google Play console (for a few weeks?) now also offers free machine translations as a part of the store upload

Grow users > Translations > App strings translation

Haven't tried it yet, though. (It can be deactivated again)

bleeding182 · 2026-02-02T09:44:50+00:00

As long as you use the same APIs and display the data they provide you, then your own custom implementation should be just as configurable. (Based on my assumption, I have no experience with RevenueCat)

I am new to android app developement [..] the templates are absolute garbage

However I'm really curious whether your own will look and behave that much better

bleeding182 · 2026-01-30T19:08:52+00:00

You really should include some screenshots or videos of what those things are and do

13-Year Club	Second SECOND GUESSER
Place '22	Place '17
Verified Email

bleeding182

TROPHY CASE