Google I/O 2023 kicked off on May 10, 2023, and the Android 14 Beta version has also been released to Google partners recently. This article mainly analyzes what new technology stacks Google has introduced in the Android 14 framework code, and for New features and API changes are beyond the scope of this article.
Compilation system: The use of Bazel is further expanded
When it comes to compiling, for independent applications, the one you have the most contact with should be build.gradle, so I won’t go into details here. In fact, Bazelit can no longer be said that it made its debut on Android 14. Most Javadevelopers , because we are almost all spoiledGradle by it (although it is not so easy to use), and we pay more attention to the development of new technologies. MakeBrowsers or low-level partners may have been in use for a long time.
What needs to be explained first is that it Bazelis not strongly related to Androidcompilation , but it happens to support build Java, C++, Go, Kotlinand other languages, and Android development basically uses these languages. In addition, support Rustfor Pythonis gradually being added, and Google is still very active in Bazelits development.
Turning to the framework, as of Android 13, most of the configuration files you write should still be parsedAndroid.bp by , while the logic related to the underlying configuration is still defined and parsed by , a typical compilation flow chart as follows:SoongNinjaAndroid.mkKatiNinja
When it comes to Android 14, Bazelthe parsing process will be added, and the flow chart is as follows:
Judging from the current roadmap announced by Google, starting from Android 14, all migrated C++modules will be Bazelcompiled by default, and starting from Android 15, Mainlineall modules will be Bazelcompiled by default.
Seeing this, I guess you still don't panic, anyway, the old ones are still compatible, don't worry. However, Google still has confidence in this area. If the problem is not big, and if the official does not abandon the pit (to be honest, Google has abandoned a lot of pits, I understand it all), and when Android 16 is released, the entire compilation system should be able to cut to Bazel.
what to do? what to do? what to do?
study! how to learn Look at the official website ! The official website provides us with a lot of examples . Whether your project is Java or Kotlin, you can find answers to common questions, such as how to reference third-party libraries and how to configure NDK projects.
Microsoft, which has been the most active in embracing open source and new technologies in recent years, wrote an article last year , teaching everyone how to write BUILDfiles , which is also a great reference.
Settings: Kotlin and Jetpack Compose are here
start migrating toKotlin
Google defined Kotlin as the development language officially supported by Google at the IO conference in 2017. By this year, most App developers have already switched over. However, many Android framework developers still seem to sneer at this language, or in other words, they don’t usually use it, and Google doesn’t seem to use it too much in the framework, so there is no need to learn it for the time being.
很”遗憾“，在 android 14 的 Settings 模块，我们开始看到了 Kotlin 的影子。自此，搞框架 App 开发的同学失去了最后一个不学 Kotlin 的借口。
事实上，Settings 模块并不是第一个吃螃蟹的，头部的 SystemUI 模块，早在 2018 年就开始用 Kotlin 改写部分模块了，而且这次 android 14 上还有进一步的演进，这个后面会提到。
我们很多搞框架开发的小伙伴，对于新技术似乎有种本能的排斥，大家的内心 OS 无外乎：
- 这玩意儿都是折腾 App 用的，框架要的是稳定，完全用不到
- Google 自己都没咋在模块里面用到，我干嘛折腾呢？
- 天生骄傲，觉得自己是搞框架的，比隔壁那些搞 App 的高到不知道哪里去了…
希望看到这篇文章的小伙伴，平时千万不要有以上这些想法。我们的认知永远都是有限的，很多时候你这样想，很可能只是因为没有看过别的模块而已，别的模块说不定早就卷入新的技术栈了，就等着弯道超车呢。
怎么办？怎么办？怎么办？
学！Kotlin 怎么学，这个……这么多年了，网上太多教程了，不说了。
引入 Jetpack Compose
说起来这又是一个新的坑，Google 是在 2019 年的 IO 大会宣布了把 Jetpack Compose 定义为 Android’s recommended modern toolkit for building native UI。然而，写惯了 findViewById 的我们，有可能刚刚学会用 ViewBinding，怎么这次直接上 Jetpack Compose 了？
从 Android 14 目前释放的代码来看，Google 新建了一个 spa 包，这个包里面尝试把“应用管理”、“应用通知管理”，还有“使用情况”页用 Jetpack Compose 重写了，这些页面几乎都是纯列表页面，拿它们优先下手理论上不会有太多坑，我猜 Google 也是这么考虑的？
除此之外，还有3个主页面也进行了重写，这三个页面本质上也是列表页：
出于稳健考虑，Google 没有默认使能这些页面。如果你想提前吃螃蟹，可以使用以下命令来开启： adb shell settings put global settings_enable_spa true 通过搜索代码，也可以轻松找到这个开关在哪里被使用：
然后我们可以去到相关页面看一下前后对比：
原生实现
Jetpack Compose 实现
由于 Jetpack Compose 的各个组件一直都在很好地践行 Material Design 3，可以看到后者的视觉还原要更好，也不会出现前者那样 MenuItem 背景颜色不正确的问题。
好了，让我们回到技术本身。其实我知道很多小伙伴拒绝学习 Jetpack Compose，本质上是拒绝学习声明性编程，一看到那种样式的代码就脑阔疼。而我完全理解你痛苦。就像当初学习 RxJava，好不容易从函数式编程过渡到了响应式编程，这次又来了一个新概念，确实内心是拒绝的。
其实编程思维的转变，说难也难，说简单也简单。回过头想一下，当初你看着别人写的 RxJava 代码，一气呵成，感觉很厉害的样子，其实本质上还是因为那个时候你没学会，看不懂 lambda，看不懂那些运算符是啥意思。等你后面学会了，再回过头来看，那种感觉跟初学的时候就完全不一样了。事实上，学习声明式编程也是如此。
怎么办？怎么办？怎么办？
学！幸运的是，Google 给我们提供了详细的指导，大家可以参考 developer.android.com/jetpack/com… 来快速入门上手。而且，这波 Google 自己带节奏，不学看起来是真的不行了。
SystemUI：使用架构最佳实践（Best Practise）重写
当看到这个标题的时候，你一定会觉得很晦涩，但我相信看到下面这张图，你一定不会感到陌生。
没错，这就是 Google 这几年一直在 App 开发层推崇的架构最佳实践。从 Android 14 开始，这套架构被引入 SystemUI 模块，用来解决之前状态栏各 item 的 Controller 和状态之间混乱不堪的问题。
对于 SystemUI 而言，状态栏的每一个 item，无外乎都关联着一个个回调，而回调进来的数据，往往都是外部对象，而 item 本身可能更关心的是自己的内部对象，并且状态一旦变了， UI 是一定要跟着变的，而这个需求恰好是这套架构最佳的使用场景。来看 Google 是怎么重构的：
近年来，Android App 应用开发已经从最开始那种兵荒马乱的年代，慢慢过渡到大家都开始重视应用架构了。从最开始的啥都往 Activity/Fragment 里塞，慢慢到后来有了 MVC，再后来到 MVP，现在又流行的 MVVM，Google 似乎最终也站稳了立场。
怎么办？怎么办？怎么办？
学！关于 app 架构最佳实践 的详细内容，可以参考 Google 官网的这篇介绍。需要注意的是，要想更方便地运用这套结构，依赖 注入 （DI） 往往是必不可少的，SystemUI 其实很早就在用依赖注入了，目前依然是 Dagger，而其实 Google 这几年一直在推进他们基于 Dagger 演变的 Hilt，这是一套更适合 Android 平台的依赖注入框架，大家可以从这里了解到具体详情。另外，Kotlin 协程，和对数据流（Flow）的理解也是必不可少的，这部分大家也可以参考官网。
我的个人建议是，大家先学习依赖注入（DI），再学习 Kotlin Flow，最后再回过头来入门这套架构，这套学习路线应该是比较正确的。
福利： Android Studio for Platform 要来了
文章最后带来一个好消息，那就是 Google 在今年总算良心发现，想起了我们这帮苦巴巴的搞 Android 框架的平台开发者，在继 AIDEGEN 之后，他们正在搞 Android Studio for Platform 。
从目前放出的预览图来看，整体应该至少是基于 IDEA 2022.3，因为默认启用了 NEW UI，然后平台开发会用到的应该都会支持，但何时能放出下载官方暂时还没有说，希望 Google 能好好搞，求别弃坑。
总结
At this point, I want to go back to the title of this article. Careful readers will find that I put quotation marks on the word "new" of the "new technology stack". Why? Because for those who pay attention to technology development, at the same time, Android application layer and framework For students who work in between, these are actually not new technologies, and some can even be said to be "leftovers" at the application layer. Why are these technologies introduced into the Android framework until today? I think it is nothing more than for the Pursue stability, just like Kotlin was also in the community back then. It has been popular in the App development layer for many years, and Google only got involved later and finally introduced the framework. It takes time to verify the feasibility and stability of many things. I personally appreciate it The technical pragmatism of major foreign manufacturers is not like many domestic manufacturers who make things that are not yet stable or have not passed the test of time.
Everyone learn it!