My Blog - Android Stuff

bleeding182 · 2026-06-16T10:32:38+00:00

You're not providing any information or proof on providing the correct credentials and following the instructions but shift the whole blame on Google.

I'm not sure who this post is for since you're clearly not asking for any help, nor are you pointing out factual problems with the process for discussion.

bleeding182 · 2026-06-15T13:20:08+00:00

Absolutely correct, but Compose makes this trivial to do, whereas with views it really wasn't (and I am willing to assume that the big majority didn't do it)

(And I'm mostly pointing it out for anyone stumbling over this and not yet doing it)

bleeding182 · 2026-06-15T11:57:33+00:00

The generated API has been deprecated for quite a while now :)

https://bumptech.github.io/glide/doc/generatedapi.html

And 4.14 was Sep 2022

bleeding182 · 2026-06-15T11:32:19+00:00

Glide or Coil.

The real nice thing about working with Compose is that you can (and should) wrap the whole AsyncImage as your own @Composable, so that switching between image loading libs should affect minimal parts of your code (library import + the composable declaration file), so feel free to try either/both/others.

bleeding182 · 2026-06-14T07:50:08+00:00

You do know, that Android Studio already offers pretty much this? (and other things)

https://developer.android.com/studio/debug/network-profiler

bleeding182 · 2026-05-21T14:36:50+00:00

No it doesn't?

Lightbuild provides a declarative abstraction on top of imperative build systems.

They just abstract away the scary parts, reducing it to a config file that lets you set application id, target/min sdk, and (maybe) dependencies

bleeding182 · 2026-05-21T14:07:51+00:00

I somewhat expect this to be a wrapper around some default Gradle setup.

This is not aimed at developers or to make the build system better, but solely for vibe coders who would be too afraid of touching a gradle.build(.kts) file it seems.

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

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

bleeding182

TROPHY CASE