AOSP下的系统开发

修改aosp三个的方面

• 系统app开发
• framework层定制
• native层定制

AOSP开发的覆盖面是非常广的：

1. 第一个方向：以前是搞android应用开发，现在负责系统application开发，这样就会上手非常快，只需要对osp有基本了解就可以了。但有时候在解决bug的时候,需要对下层有所了解。就会逐渐的走向framework层的开发。在framework层中做实现，修改，定制的过程中，就会逐渐的接触到native层,这是由上走向下。
2. 第二个方向：以前是搞linux内核以及驱动的，由于linux内核和驱动都是以C语言为核心的，这样接触native层也是如鱼得水的。在native层定制接口的时候，可能需要和上层(framework层)的人进行配合,在配合中,要了解framework层是如何做的,如何使用接口的,怎么去调用的。从而会去学习java的语言。这样干脆就做application去了，这是由下走向上。

1. Android的启动流程简述

现在首先了解android的启动流程,以此加深android系统的了解

android启动流程.jpg

2. 系统app开发

在packages/apps找到需要修改的相应app。在该app目录中是属于java的部分，与android应用的开发语言相同。但是与平常的app在androidstudio编写不同，在源码环境中，需要利用编辑器来进行编辑。并且在源码中的编译就需要利用make编译系统进行编译。源码的编译是以模块进行。利用mm命令进行编译。编译完成之后，会生成odex以及apk。与普通的apk的结构不同，系统编译生成的application分成了两部分：

1. apk包括了签名，资源，AndroidMannifest清单文件,资源的二进制文件。
2. 而原本的classes.dex则被放在了odex这一部分中。

为什么apk分成了两个文件，这就是Dalvik与art虚拟机的区别：

Dalvik：
JIT(just in time)实时编译,运行的时候将字节码翻译成机器码,所运行的目标文件与硬件平台无关,app运行效率低
ART:
AOT(Ahead of time)预先编译,运行前将字节码翻译成机器码,所运行的目标文件(oat)与硬件平台相关.app运行效率高。但会占用空间。APK安装所需时间增加

2.1 odex是干什么的

• Dalvik时代：apk运行的时候，会把apk的classes.dex解压出来并通过dexopt优化为.odex文件,缓存在/data/dalvik-cache目录下,提高后续执行的效率。这也是android被诟病的比较卡。
• ART时代：apk安装的时候，会把apk的classes.dex解压后,通过dex2oat工具转化为.odex文件(ELF格式，与Dalvik时代的.odex文件完全不同，只是为了和以前的Dalvik时代的命名相同，内容完全不同),存储在apk所在目录的oat目录下。用空间换时间

2.2 为什么在源码环境编译生成了odex文件

ROM：apk，jar，bin，so等组成
优点:

1. 降低系统更新后启动的时间：
   未做odex的Rom，首次开机的过程会执行odex操作。编译时做，开机时候就不用做了
2. 减少在设备上进行odex操作所造成的空间浪费：
   编译时进行dexopt/dex2oat，会直接将apk资源与代码拆开。如果在设备上安装时进行dexopt/dex2oat,apk的大小不会减少,但又会多一个odex文件占据磁盘空间

缺点:

1. 增加开发的编译时间
2. 不能直接执行apk的install操作,需要将apk和odex都sync到设备上

2.2.1 如何在开发阶段关闭dex2oat

• 在当前module的Android.mk里增加:
  LOCAL_DEX_PREOAT = false
• 在build/core/main.mk中关闭所有module的dex优化:

## eng ##在lunch命令时选择eng版本
ifeq($(TARGET_BUILD_VARIANT),eng)
tags_to_install := debug eng
#关闭odex优化
WITH_DEXPREOPT := false

odex优化只在linux环境下生效

3. Framework层定制

Framework的定制,一般是为了满足app层或者整个系统的某一种需求。

1. 确定要修改的Framework层服务在哪(一般在源码的frameworks目录下)
2. 修改要定制的代码
3. 用mm命令进行module的编译
4. 用编译生成的文件(如framework.jar,services.jar等)替换设备中的文件(一般在system/framework目录下)
5. 重启系统：

#只重启安卓系统:
stop;start

6. 验证修改(通过日志等方式)

4. native层代码

native层的定制，一般是为了满足framework层代码的调用需求。Native层分为两部分JNI(AndroidRuntime)和natie。JNI层是native层C/C++与framework层java交互的桥梁。

4.1 修改jni层:

1. 从framework层往下层寻找jni的native实现。

jni的规范：
例如framework层中的android.util.Log.java这个类中的jni：
该类的包名加类名为:android.util.Log
将"."改为"_",则为android_util_Log
则该类native的实现就在android_util_Log这个文件中,在源码中找到该文件进行修改

2. 修改之后在jni实现的目录下，执行mm命令进行编译
3. 将编译生成的文件(如libandroid_runtime.so等)替换设备中的文件(一般在system/lib/目录下)
4. 重启系统

#只重启安卓系统:
stop;start

5. 验证修改(通过日志等方式)

4.2 修改native层

还没了解到,未完待续....