也许每个人出生的时候都以为这世界都是为他一个人而存在的，当他发现自己错的时候，他便开始长大
少走了弯路，也就错过了风景，无论如何，感谢经历
本篇文章遇到排版混乱的地方，可点击文末阅读原文或前往该地址：https://orangey.blog.csdn.net/article/details/126219831
关于Android安全的知识，可前往：https://blog.csdn.net/ananasorangey/category11955914.html
反编译Apk替换Apk中英文的字符串位置，找到需要汉化的字符串位置，然后修改成对应的中文即可，但某些apk把相关要汉化的字符串放到底层里，也就是so文件中，此时会比常规的替换要有一些难度，我们不能像往常一样修改smail文件(apktools工具修改smail文件和添加中文的string.xml)，需要去修改so中的内容，so文件因为底层(native层中)都是指针操作字符串，而且还涉及到字符串的地址。需要了解so文件的格式，才能做相应的修改
010Editor：查看16进制的工具，比UE轻了很多，也很好用
HexEditor(HE工具)：手机上的十六进制查看工具
hiero：制作字库用工具
Xplore文件管理器
浮游生物：孢子的世界
IDA 7.5 Pro：逆向领域中堪比Android中的AndroidStudio（可以去吾爱破解上找破解版的）
NDK：编译so文件时需要用到，所以需要用到他
补充：Java中不会接触到指针的概念，但是用IDA分析so的时候是汇编指令，都是地址，地址就是指针，指针就是地址，例如如下代码中定义一个字符串：
char *orangey="Hello world Orangey"
orangey参数就是一个指针，指向Hello World中的首个字符，也是这个字符串在内存中的首地址，但这个地址不是绝对地址，而是相对地址。是绝对地址减去偏移值
用IDA打开so文件，用Ctrl+S搜索，到这个段得到起始地址，然后在用010Editor打开
IDA：Shift+F7快捷键打开段窗口
在修改文件的内容的时候，一定不能影响到其他内容的地址，这样会导致其他信息的偏移值发生变化之后，代码就会异常报错的
修改字符串时需注意事项：
如果修改的字符串的长度和源字符串的长度相等，直接替换即可
如果修改的字符串的长度比源字符串的长度短，需要用空字符串进行补齐
如果修改的字符串的长度比源字符串的长度要长，需在.rodata段、.data段、.string段找到一块空地，在哪里添加一个字符串
十六进制算法：
当前位不够减，向高位借1，当做16使用
被低位借走1后，当前位就不够减了，还得再向高位借1，并当做16使用
被低位借走的1，运算时要减去
当前位本来就不够减，还被低位借走1，所以必须向高位借1，并且借到后当做16使用
在线十六进制计算地址：http://www.99cankao.com/digital-computation/hex-subtraction-calculator.php
用IDA打开so文件，用Ctrl+S搜索，到这个段得到起始地址，在用010Editor打开，看到存在一大片空字符串的地方，可在这里添加一个字符串，添加完之后需要再改一下十六进制地址，用当前绝对地址减去偏移量，得到减去后的值后，这时候要用HE在so文件里搜索减去后反过来的值(要反过来)
ELF文件在被映射时，是以系统的页长度为单位的，那么每个section在映射时的长度都是系统页长度的整数倍，如果section的长度不是其整数倍，则导致多余部分也将占用一个页。所以section段的位置和长度不是随便添加的，要根据program header头的align对齐方式来添加
新加入的section一般是在文件末尾，但并不是真的文件末尾，而是将文件加载到内存映像中的末尾，但一般等于虚拟地址vaddr+占用空间大小memsiz，还要做字节对其，以及文件末尾不等于映像末尾，一般这个映像末尾比文件末尾大，因为操作系统对内存都是以页的粒度来操作的，所以添加section段要找到真正的映像末尾，操作系统会把program header的type为LOAD的段加入内存映像中，而LOAD类型的program header一般都是做升序排列，只需要取最后一个LOAD就可以，让vaddr+memsiz在和align做对齐操作就能够得到映像末尾
详情了解前往如下：https://www.jianshu.com/p/a2d87d9467cc
静态分析的流程
使用apktool来反编译apk
得到程序的smail源码和AndroidManifest.xml文件
直接解压apk文件得到classes.dex文件，然后用dex2jar工具得到jar,用jd-gui工具查看
全局查找关键字符串和日志信息
代码的注入技术
使用系统的Hook技术，注入破解程序进程，获取关键方法的执行逻辑(Cydia和Xposed框架)
使用IDA来静态分析so文件
动态分析步骤：
apktool反编译apk
java -jar apktool.jar d xxx.apk
修改AndroidManifest.xml中的信息，改成可调式模式(AndroidManifest.xml 的android:debuggable="false" 改为true)
回编译
java -jar apktool.jar b -d test -o debug.apk
注：test是之前反编译的目录，debug.apk是回编译之后的文件
用系统自带的签名文件即可签名：
java -jar .\sign\signapk.jar .\sign\testkey.x509.pem .\sign\testkey.pk8 debug.apk debug.sig.apk
注：step1:Android Studio 采用gradle命令assembleRelease生成未签名的apk
step2:系统签名，Android自带的签名工具为 signapk.jar， 可以在源码编译目录out中找到，具体路径为：out/host/linux-x86/framework/signapk.jar 以上APK具有系统权限，重新签名应该使用platform签名文件进行签名。
签名方法：将对应权限的签名文件platform.pk8、platform.x509.pem， 签名工具 signapk.jar， 以及需要签名的apk（假设 old.apk） 放到同一目录下，打开linux终端（windows cmd也可以），进入该目录，进行重新签名。
使用java自带的命令jarsigner进行签名：
jarsigner -verbose -keystore [ 密钥库] -signedjar [签名后的apk] [待签名的apk] [密钥库里的别名]
回编译后程序运行失败，是内部做校验，一般做校验的话，有两种：
对dex做校验，防止修改dex的
对apk的签名做校验，防止重新打包
onCreate方法，但是这里我们一般找的方法是：
1、首先看这个类有没有静态方法和静态代码块，因为这类的代码会在对象初始化之前运行，可能在这里加载so文件，或者是加密校验等操作
2、再看看这个类的构造方法
3、最后再看生命周期方法
Android中的Apk程序其实就是一个压缩包，可用压缩软件进行解压。
Android中的apk程序本质上是一个包含资源和汇编Java代码的压缩(.zip)包，其中最核心的三个文件 分别是AndroidManifest.xml、classes.dex、resources.arsc
开源工具Apktool 工作原理就是解析这三个文件格式。apk解压后AndroidManifest.xml(清单文件)用普通文本格式打开的话是乱码的。
这是因为在打包的过程中，清单文件被编译成二进制数据，存储在apk安装包中。之所以称之为清单文件，因为它的确是应用的 “清单”。它包含了应用的包名，版本号，权限信息，所有的四大组件等信息。在逆向的过程中，通过 apk 的清单文件，我们可以了解应用的一些基本信息，程序的入口 Activity，注册的服务，广播，内容提供者等等。
如果尝试查看过 apk 中的 AndroidManifest.xml 文件，会发现是一堆乱码，因为在打包过程中，清单文件被编译成了二进制数据存储在安装包中。需要我们了解 AndroidManifest.xml 的二进制文件结构，才可以读取到我们需要的信息。这一步可以使用开源工具读取编译后的清单文件，像 AXmlPrinter , apktool 等等。当然，正是由于这些工具都是开源的，一些开发者会利用其中的漏洞对清单文件进行特定的处理，使得无法通过这些工具反编译清单文件。如果我们了解其二进制文件结构的话，就可以对症下药了。
总体上按顺序分为四大部分：
Header : 包括文件魔数和文件大小
String Chunk : 字符串资源池
ResourceId Chunk : 系统资源 id 信息
XmlContent Chunk : 清单文件中的具体信息，其中包含了五个部分，Start Namespace Chunk 、End Namespace Chunk 、Start Tag Chunk 、End Tag Chunk 、 Text Chunk
二进制 AndroidManifest.xml 大致上就是按照这几部分顺序排列组成的，下面就逐一部分详细解析。在这之前还需要知道的一点是，清单文件是小端表示的，ARM 平台下大多数都是小端表示的
一系列代码功能接口与资源数据的有机集合
Android SDK 即是大量库文件的集合
开发兼容不同版本系统的 APK 时，要引用 Android SDK 中不同版本的 android.jar 文件（开发中使用最多的库）
第三方提供的地理位置 SDK、数据统计 SDK、广告 SDK 等都是库文件
引用第三方库文件可能带来安全风险（获取用户数据、监控用户行为等），应对它们的“内幕”有所了解
Android Studio 问世前，Android 平台软件开发主要用 ADT 工具包完成。ADT 工具包的 IDE 是 Eclipse，库文件使用 Java 语言中标准的 jar 包。jar 包其实是一个 zip 格式的压缩包文件，存放着编译后的 Java 代码的 class 文件的集合。因此称 jar 文件为“jar 包”
查看 android.jar 的格式和内容（命令行输入 bash，进入 Bash on Ubuntu on Windows 的 Shell 模式，配置方法如下：
Windows 10 中，可使用全新的 Bash on Ubuntu on Windows Shell 模拟环境。该环境随 Windows 10 的 Linux 子系统提供。 安装步骤：
1）升级到 Windows 10 以支持开发者模式 2）在 “设置”的“更新和安全”中选择“开发者选项”，然后选择“开发人员模式”
3）打开“控制面板”，选择“程序与功能”，然后选择“启动或关闭 Windows 功能”，然后勾选“适用于 Linux 的 Windows 子系统”，系统会下载更新并提示重启计算机
更新和安全”中选择“开发者选项”
重启后，打开命令行，输入“bash”命令，会提示继续安装 Bash on Ubuntu on Windows。选择“yes”，系统会安装相关的系统文件。安装完成后，会切换到 Shell 模式 在 Bash on Ubuntu on Windows Shell 环境中，安装软件包的命令为：
sudo apt-get install 软件包名
安装好后再输入如下命令：
file android.jar
unzip -l android.jar | less
PS：部分对安全性要求较高的 jar 包，会对包含的 class 文件进行签名，签名信息保存在 jar 包的 META-INF 目录 分析 jar 包有静态分析和动态分析两种
静态分析
可使用 jd-gui 这类 jar 查看工具，jd-gui 内部会调用反编译接口，将 jar 包中的 class 文件编译成 Java 文件，并将结果显示，如下图：
也可将 jar 包反编译称 Java 文件，导入 Java 编辑器中查看。选择 jd-gui 菜单项“File” -> “Save All Sources”即可保存所有反编译出的 Java 文件
下载地址：https://github.com/java-decompiler/jd-gui/releases
动态分析
PC 平台可用与系统特性相关的工具 Dtrace 或 soot 对 jar 包中的文件进行运行时跟踪
Android 平台没有可直接使用的工具，要用迂回的办法，即先将 jar 包集成到编写的 APK 中，再对要分析的 jar 包中的类与方法进行插桩和运行时分析
在 Android 平台进行动态分析时，可参考 PC 上的方案，如 AspectJ 的面向切片编程技术。AspectJ 提供了对 jar 包中方法的侵入式 Hook 技术，可通过编写 AspectJ 脚本 Hook jar 包中的方法。Android 平台有 AspectJ 的移植版本，只要编写 Hook 实例即可，详情见之后的笔记
Android Studio 问世前：jar 包中通常只包含其所使用的代码，不包含代码所使用的资源数据；如果第三方 SDK 使用了大量的图片、声音、布局等资源，除了要将 jar 包引用到工程外，还要将 SDK 中的资源手动复制到工程中
Android Studio 问世后：AS 将 aar 文件作为全新的库文件格式。aar 除了可包含代码，还可包含任何在开发中用到的资源数据
启动 AS，新建工程（AS 不允许直接创建 aar 文件，要通过模块的形式在已存在的 APK 工程中添加 aar 文件），命名为“MyAar”，然后选择默认选项即可，如下图：
在 AS 主界面点击右键，如下图：
选择“Android Library”，输入名称“MyLib”，如下图：
在工程中包含 app 和 mylib 两个模块，不对其修改，直接编译 mylib 模块的 Release 版本。编译完成后会在当前工程目录的 mylib/build/outputs/aar 目录下生成 mylib-release.aar 文件
执行如下命令，查看文件格式：
file mylib/build/outputs/aar/mylib-release.aar
从刚刚输出来的内容可知 aar 文件也是 zip 包，执行如下命令，查看它的内容：
unzip -l mylib/build/outputs/aar/mylib-release.aar
它的目录结构与 APK 文件类似
AndroidManifest.xml：可用于定义 aar 包的名称、编译器版本等
classes.jar：包含 aar 库文件中所有代码生成后的 class 文件
res 目录：存放所有资源
aidl 目录（本文件不存在）：存放 AIDL 接口文件
assets 目录（本文件不存在）：存放 Asset 资源
jni 目录（本文件不存在）：存放编译好的不同版本的 so 库
libs 目录：存放 aar 包引用的第三方 jar 包
APK（Android Package）：Android 系统的软件安装包文件
APK 是 Android 软件的核心和 Android 软件开发的结果，要重点关注
APK 文件与其他系统中的软件包一样，也有自己的格式和组织结构。自 Android 诞生起，APK 文件的格式就没发生变化，始终使用 zip 作为其格式。在目录结构上，APK 文件也没发生变化，以 Crackme0201为例，解包查看其目录结构：
查看文件格式
file APK文件全路径
解包
unzip APK文件全路径
使用 tree 命令查看目录结构
tree
一个完整的 APK 文件包含如下内容：
AndroidManifest.xml：编译好的 AXML 二进制格式的文件
META-INF 目录：保存 APK 的签名信息
classes.dex：程序的可执行代码。如果开启了 MultiDex，则会有多个 DEX 文件
res 目录：程序中使用的资源信息。针对不同分辨率的设备，可使用不同的资源文件
resources.arsc：编译好的二进制格式的资源信息
assets 目录：若程序使用 Asset 系统来存放 Raw 资源，所有的资源都将存放在这个目录下
使用 AS 开发 Android 程序时，AS 会在系统后台调用编译器，自动生成 APK 文件
使用 aapt 打包程序资源，处理项目中的 AndroidManifest.xml 文件和 XML 布局文件，并生成 R.java 文件
使用 aidl 解析 AIDL 接口，定义并生成相应的 Java 文件
调用 Java 编译器生成 class 文件，使用 dx 将所有的 class 文件与 jar 包打包生成 DEX 文件，调用 apkbuilder 将上述资源与 class 文件合并成 APK 文件
对 APK 进行对齐处理和签名
打包生成 APK 的整个过程都基于 ADT 时代的编译工具集实现
Android Studio 时，编译流程的细节发生一些变化，Android 官方使用 gradle 作为 APK 的构建工具
整个打包过程被抽象成了将编译模块和依赖项打包成 DEX 文件、将 APK Packager 打包成 APK 和签名两个步骤，底层的操作细节被掩盖
Android 程序的四种安装方式
通过系统程序安装（开机时安装）
由开机时启动的 PackageManagerService 服务完成。这个服务在启动时会扫描系统程序目录 /system/app 并重新安装所有程序
通过 Android 市场安装 手机内置的应用商店如果放置在 /system/app 目录下，APK 的安装过程就可自动完成，通常不需要用户干预；否则会弹出软件安全界面，引导用户完成安装
从 Android 6.0 开始，软件安装完成后会弹出权限控制界面，允许用户对软件所使用的权限进行细粒度的管理
通过 adb 命令安装
使用 Android SDK 提供的调试桥命令 adb 来安装 APK
在命令行输入如下命令，即可完成安装：
adb install APK全路径
手机客户端自带安装（通过 SD 卡里的 APK 文件安装）
点击手机文件浏览器里的 APK 文件，直接调用 Android 系统的软件包 packageinstaller.apk，即可安装 APK
通过分析 packageinstaller.apk 的实现步骤了解 APK 安装过程
用户通过 Android 手机的文件管理程序定位到要安装的 APK 时，只要点击 APK，就会弹出软件安装界面（点击“安装”即可开始安装，点击“取消”则返回）。这个安装界面其实是 Android 系统程序 PackageInstaller 的 PackageInstallerActivity，当 Android 系统请求安装 APK 时，就会启动这个 Activity，并接收通过 Intent 传递来的 APK 文件信息
PackageInstaller 的源码位于 Android 系统源码的 packages/apps/PackageInstaller 目录下。当 PackageInstallerActivity 启动时，首先初始化一个 PackageManager 对象与一个 PackageParser.Package 对象，接着调用 PackageUtil 类的静态方法 getPackageInfo() 来解析程序包信息。如果解析出错，程序执行失败并返回；如果成功，程序就调用 setContentView() 方法设置 PackageInstallerActivity 的显示视图，然后调用 PackageUtil 类的静态方法 getAppSnippet() 与 initSnippetForNewApp() 来设置 PackageInstallerActivity 的控件，以显示程序的名称和图标，最后调用 initiateInstall() 方法进行其他初始化工作
PackageInstallerActivity 的 onCreate() 方法代码如下：
Protected void onCreate(Bundle icicle) {
super.onCreate(icicle);
// Get intent information
final Intent intent = getIntent();
// 获取传递来的 APK 文件信息
mPackageURI = intent.getData();
// 获取包管理器
mPm = getPackageManager();
// 解析 APK 文件
mPkgInfo = PackageUtil.getPackageInfo(mPackageURI);
// Check for parser errors
if (mPkgInfo == null) {
Log.w(TAG, "Parser error when parsing manifest. Discontinuing installation");
// 解析出错，弹出出错对话框
showDialogInner(DLG_PACKAGE_ERROR);
setPmResult(PackageManager.INSTALL_FAILD_INVALID_APK);
return;
}
// Set view
// 设置试图
setContentView(R.layout.install_start);
mInstallConfirm = findViewById(R.id.install_confirm_panel);
mInstallConfirm.setVisibility(View.INVISIBLE);
// 获取 APK 的程序名和图标
PackageUtil.AppSnippet as = PackageUtil.getAppSnippet(
this, mPkgInfo.applicationInfo, mPackageURI);
// 设置 APK 的程序名和图标
PackageUtil.initSnippetForNewApp(this, as, R.id.app_snippet);
// Deal with install source.
String callerPackage = getCallingPackage();
if (callerPackage != null && intent.getBooleanExtra(
Intent.EXTRA_NOT_UNKNOWN_SOURCE, false)) {
try {
// 获取程序信息
mSourceInfo = mPm.getApplicationInfo(callerPackage, 0);
if (mSourceInfo != null) {
// 系统程序
if ((mSourceInfo.flags & ApplicationInfo.FLAG_SYSTEM) != 0) {
// System apps don't need to be approved.
// 其他初始化工作
initiateInstall();
return;
}
SharedPreFerences prefs = getSharedPreferences(
PREFS_ALLOWED_SOURCE, Context.MODE_PRIVATE);
if (prefs.getBoolean(mSourceInfo.packageName, false)) {
// User has already allowed this one.
// 其他初始化工作
initiateInstall();
return;
}
// Ask user to enable setting first
// 弹出“新的应用来源”对话框
showDialogInner(DLG_ALLOW_SOURCE);
return;
}
}
catch (NameNotFoundException e) {
}
}
// Check unknown sources.
if (!isInstallingUnknownAppsAllowed()) {
// Ask user to enable setting first
// 弹出“启用未知来源”对话框
showDialogInner(GLG_UNKNOWN_APPS);
return;
}
// 其他初始化工作
initiateInstall();
}
在整个 onCreate() 方法中有两个重点函数：PackageUtil 类的 getPackageInfo()；initiateInstall()。getPackageInfo() 首先通过 packageURI 获取 APK 的路径，然后构造一个 PackageParser 对象，最后调用 PackageParser 对象的 parsePackage() 解析 APK 程序包。parsePackage() 代码较长，大致如下：
public Package parsePackage(File sourceFile, String destCodePath,
DisplayMetrics metrics, int flags) {
...
try {
assmgr = new AssetManager();
int cookie = assmgr.addAssetPath(mArchiveSourcePath);
...
}
catch (Exception e) {
Slog.w(TAG, "Unable to read AndroidManifest.xml of" +
mArchiveSourcePath, e);
}
...
try {
// XXXX todo: need to figure out correct configuration.
pkg = parsePackage(res, parser, flags, errorText);
}
catch (Exception e) {
...
}
...
return pkg;
}
parsePackage() 调用了另一个版本的 parsePackage()，代码如下：
private Package parsePackage(Resources res, XmlResourceParser parser,
int flags, String[] outError) throws XmlPullParserException, IOException {
...
String pkgName = parsePackageName(parser, attrs, flags, outError);
...
final Package pkg = new Package(pkgName);
...
while ((type = parser.next()) != XmlPullParser.END_DOCUMENT &&
(type != XmlPullParser.END_TAG || parser.getDepth() > outerDepth)) {
if (type == XmlPullParser.END_TAG ||
type == XmlPullParser.TEXT) {
continue;
}
String tagName = parser.getName();
if (tagName.equals("application)) {
...
foundApp = true;
if (!parseApplication(pkg, res, parser, attrs, flags, outError)) {
return null;
}
}
else if (tagName.equals("permission-group")) {
...
}
...
else if (tagName.equals("eat-comment")) {
...
}
else if (RIGID_PARSER) {
...
}
else {
Slog.w(TAG, "Unknown element under : " +
parser.getName() + " at " + mArchiveSourcePath +
" " + parser.getPositionDescription());
XmlUtils.skipCurrentTag(parser);
continue;
}
}
...
return pkg;
}
首先调用 parsePackageName() 从 AndroidManifest.xml 中获取程序包名，接着构建了一个 Package 对象，然后逐一处理 AndroidManifest.xml 中的标签。在处理 application 标签时使用了 parseApplication()，该方法负责解析 activity、receiver、service、provider，并将它们添加到传递进来的 Package 对象的 ArrayList 中
在 onCreate() 中，getPackageInfo() 返回后调用了 initiateInstall()、initiateInstall() 负责检测该程序是否已安装。若已安装，就调用 startInstallConfirm() 显示安装界面；若没安装，则调用 showDialogInner(DLG_REPLACE_APP) 弹出替换程序对话框
startInstallConfirm() 设置了安装与取消按钮的监视器。最后是 onClick() 的按钮点击响应，安装按钮使用 startActivity() 启动一个 Activity 类 InstallAppProgress，该类在初始化 onCreate() 时调用 initView()，后者最终调用 PackageManager 类的installPackage() 来安装 APK
installPackage() 是 PackageManager 类的一个虚函数，PackageManagerService.java 实现了它。installPackage() 调用了 installPackageWithVerification()，该方法先验证调用者是否具有安装程序的权限，然后通过消息处理的方式调用 processPendingInstall() 进行安装。processPendingInstall() 调用了 installPackageLI()。installPackageLI() 经过一系列验证，最终调用 replacePackageLI() 或 installNewPackageLI() 来替换或安装程序。上述过程的代码如下：
private void installPackageLi(InstallArgs args,
boolean newInstall, PackageInstalledInfo res) {
int pFlags = args.flags;
String installerPackageName = args.installerPackageName;
File tmpPackageFile = new File(args.getCodePath());
...
// Set application objects path explicitly after the rename
setApplicationInfoPaths(pkg, args.getCodePath(),
args.getResourcePath());
pkg.applicationInfo.nativeLibraryDir =
args.getNativeLibraryPath();
if (replace) {
// 替换已安装的程序
replacePackageLI(pkg, parseFlags, scanMode,
installerPackageName, res);
}
else {
// 安装新程序
installNewPackageLI(pkg, parseFlags, scanMode,
installerPackageName, res);
}
}
尽管安装和替换操作的代码都较长，但它们最终都会调用 scanPackageLI()
scanPackageLI() 会实例化一个 PackageParser 对象，然后调用其 parsePackage() 来解析 APK 程序包。在代码的最后调用了 scanPackageLI() 的另一版本，此版本的 scanPackageLI() 将完成 APK 的依赖库检测、签名验证、sharedUser 的签名检查、Native 库目录文件的更新、组件名称的检查等工作，并调用 mInstaller 的 install() 来安装程序。mInstaller 为 Installer 类的一个实例，Installer 类的源码位于 Android 源码文件 frameworks/base/services/java/com/android/server/pm/Installer.java 中。install() 在构造字符串“install name uid gid”后，调用 transaction()，通过 socket 向 /system/bin/installd 程序发送 install 指令。installd 的源码位于 frameworks/base/cmds/installd 目录下，这个程序在开机后常驻内存，可通过在 adb 的 Shell 环境下运行 ps | grep /system/bin/installd 命令查看进程信息。installd 处理 install 指令的函数为 installd.c 文件中的 do_install()，do_install() 调用了 install()，后者在 commands.c 文件中有实现代码，大致如下：
int install(const char* pkgname, uid_t uid, gid_t gid) {
...
// 创建包路径
if (create_pkg_path(pkgdir, pkgname, PKG_DIR_POSIFIX, 0)) {
ALOGE("cannot create package path\n");
return -1;
}
// 创建库路径
if (create_pkg_path(libdir, pkgname, PKG_LIB_POSIFIX, 0)) {
ALOGE("cannot create package lib path\n");
return -1;
}
// 创建包目录
if (mkdir(pkgdir, 0751) < 0) {
ALOGE("cannot create dir '%s': %s\n",
pkgdir, strerror(errno));
return -errno;
}
// 设置包目录权限
if (chmod(pkgdir, 0751) < 0) {
ALOGE("cannot chmod dir '%s': %s\n",
pkgdir, strerror(errno));
unlink(pkgdir);
return -errno;
}
// 创建库目录
if (mkdir(libdir, 0755) < 0) {
ALOGE("cannot create dir '%s': %s\n",
libdir, strerror(errno));
unlink(pkgdir);
return -errno;
}
// 设置库目录权限
if (chmod(libdir, 0755) < 0) {
ALOGE("cannot chmod dir '%s': %s\n",
libdir, strerror(errno));
unlink(libdir);
unlink(pkgdir);
return -errno;
}
// 设置库目录的所有者
if (chown(libdir, AID_SYSTEM, AID_SYSTEM) < 0) {
ALOGE("cannot chown dir '%s': %s\n",
libdir, strerror(errno));
unlink(libdir);
unlink(pkgdir);
return -errno;
}
// 设置包目录的所有者
if (chown(pkgdir, uid, gid) < 0) {
ALOGE("cannot chown dir '%s': %s\n",
pkgdir, strerror(errno));
unlink(libdir);
unlink(pkgdir);
return -errno;
}
...
return 0;
}
install() 执行完毕，会通过 socket 回传结果，最终由PackageInstaller 根据返回结果进行相应的处理，此时一个 APK 就安装完成了
用于解析和打印编译的 Android 清单文件的库
java -jar AXMLPrinter.java xxx.xml >demo.xml
将xxx.xml解析之后输出到demo.xml中即可
地址：https://github.com/rednaga/axmlprinter
aapt即 Android Asset Packaging Tool，该工具在SDK/tools目录下。
只有那些类型为res/animator、res/anim、res/color、res/drawable（非Bitmap文件，即非.png、.9.png、.jpg、.gif文件）、res/layout、res/menu、res/values和res/xml的资源文件均会从文本格式的XML文件编译成二进制格式的XML文件
XML资源文件之所要从文本格式编译成二进制格式，原因如下：
二进制格式的XML文件占用空间更小。这是由于所有XML元素的标签、属性名称、属性值和内容所涉及到的字符串都会被统一收集到一个字符串资源池中去，并且会去重。有了这个字符串资源池，原来使用字符串的地方就会被替换成一个索引到字符串资源池的整数值，从而可以减少文件的大小
二进制格式的XML文件解析速度更快。这是由于二进制格式的XML元素里面不再包含有字符串值，因此就避免了进行字符串解析，从而提高速度。
将XML资源文件从文本格式编译成二进制格式解决了空间占用以及解析效率的问题，但是对于Android资源管理框架来说，这只是完成了其中的一部分工作。Android资源管理框架的另外一个重要任务就是要根据资源ID来快速找到对应的资源。
命令：
aapt l -a apk名称 > demo.txt
详情了解：
https://www.codenong.com/jsf0f4856866e0/
https://juejin.cn/post/6844903747169026061
参考链接：
https://blog.csdn.net/zlmm741/article/details/104640245 https://juejin.cn/post/6844903747169026061 https://blog.csdn.net/zlmm741/article/details/104577290
你以为你有很多路可以选择，其实你只有一条路可以走
