Build App(s)多次编译后的产物,其SHA256校验值不一致是怎么回事?

编译了一个用beta签名的.app文件发给运营用于上线,该文件能成功上传并且华为后台校验通过。

今天点出来个bug,修了,再次编译了用beta签名的.app文件用于上线,该文件上传后未通过华为后台校验,错误码993。多次编译上传都是993。

这个问题也容易解决,我编译了release签名的.app文件用于上线,该文件能成功上传并且华为后台校验通过。

现在我要确认:昨天发给运营的上传并校验通过的文件,是用beta签名的,还是用release签名的。

所以我想到了SHA256校验:我用昨天beta签名编译时commitID节点的代码,分别用beta签名和release签名编译.app文件,再加上昨天发给运营的用beta签名的.app文件,比较一下它们的SHA256的值应该就可以了。

但是,这3个文件的SHA256值都不一致。

期望有2个文件SHA256值是一致的,要么是昨天的文件和今天的beta签名的一致,要么是昨天的文件和今天的release签名的一致。

问题来了,我多次编译后发现:同一份代码、同一份签名文件,多次编译的产物.app文件,其SHA256校验码不一致,.hap文件的校验码也不一致。

如何解释?原理是什么?
本文参与了 【 HarmonyOS NEXT 技术问答冲榜,等你来战!】欢迎正在阅读的你也加入。

阅读 604
avatarAI BotBETA
### 解释和原理

这个问题通常是由于编译过程中包含了一些不可预测或随机化的元素,导致每次编译生成的二进制文件(如 `.app` 或 `.hap` 文件)在内容上有细微的差异,从而影响到 SHA256 校验值。以下是可能的原因:

1. **时间戳**:编译过程中可能会嵌入当前的时间戳信息到二进制文件中,这样每次编译的时间不同,生成的文件内容也会不同。

2. **编译器的优化和指令选择**:不同的编译器版本或设置可能会导致生成的机器码有所不同,即使源代码相同。编译器可能会根据当前的编译器状态、可用资源等因素做出不同的优化决策。

3. **链接器行为**:链接器在将多个目标文件(.o 文件)链接成最终的可执行文件时,可能会以不同的顺序或方式处理这些文件,导致生成的二进制文件有所不同。

4. **随机数或UUID**:在某些情况下,应用程序可能会在编译时生成或嵌入随机数或UUID,这些值每次编译时都会变化。

5. **环境差异**:编译环境(如操作系统、库版本等)的微小变化也可能导致生成的二进制文件有所不同。

6. **资源文件处理**:如果应用程序包含资源文件(如图片、音频等),这些文件在编译时可能会被处理(如压缩、优化等),处理结果可能会因编译环境或参数的不同而有所变化。

### 解决方案

- **确保编译环境一致**:尽量在相同的编译器版本、操作系统和硬件环境下进行编译,以减少环境差异对编译结果的影响。

- **使用固定的构建脚本**:通过脚本化构建过程,确保每次编译使用的参数和步骤都是一致的。

- **避免嵌入时间戳和随机数**:在可能的情况下,避免在编译过程中嵌入时间戳和随机数等变化的值。

- **使用版本控制系统**:利用版本控制系统(如 Git)来跟踪源代码和构建脚本的变化,确保每次编译都是基于相同的代码和脚本。

- **比较二进制文件的差异**:使用工具(如 `diff` 或 `xxd`)来比较不同编译生成的二进制文件的差异,以了解导致 SHA256 校验值不一致的具体原因。

由于上述原因,即使同一份代码和签名文件,多次编译生成的二进制文件的 SHA256 校验值也可能不一致。因此,在比较不同编译生成的文件时,需要考虑到这些潜在的差异。
1 个回答

p7b文件不变的情况下获取的finerprint值是一致的,在应用市场上架后,使用的p7b文件变化,会导致获取的finerprint不一致

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进