模具设计三大软件,如何优化标题关键词,templates怎么读,建设网站公司兴田德润官方地址Android系统的APK应用程序可以有以下几种编译方式
借助系统编译#xff1a;利用Android.mk 文件将众多小项目组织起来
借助IDE编译#xff1a;AndroidStudio
命令行编译 #xff1a; 比如利用gradle脚本编译APK应用。
一、 通过命令行编译和打包APK
编译命令(Window系…Android系统的APK应用程序可以有以下几种编译方式
借助系统编译利用Android.mk 文件将众多小项目组织起来
借助IDE编译AndroidStudio
命令行编译 比如利用gradle脚本编译APK应用。
一、 通过命令行编译和打包APK
编译命令(Window系统)
./gradlew build 检查依赖并且编译打包
./gradlew assembleDebug/assembleRelease 编译并打出Debug包 /Release包
./gradlew installDebug 编译出Debug包并且安装
./gradlew installRelease 编译出Release包并且安装
./gradlew assembleDebug/assembleRelease --info 编译包并且打印日志
./gradlew assembleDebug/assembleRelease --scan 编译并且输出更详细的报告
./gradlew clean 清除构建目录下的文件
./gradlew unsinstall packageName 卸载安装
./gradlew uninstallDebug / uninstallRelease 卸载安装包
// task相关
./gradlew --tasks 查看主要Task
./gradlew tasks --all 查看所有Task
./gradlew taskName or ./gradlew :moduleName:taskName 执行Task
// 查看依赖
./gradlew dependencies 查看项目根目录下的依赖
./gradlew :app:dependencies 查看app模块下的依赖
./gradlew :app:dependencies dependencies.txt 查看依赖输出到文件
//性能相关
./gradlew assembleDebug --offline 离线编译
./gradlew assembleDebug --build-cache 可开启缓存
./gradlew assembleDebug --no-build-cache 不开启
./gradlew assembleDebug --configuration-cache 配置缓存开启
./gradlew assembleDebug --no-configuration-cache 不开启
./gradlew assembleDebug --parallel 并行构建开启
./gradlew assembleDebug --no-parallel 不开启 二、 APK编译过程详情 以apk后缀的文件是Android应用系统的标准格式其实是一个压缩包用压缩工具截出来可以看到一个apk应用程序至少包含一下几部分内容
|-- AndroidManifest.xml
|-- cleasses.dex
|-- resources.arsc
|-- res
| |-- drawable
| | -- *.png
| |-- layout
| -- *.xml
|
|-- META-INF
| |-- CERT.RSA
| |-- CERT.SF]
| |-- MANIFEST.MF
| |
|
APK编译过程图解 可以清楚看到整个编译过程涉及到了许多工具
1. 首先是.aidl文件要经过aidl工具转换成编译器能处理的Java接口文件。
2. 同时资源文件将aapt处理为最终的resources.arsc并且生产R.java。
3. Java编译器统一将Java源码R.java等文件统一变异成.class 文件。
4. dex工具将.class工具转换成Android系统所能识别的格式dex。
5. 接下里dex、资源等通过apkbuilder生成初始的APK 。
6. apk签名。 签名工具有很多。
7. 签名后apk通过zipalign进行优化。
三、 应用程序签名源码简析
接下里分析一下源码来了解META-INF文件的用途以及签名校验大致流程。 应用程序安装时候首先是PackageManger会对其进行初始化。这包含对签名和文件哈希值的检查。
1.PackageParser 负责解析应用程序包并完成安全校验 private void installPackageTracedLI(InstallArgs args, PackageInstalledInfo res) {.... PackageParser pp new PackageParser();...pkg pp.parsePackage(tmpPackageFile, parseFlags);.... try {// either use what weve been given or parse directly from the APKif (args.certificates ! null) {try {PackageParser.populateCertificates(pkg, args.certificates);} catch (PackageParserException e) {// there was something wrong with the certificates we were given;// try to pull them from the APKPackageParser.collectCertificates(pkg, parseFlags);}} else {PackageParser.collectCertificates(pkg, parseFlags);}} catch (PackageParserException e) {res.setError(Failed collect during installPackageLI, e);return;}
}
2. PackageParser通过collectCertificates()来检验程序包中所有文件是否都符合要求然后才能返回PackageManager继续执行安装过程。 这个函数分为以下关键部分 解析package包得到所以文件 对这些文件逐一检验。 安全检查关键在于loadCertificates private static Certificate[][] loadCertificates(StrictJarFile jarFile, ZipEntry entry)
633 throws PackageParserException {
634 InputStream is null;
635 try {
636 // We must read the stream for the JarEntry to retrieve
637 // its certificates.
638 is jarFile.getInputStream(entry);
639 readFullyIgnoringContents(is);
640 return jarFile.getCertificateChains(entry);
641 } catch (IOException | RuntimeException e) {
642 throw new PackageParserException(INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION,
643 Failed reading entry.getName() in jarFile, e);
644 } finally {
645 IoUtils.closeQuietly(is);
646 }
647 }
648
整个检验过程主要涉及以下几点
CERT.RSA
这是应用程序开发者提供的证书包含开发者的公钥和一些列身份信息。因为是自签名的就不需要CA认证。
CERT.SF
后缀名.SF 应该是Signature File的缩写所以就是我们所说的签名文件。 它是对某个文件的HASH值进行私钥加密产生的。 它是对真个MANIFEST.MF 进行加密---它包好了应用中所有文件的Hash值。
MANIFEST.MF /frameworks/base/core/java/android/util/jar/StrictJarVerifier.java void verify() {
141 byte[] d digest.digest();
142 if (!MessageDigest.isEqual(d, Base64.decode(hash))) {
143 throw invalidDigest(JarFile.MANIFEST_NAME, name, name);
144 }
145 verifiedEntries.put(name, certChains);
146 }
文件 SHA-1是经过了Base64编码的所以这里要解码在对比。
这样就确保了Android的应用程序没有被恶意篡改有效的保护了开发者的权益。
V2的校验过程(略)
四、应用签名
我们可以利用sdk中的build-tools里面的apksigner工具来验证一下apk用了那种方式签名。 V2签名的信息存储在Android应用程序的APK文件中的签名块Signature Block中。签名块是APK文件的一部分用于存储应用程序的数字签名信息。
在APK文件的二进制结构中签名块位于文件的末尾紧跟在ZIP目录结构之后。签名块使用特定的格式存储签名信息包括应用程序的证书和签名本身。
要查看APK文件中的签名信息你可以使用Android SDK提供的工具和命令行选项。一个常用的工具是apksigner它可以用于验证应用程序的签名并提供签名块的详细信息。
以下是使用apksigner命令查看APK文件签名信息的示例
apksigner verify --print-certs path/to/your/app.apk
这些签名方案用于验证Android应用程序的完整性和真实性并确保应用程序在安装和运行时没有被篡改。
V1签名JAR签名V1签名是早期版本的Android应用程序签名方案。它使用基于JARJava Archive的签名方式将整个APK文件视为JAR文件并使用基于RSA的数字签名算法对其进行签名。V1签名方案在Android 1.0至7.0版本中使用。
V2签名APK签名V2签名是Android引入的第二个签名方案用于增强应用程序的安全性和完整性保护。V2签名将APK文件分为多个部分并对每个部分进行签名以提供更好的验证和错误检测。V2签名方案使用基于RSA的数字签名算法并在APK文件末尾添加签名块。V2签名方案从Android 7.0开始引入并成为默认的签名方案。
V3签名APK签名V3签名是在V2签名基础上进行改进的签名方案。它引入了APK签名方案V2的补充并使用ECDSA椭圆曲线数字签名算法来生成签名。V3签名进一步提高了应用程序验证的安全性并提供了更好的完整性保护。V3签名方案从Android 9.0开始引入。
V4签名APK签名V4签名是Android在Android 11中引入的新签名方案。它是对V2签名的扩展旨在提供更快的应用程序安装速度和更小的APK文件大小。V4签名使用了更高效的签名算法和压缩技术以减少签名数据的大小。V4签名方案需要使用Android 11及更高版本的构建工具和设备支持。
