AOSP-CarLauncher介绍
Car Launcher作为车载Android的桌面启动器,是车载Android的入口应用。
Car Launcher作为车载Android的桌面启动器,是车载Android的入口应用。
在 Android 7.0 发布之前,Android 仅使用 GNU Make 描述和执行其构建规则。Make 构建系统得到了广泛的支持和使用,但在 Android 层面变得缓慢、容易出错、无法扩展且难以测试。Soong 构建系统正好提供了 Android build 所需的灵活性。
我们知道像系统中的AMS,WMS,PKMS等这些系统服务均是通过ServiceManager.addService("xxx", new XXManagerService())
将自己的Binder Stub注册进入SM才能够让其他进程利用Binder与之通信。
我们开发过程中常见的ActivityManagerService,WindowManagerService,PackageManagerService等等都属于系统服务,运行于SystemServer进程,并且向ServiceManager进程注册了Binder以便其他进程获取binder与对应的服务进行通信。同样,在AOSP中我们也可以加入我们自定义的系统服务。
Android 系统预置 APP 是做 Framework 应用开发经常经常会遇到的工作,预置 APP 分为两种,一种是直接预置 APK,一种是预置带有源码的 APP。
开启新世界,开始搞机啦,第一步就是先整系统源码。
Android的插件化开发经过这么多年的发展,已经比较成熟,也诞生了很多优秀的插件框架,比如VirtualApk、RePlugin、Shadow等。其实所有支持四大组件的插件框架,都在解决一个问题,就是绕过Manifest注册表校验。传统的做法就是通过Hook技术,欺骗Android系统,注册表插桩,让系统认为启动的是插桩的四大组件,实际loadclass插件的类。
插件化技术最初源于免安装运行 Apk
的想法,这个免安装的 Apk
就可以理解为插件,而支持插件的 app
我们一般叫 宿主。
想必大家都知道,在 Android
系统中,应用是以 Apk
的形式存在的,应用都需要安装才能使用。但实际上 Android
系统安装应用的方式相当简单,其实就是把应用 Apk
拷贝到系统不同的目录下、然后把 so
解压出来而已。
APP经过长期迭代后随着业务的臃肿就会逐渐呈现出某些点位上有阻塞卡顿的地方,这就需要我们要采取一些行之有效的方案去监控发现,并尽早介入解决。
所谓组件化,就是将整个庞大的项目以业务逻辑进行拆分成多个模块,并且各个模块之间相互独立,相互解耦,每一个模块可以单独进行开发调试,各个模块调试完,以library的形式依赖在壳App中组合成一个完整的项目。