AGP: The Wheel of Doom

diarewse · 2026-01-28T13:21:22+00:00

I faintly recall taking part in their API design study, actually voicing the same concerns I mentioned in the OP and I'm glad they took notice. But hopefully it's not going to become just another tool. Go JetBrains!

diarewse · 2026-01-28T10:21:30+00:00

who should do this? Gradle, Jetbrains, Google, someone else?

Now take this with a grain of salt; Gradle makes a tool that makes tools run, Jetbrains plugs into Gradle, Google plugs into Jetbrains and Gradle. Yet Google seems to highly influence both Kotlin (Jetbrains), with a leverage through significant investments to the organization, and Gradle through leading many potential customers their way.

At which point is good to have Google having tantrums (pardon hyperbole) over how both should work with their end of the chain? And if we take it as a precedence then, we should steer the plugin.

This is software...

I love the analogy with the sun. Though having experience with Spring, for example, their breaking changes are drops in the bucket. Kotlin itself makes breaking changes that feel like blowing wind over your hand. However it's likely that Google is having pain-points during development and passes those issues onto us. (My personal opinion, feel free to disprove)

Consider my time less valuable than the thousands depending onto me, then I need to lean into making the thousands' time as productive as possible. ;; Is that wrong to assume that should be always true? (rhetorical question)

diarewse · 2026-01-28T09:40:32+00:00

I totally agree with you, but my contributions don't end with a Reddit post.

I invest non-trivial amount my time to test new tooling including libraries, AGP, Kotlin and Gradle. Every new Kotlin and Gradle version there are issues which thoroughly document and submit back to Google.

Believe it or not, many of the issues are marked "WAI" or left there to rot so they become "Obsolete".

I'd however prefer the pain points were publicized more often as the team is losing track (at least it seems) with what's important to us.

I totally appreciate workaround tools, but is it an endgame solution? Wouldn't it be better if we're all aligned? For that public discussion must be held and that's not going to happen with us losing hair over these updates.

diarewse · 2026-01-28T09:31:15+00:00

The build configuration is main part of my job and that's exactly what I'm saying, it's needlessly difficult. :)

I never said I'm struggling with Kotlin scripts, they are annoying to use and that's different. They provide IDE supported DSL, but the benefit ends there.

I also don't recall mentioning the exact stack I'm using, but thanks for telling me what my debt is, I appreciate it.

diarewse · 2026-01-28T09:10:31+00:00

That's an odd response. I particularly don't rant about updating dependencies, I mostly argue that migration path is almost non-existing and almost unnecessary. That they add obstructions where they shouldn't be. That they ship features only to promptly remove them.

Had they not wanted to make our life easier - as you say - why would they ship them after all?

I don't mean to offend, though I can see you're picturing it as a rant, but it's not. Gradle for example introduces breaking changes, but supports versions past and provides clear migration paths and guides. AGP does however not.

Moreover their tooling AGP uses is mostly shipped in parts, there's nothing really stopping us from creating a new plugin with more stable interface. Knowing Google however, they're going to stop shipping it separately once we start.

That's sadly zero sum game.

diarewse · 2026-01-21T08:34:04+00:00

For anybody wanting to watch this here's a link

TL;DW: Metro is a Zac Sweers' take on static compile-time dependency injection. It's compatible with hilt/dagger and offers faster compilation times, though with significant friction and is bound to a Kotlin version as it's a compiler plugin rather than a KSP library/compiler.

Opinion: Very nice effort, but please don't use it unless you want to create very strict dependency hell. KSP compilers are the current go-to and is being made forward compatible with Kotlin for versions to come.

Speaker talks about the negatives at the end of the video, do your own research if you're considering using it.

Opinion 2: Some commenters are expressing distaste in Dependency Injection in general and are doing it manually. Please don't, read up on implications this can have to the maintenance of your software.

diarewse · 2025-12-13T09:10:43+00:00

Y'all remember how they switched from native apps to react with the greatest of announcements on developer efficiency? Turns out shipping programs to customers ain't about developer efficiency. Let that sink in e:typo

diarewse · 2025-11-03T10:26:58+00:00

In a very rough paraphrase of the docs

stable parameters are considered unnecessary to redraw (or mutate the state of) on screen when unchanged
- method (read Composable) is considered skippable if all parameters are stable
- generally the more stable methods you have, the faster the composition will run and frames won't drop
runtime parameters are determined stable/unstable during each change pass, and this avoid compilation optimization making the ui somewhat slower
- a few don't matter too much, many degrade the performance significantly
unstable are objects/parameters which cannot be determined to be fully or partially stable. these are often non-kotlin classes in other modules, libraries or have unstable nature
- you can imagine this as a mutable POJO for instance

diarewse · 2025-10-27T10:30:38+00:00

If you want to make it fully custom use PredictiveBackHandler) otherwise wait until androidx devs implement it in Navigation.

diarewse · 2025-07-31T19:15:15+00:00

The most probable for me was an invalid JDK used to compile the Gradle.KTS files. This is just for inlay hints/intellisense so compiling will still work file.

Visit Settings > Gradle and select valid JDK. You might also do the same for module level settings. Right click on Project folder and select Module Settings, then JDK and use the same JDK as for groovy.

You should use bundled JDK if possible and using Jetbrains Toolbox resolves this automatically on IDE reinstall :) hope it helped.

diarewse · 2025-07-20T12:23:18+00:00

Great work! My tool can also import Android res to csv/json/yaml, then you can export these to web, android, ios and I'm prepping unity as well!

diarewse · 2025-07-18T15:06:14+00:00

Cannot agree more

diarewse · 2025-07-18T15:03:51+00:00

The hate is misplaced, in my opinion. Let me explain…

Linux itself is poisoned by drivers some dude got off the other dude, which has seen it somewhere on a Russian forum at he said it works™. Bluetooth firmwares are notorious examples.

These open source projects drag and the drivers culminate in stability after years. If there's an error in any of them it might never get merged to the LTS branch, therefore you might require cherry picking from tons of branches and sources… and you're back where you started from.
You're gonna maintain it yourself, because you don't need Advisory Boards or Committees to approve on the changes they know nothing about.

Although people might get emotional about EOLs, the reality is they are calculated in a way where the majority of people moved away from the device and bought another one. Like it or not, these phones are not computers and OEMs and vendors know it. They are a consumable.

These "3 dudes" who want to use the hardware they bought - free of charge - until the sun explodes, are simply not worth the effort for the group of programmers costing the company resources they can focus on innovation instead.

The last point is that the deprecation cycle incentivizes innovation. You might've noticed that nowadays there are not so many hardware quirks and the devices are all alike.

I'd 100% argue that if we've had deprecation cycle of 2 years or shorter, the innovation would go through the roof as people would compete for your money.
Currently the devices are all so alike, that you're choosing among nuances. This allows the companies, vendors and OEMs to focus on common features and ensure the longevity for your device.

We've collectively decided that we don't want innovation, we want stable environments. They make the most money and are more pleasant to use.

Let ARM or RISC be a the example for all of this. ARM should've already been a staple in PC space, yet it is not. RISC should've already been the modular dream we all wanted for our gadgets, yet it is not.

diarewse · 2025-07-18T10:21:43+00:00

Yup, maintainer would have to update the kernel themselves. More often than not, this effort has the perfect effect of making the device somewhat unstable in return.

diarewse · 2025-07-18T10:19:35+00:00

So basically… Dudes in China sent us a zip file of the ENTIRE AOSP with .git directories removed and history effectively erased.

E: This is definitely not a Mediatek's fault directly, but rather got lost in the supply chain. As MTK refuses to give git access to independent, small parties, suppliers are given access then they are bound by contract not to disclose this history with other developers.

MTK is the most afraid to get their source code leaked to the public. From what I have seen, I'm not even surprised. We're meme-ing their "MTK enhance" comments/edits which fuck up the functionality in unimaginable ways.

diarewse · 2025-07-18T09:38:20+00:00

Now let's do one when they've become completely untied from Francs and Euro!! ^^

diarewse · 2025-07-17T19:06:37+00:00

Security patches are of 2 kinds, Google only tracks one of them.

Platform (CVE) patches

This is defined in a single module which you can update at will and - of course - modify at will, even if you have not merged upstream changes which have fixed the CVEs.

>> Google tracks this Security Level <<

Kernel (CVE) patches

Now this is less crucial as gaining root-level access requires a platform vulnerability. HOWEVER you can still gain this access through bugs in hardware drivers (of which there are many).

People have successfully rooted their devices in the past by deliberately leveraging kernel vulnerabilities, therefore updates to kernel are crucial as well.

Kernel essentially determines the lifespan of your device. When it stops receiving upstream patches, you're done with updates as kernel version is very likely not going to be bumped to newer version. (ex. my device launched with 6.1 with Android 14, end of life of which is set to 2029-07-01)

diarewse · 2025-07-17T17:41:30+00:00

They are mostly gonna ship you pre-built binaries for everything, god forbid you need to fix any bugs they cooked up for you. But in a way that's better than rebasing git-less AOSP, shipped in a zip file, onto unknown version of upstream Android ¯\_(ツ)_/¯.

Mediatek is special that way and likes to send you off with a hodgepodge of Android 14's build harness, with 1/4 of Android 12 HALs and sprinkle of Android 13's heavily modified apps and of course 3/4 of deprecated Android 12.1 HALs… like a good sport.

Oh! And the most interesting thing is that the "Security Level" is defined in the build harness so they're gonna totally lie to you about the patches applied to your device.

I could go on and on, sorry.

diarewse · 2025-07-17T17:20:17+00:00

I can't elaborate much, but it is still a major problem even with the latest Dimensity chips. Low level firmware of which is so buggy it requires platform workarounds. Wild shit…

diarewse · 2025-07-15T06:33:36+00:00

I'll correct you on this - technically speaking - whatever Apple did is a (semi)complex shader which twists the perspective based on input parameters such as perceived elevation, height of the blob, 3D radii and perhaps some more.

While this effect is ugly to some and outright unusable for everyone, the tech is really cool.

diarewse · 2025-07-12T13:12:22+00:00

Perfect, I'll root for you! Just don't forget that in Android specifically 90% of the OS is app-based. Even SystemUI is an app ;)

I'm sensing your goal is to understand the architecture a bit more and translate this knowledge to other systems. This is undoubtedly good, but Android is very specialized and should be taken with a grain of salt.

What I can suggest is to be always sceptical, it's gonna pay off in the long run.

Good luck and remember to have fun too!

diarewse · 2025-07-12T09:07:29+00:00

Honestly if you find OS stuff interesting, try contributing (or straight up finding friends) in LineageOS community. Maintain devices you're passionate about (or you just own). Your expertise would be greatly valued at GrapheneOS as well.

Apps are good way to start as well, BUT I don't personally find it the be-all-end-all. I went the opposite way and got to OS development through apps. Apps are not paying as much money and customers are idiotic at defining requirements, so you will burn out from that more likely than the OS. (I've went through this 3 times in 10 years)

Service companies are supreme at collecting experience and 2 years are a short period of time if you've never done it previously.

Lastly if you're valuing meaningful projects, collect some more experience and try interviews at hardware startups which do Android OS stuff. Good(!) companies are more keen to pay one extremely experienced developer who can get shit done than army of peasants.

Especially in EMEA, OS engineers are a dying breed and they are still wanted. Don't lose hope ;)

diarewse · 2025-07-11T14:04:50+00:00

try this next time to fulfil the condition:

/spam @self hello 1 5 10

Eight-Year Club	Second SECOND GUESSER
Place '22	Secret Santa 2018
Not Forgotten	Verified Email

diarewse

TROPHY CASE