Android Studio 之签名

通过签名可以确保数据来源的可靠性和数据的不可篡改性

对 Apk 进行签名，也就是在 Apk 中写入一个指纹，写入指纹后，Apk 中有任何修改，都会导致这个指纹无效，Android 系统在安装 Apk 进行签名校验时就会不通过，进而无法安装该 Apk

如上图：

通常的签名验签过程中，接收方收到消息后，会先向 CA 机构验证证书的合法性，再进行签名校验。但 Apk 的证书通常由开发者自己制作，没有向 CA 机构申请，Android 系统在安装 Apk 时也并没有校验证书本身的合法性，只是从证书中提取公钥和加密算法，因此，如果对第三方 Apk 重新签名，也能安装到没有安装过这个 Apk 的系统中

keystore 文件包含私钥、公钥和数字证书，分为很多种，Android 使用的是 Java 标准 keystore 格式 JKS(Java Key Storage)

Android App Bundle：用于通过 Google Play 发布的应用，需要升级到AS 3.2 以上版本才支持App Bundle 格式；

APK：用于创建可部署到设备上的签名 APK

点击 Finish 就会生成签名文件与签名后的 Apk

当我们需要升级 Apk 版本的时候，需要再次对 Apk 文件进行签名，可以通过配置 build.gradle 让其自动生成签名后的 Apk

如果你的项目是开源的，需要把你的签名信息写在 local.properties 中，然后在 .gitignore 配置文件中加入 local.properties ，这样 local.properties 就不会提交到开源项目中，签名信息也就不会被人获取

local.properties：

app/build.gradle:

有时候我们的 apk 中某些功能尺则需要系统签名，例如静默安装。测试系统签名的 apk，需要 root 权槐谈限，而带 Google APIs 的模拟器不能 root，因铅困碰此要注意不能选择带 Google APIs 的模拟器

下面执行的 *** 作都是在 Linux 中，如果 apk 是 window 中生成的，需要拷贝到 linux *** 作，再将生成的系统签名过得 apk 再拷贝到 window，比较麻烦，可以考虑后面的自动系统签名，还是需要在 linux *** 作一次，不过之后就可以只在 window *** 作了

这两个文件在目录 aosp/build/target/product/security 下，如下图

在目录 aosp/prebuilts/sdk/tools/lib 下，如下图

将前面获取的 platform.pk8 、 platform.x509.pem 和 signapk.jar 文件放到需要签名的 apk 同一个目录，执行以下命令

如果出现上面的错误：Failed to load any of the given libraries: [conscrypt_openjdk_jni-linux-x86_64, conscrypt_openjdk_jni-linux-x86_64-fedora, conscrypt_openjdk_jni]

解决方法：

到目录 aosp/prebuilts/sdk/tools/linux/lib64 下，复制 libconscrypt_openjdk_jni.so 文件到需要签名 apk 的同一个目录，并将命令改为

自动进行系统签名的原理是：先生成一个 system.jks 文件，使用 keytool-importkeypair 对 system.jks 文件进行系统签名，再 build.gradle 和 local.properties 进行配置，直接使用带有系统签名的 system.jks 对 apk 进行签名，这样编译生成的apk文件就自带系统签名了

按照前面的方法，生成一个 system.jks 文件，此时是在 window 系统中 *** 作的

进入 keytool-importkeypair 目录，将 system.jks、platform.pk8、platform.x509.pem 文件拷贝进来，拷贝之后的目录结构为

使用 linux 中修改过的带有系统签名的 system.jks 文件将 window 中最开始生成的 system.jks 覆盖掉，再像前面的自动签名部分一样，修改 build.gradle 和 local.properties 的配置，之后生成的 apk 就是系统签名过的了

测试方法是，在 AndroidManifest.xml 中添加 android:sharedUserId="android.uid.system" 后安装到 非 Google APIs 的模拟器上 ， Google APIs 的模拟器不能 root，无法安装

会发现只有使用 system.jks 文件签名后才能安装，否则安装失败，会报以下的错误：

开放源码技术是指一种技术或软件，通过其源代码在大众中分布，使程序员能够改变应用程序或程序的行为。如果一个程序员可以访问特定软件的源代码，他可以修改、检查和更改该软件，通过升级它的新功能或修复一个破损的部分，以提高其效率。

开源技术的概念出现于1983年，当时麻省理工学院的一名程序员和研究员理查德·斯托曼提出技术应该是开源的。他希望程序员有更多的自由，因为他相信程序员可以创建更好的版本的软件，并带来革命性的技术变化，如果他们提供的源代码。这个想法导致了1998年开放源代码促进会的诞生(Adey，2021)。

这些年来，很多事情都发生了变化，开源软件领域出现了新的趋势，产生了新的想法，为程序员创造了更多的机会，这样他们就可以学习、适应和实施他们的教导，为开源软件的幸福做出贡献(Wallen，2022)。

让我们来看看开源技术领域即将发生的一些最大趋势，这些趋势将在未来几年改变这个行业。

对拥有开源技能的全栈开发人员和 IT 人员的需求将会激增。在软件系统的开发、建模和 *** 作中使用的栈的多样性将为程序员和开发人员提供大量的机会来增强他们的技能集。雹拿在云计算、 DevOps 工具、 Kubernetes、 Python、 PyTorch 等领域的经验将使程序员能够优化业务并增加收入。企业和企业，无论是大企业还是小企业，都希望在投资开源技术的力量和解决客户问题的积极影响时填补空白(Kamaruzzaman，2021)。

Kubernetes (作为云应用程序的开源容器编排平台)的采用将会增加。这将使兼容的开源容器格式得以广泛使用，正如 Open Container Initiative 中所描述的那样。尽管实现 Kubernetes 所需的学习曲线非常庞大，但是随着全球大量 IT 团队认识到这种技术所具有的真正潜力，一切进展顺利。Kubernetes 被认为是最重要的开源技术，它的采用将在2022年增加(Wallen，2022)。

Snap 和 Flatpak 都是为分发 Linux 应用程序而设计的系统。尽管随着时间的推移，这些系统一直受到嘲笑，但它们简化了应用程序的安装过程，并为桌面上的更多应用程序腾出了空间。由于 Snap 和 Flatpak，像 Slack、 Spotify 和 Skype 这样的应用程序可以毫无困难地安装。现在需要这两个系统，Linux 社区迟早会理解它们的重要性。在不久的将来，一个完全默认为 Snap 和 Flatpak 的发行版将在 App Store 上发布。这将是对新用户的一次款待(Kamaruzzaman，2021)。

随着开源技术在当今 IT 世界的普及，加强安全措施以防大肆纤止对这种技术的网络攻击的必要性也在增加。可以扫描开源软件漏洞的新工具将被引入，并将被频繁地用于减轻任何伤害。从事开源技术的 IT 公司和组织将投资于获取新版本的软件和补丁，以改善整体安全状况。

当黑客发现未经修补的开源漏洞，他们可以插入讨厌的病毒或软件时，他们就会入侵软件供应链。但现在这一切都要停止了。像 Linux 基金会这样的组织将加强他们的 游戏 ，防止黑客实现他们的恶意设计。诸如数字签名服务等高级开源工具的开发将在2022年及以后继续发展(Wallen，2022)。

这可以被认为是一个愿望，很容易在2022年见到曙光。一个全新的、来自各方面的开源社交网络是可能的，它可能会给 Facebook 带来困难。这种社交网络可以完全改变社交网络的执行方式，滚仿并将给予程序员和开发人员更多的自由，以改善普通大众的用户体验。

诸如人工智能(AI)、机器学习(ML)、深度学习(DL)和数据驱动技术等技术将会继续存在，并且它们的实现和执行将会迅速增加。人工智能可以对人类有很大的帮助，因为它可以一遍又一遍地执行枯燥、单调的任务，为开发人员和程序员节省大量时间。他们可以将注意力转移到手头更聪明的任务上。使用 GPT-3和其他 NLP 库，AI 能够自动完成这些任务。一些人工智能助手足够聪明，可以为开发人员生成源代码，比如 Tabine、 gitHub Copilot 和 Codota。它们仍然处于早期阶段，但随着时间的推移逐渐成熟(Wallen，2022)。

Steam Deck是一个便携式手持 游戏 设备，并在2022年，Linux 是确定，它可以 游戏 。Linux 不会取代 Windows 在桌面 游戏 领域的地位，但它将证明 Linux 也是一个可行的选择，当它来玩 游戏 通过蒸汽(Martinez-Torres &Diaz-Fernandez，2013)。

---