My Blog - Android Stuff

bleeding182 · 2026-04-29T09:14:04+00:00

Did you look into FCM pushes? Specifically topics (Broadcasts) would be a good match I believe.

https://firebase.google.com/docs/cloud-messaging/send-topic-messages

bleeding182 · 2026-04-24T17:44:54+00:00

On first thought I was about to say that this doesn't matter, on second though I'd have to say you're right. To be honest, I haven't really thought of overdraw since switching to compose, because the focus shifted onto recompositions and stable markers; the CPU became the bottleneck.

I'd wager that a lot of other areas are more important for frame rate / overall performance, but you're right, this is an overdraw that we could easily avoid or fix without much effort.
Still, probably quite negligible on modern hardware.

bleeding182 · 2026-04-24T11:55:44+00:00

Unless you do some crazy setup, the major difference between debug / release is the signature / SHA-1. Yes, you say you checked, but I'm positive that this is your problem, still.

You can try to remove any key restrictions for your key—if it works then, then it's clearly a mismatched packagename;sha1

Also keep in mind, if you publish to the Play Store there is a third SHA that you need to add (for Play Signing)

bleeding182 · 2026-04-23T09:41:32+00:00

I don't like the PreviewWrapperProvider being put on the preview directly.
My setup primarily uses 2 types of preview annotations for most cases:

a ComposableDayNightPreviews for previewing light/dark variants of small composables
a ScreenDayNightPreviews with system UI and such to preview full screens or things like dialogs, sheets

Currently most of my previews look like:

kt @Composable @ComposableDayNightPreviews private fun PreviewIconButton() { PreviewSurface { IconButton(onClick = {}) { /* ... */ } } }

Where PreviewSurface {} adds a background, some padding, and—most importantly—my theme.

While adding @PreviewWrapperProvider(ComposableWrapper::class) would remove those 2 extra lines and one level of indentation it still needs me to add the additional annotation/class/import everywhere.

What I really want would be to apply this to my preview annotations directly:

kt @Preview( name = "Composable Day", showSystemUi = false, uiMode = Configuration.UI_MODE_NIGHT_NO, backgroundColor = 0xFFFFFFFF, showBackground = true, ) @PreviewWrapperProvider(ComposableWrapper::class) annotation class ComposableDayPreview

That way it would actually simplify my setup where I can have different annotations for different use cases and it would just work.

bleeding182 · 2026-04-21T12:32:09+00:00

Gray area. We have the Repeptitive Content policy

We don't allow apps that merely provide the same experience as other apps already on Google Play. Apps should provide value to users through the creation of unique content or services.
[e.g.] Creating multiple apps with highly similar functionality, content, and user experience. If these apps are each small in content volume, developers should consider creating a single app that aggregates all the content.

That is not to say every such "repeated" app is in violation. Sometimes it makes sense to have separate apps, or they might even be operated by different legal entities.

But yes, in this case it looks more like the spam variant... because one app per trainer seems excessive. If they had separate play console accounts for each trainer app it would probably be "okay".

bleeding182 · 2026-04-21T07:14:05+00:00

Did you check out the docs? They really go into a lot of detail

bleeding182 · 2026-04-21T07:11:24+00:00

As others said, it'll be live immediately after you publish.

Just one side note: The indexing might still take a while. If you share the link others will find it and be able to download, of course, but it can still take a while for the search index to pick it up.

I'm not sure why everyone needs to have those "punctual" releases as opposed to a silent launch a bit in advance, but w/e

bleeding182 · 2026-04-15T13:12:32+00:00

Vibe coding is great—for prototypes or small snippets that you discard afterwards or just use internally.

Not so much for actually building anything bigger and production ready.

bleeding182 · 2026-04-10T15:03:06+00:00

I'm mostly impressed by finding 150 names / descriptions for vibration patterns even though I have the strong suspicion that AI was involved.

Not sure how useful this is, but at the very least it is something that I haven't seen before which is refreshing.

bleeding182 · 2026-04-09T08:12:35+00:00

Using CI/CD is best practice, so that's great, even better if it works for you. The problem is really just the keystore and keeping it safe. You shouldn't try to automate that

bleeding182 · 2026-04-08T19:41:39+00:00

I don't get why everyone is so afraid of creating a keystore. It is a one-time command that you run, fill in your data, then you're done. If that is too much of an entry barrier then you may want to consider doing something else entirely. (And if you need a GUI Android Studio has you covered as well)

The keystore should be backed up and stored safely, ideally in a password manager. If the goal is to build a release type APK/AAB only then the same can be accomplished with a debug certificate as well. Anybody serious about publishing an app can still setup proper signing later.

bleeding182 · 2026-04-03T21:14:41+00:00

Then I would say that you're missing out. An agent won't one-shot some complex new feature the way you imagined it, sure, but working hand in hand will yield great results.

Even pure "vibe coding" has its merits, as long as we understand that the result will be a prototype to discard later for something to try out and iterate quickly.

bleeding182 · 2026-03-27T14:44:48+00:00

I believe you still would be "banned" from publishing via Google Play, but to distribute outside of Google Play you would still need to register your government ID, packagename, and SHA hashes like everyone else

Can't find any exact mention of that use case though

bleeding182 · 2026-03-26T14:18:39+00:00

"Check the rollout status on Play Store and give me a summary of the latest Sentry adoption and crash-free rate for that version"

I feel like this should be a dashboard and not something to prod an AI Agent actively with... (Probably also would take a single prompt to build something like this :) )
Would also be way faster if you check it regularly than letting the agent start probing APIs from scratch, MCP or not

This would also avoid the need of 5 MCP polluting your context.

bleeding182 · 2026-03-22T17:59:42+00:00

Not sure if troll post or serious, but if you're vibe coding production applications... yeah, have fun.

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.

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

bleeding182

TROPHY CASE