I've been wondering what are the things that need to be done before then android platform/os can tak...

# compose

[Rahul Sainani]

I've been wondering what are the things that need to be done before then android platform/os can take advantage of Kotlin and Compose?

[Kirill Grouchnikov]

Done where? By whom?

[Rahul Sainani]

In other words, what's stopping platform apis and implementations from using Kotlin and Compose.

[louiscad]

It's a non-goal. Using Compose in the Android platform itself would prevent apps from using a newer version. The fact that Compose is unbundled from the platform is a feature, perhaps its most important feature.

[Adam Powell]

There's nothing stopping most of the OS itself from adopting kotlin and compose today in the same way that apps do, since much of the OS as you experience it is already represented by different "apps" where their code isn't on the base class path that incurs the version coupling described.

[Adam Powell]

For example, the launcher and system UI are in their own packages, as is the package installer responsible for showing permissions prompts, etc.

[Adam Powell]

I'm pretty sure both systemui and package installer are already using kotlin

[Adam Powell]

https://cs.android.com/android/platform/superproject/+/master:frameworks/base/packages/SystemUI/src/com/android/systemui/ bunch of .kt files in here 🙂

[Adam Powell]

the system server is also in a position to move to kotlin, though as it doesn't show UI itself as a general rule it wouldn't benefit from compose (though we've had some instances of it in the past, most if not all of them have moved out to other packages)

[Adam Powell]

the biggest benefit to bringing kotlin into frameworks/base/core would be to offer more natively-kotlin API shapes in new platform APIs, but androidx libraries are increasingly filling that need

[eygraber]

👆 and null safety 🧌

[ephemient]

you probably don't want kotlin-stdlib to be bundled with the framework...

[Adam Powell]

null safety for platform APIs can already be provided with the nullability annotations and retrofitting them over the past few years hasn't always been a clear win. Declaring stricter nullability is source breaking for kotlin users and many APIs were never really shaped for anything other than ambiguous nullability. A great example is findViewById - yes it can return null, there's no question about it. But common usage patterns are such that if it does, there's a programming error somewhere else.

[Adam Powell]

the NPE from a platform type error in the worst case is just as useful as having to be strict across all of the associated calling code.

[eygraber]

I meant for internal usage, not for the platform APIs. I guess it doesn't happen as often anymore (maybe because of the annotations), but there used to be a lot of crashes related to something internal throwing an NPE

[Adam Powell]

not just the annotations but better error hygiene in general for new APIs and high traffic paths. A lot of code that existed back before android 2.2 (when android was interpreted only, no aot, no jit) aggressively skipped precondition checking for bad inputs for performance reasons and was never revisited. The underlying issue there is revisiting that code more than which language it's written in.

[Rahul Sainani]

Thanks for the detailed insights @Adam Powell 🙌

[Michal Klimczak]

This channel is generally great for learning about android internals. The android community lacked something like this for years. You're doing great job for the community @Adam Powell (and the rest of the team).