There's a lot of bad practices out there. Android dev is actually a bit ahead of iOS development. The problem is that bad practices are commonplace, and most apps are greatly overengineered. So you end up needing 2 Android devs per 1 iOS dev, when the ratio should be closer to 0.8:1.

Google normally has good advice, but they tend to build to scale to a hundred engineers, and that includes "deprecated" stuff. You can go many times faster when building for only 1-2 Android engineers.

My rule of thumb is that if the example looks more convoluted than without it, it probably is. If it's good technology, the examples should make you think, "Oh shit, this is genius," not, "I'm too stupid to understand this."

Pick things up once something is actually a problem. Things with a fast ROI:

Kotlin: write 40% less code than Java

ViewModels: cleanly separates lifecycle stuff and reduces crashes

Network (Retrofit, volley): no more custom async and no crashes when the API changes a little

Compose: cut down all "recyclerview" code by 50%-80%, and have much more maintainable logic

Things with a negative ROI (feel free to argue for them):

Most architectures, e.g. MVP, VIPER, "clean". Architecture isn't a fixed pattern, it depends on what your app is trying to do. Most of the time it's like an apartment trying to emulate a hotel.

Butterknife: Replaced by Kotlin

Event bus: Replaced by Flow

RxJava: Replaced by Flow

Data binding or view binding: Replaced by Compose

Robolectric. It breaks for obscure reasons, takes forever to run (effectively locking you out of TDD). Espresso works. You shouldn't spend more time fixing tests than fixing code.

Android debugger. Idk, TDD catches plenty of bugs and plopping logs everywhere catches the rest.

Looper/threads: Replace with Coroutines

Some of the older UI things like animations, which might be obsoleted with Compose.