从 2018 年 3 月初我们发布 以来，很多开发者都对当前常见应用在 Android P 上做了一些，我们在这里总结了一些常见的问题，以及它们发生的原因和的修改措施。测你前世死因 对于即将推出的 Android 新版本的预览版，这些值可能是字母数字 (如 “PPR” 或 “P”)，因此在尝试将 “P” 解析为整数时会导致崩溃。 在中国的 Android 生态中，应用经常依赖的第三方 SDK (特别是加固和热修复框架) 会和系统底层紧密集成 (如使用非公开的接口)，而导致应用在 Android 版本升级时无法正常运行。我们也开始与一些常见的 SDK 提供商合作 (并计划覆盖更多)，在 Android 新的预览版本中尽早解决兼容性问题。 如果您使用的第三方 SDK 尚不支持 Android 新版本，请报告给其提供商，帮助推动它解决兼容性问题。 非 SDK 接口指的是 Android 系统内部使用、并未提供在 SDK 中的接口，开发者可能通过 Java 反射、JNI 等技术来调用这些接口。但是，这么做是很的：非 SDK 接口没有任何公开文档，必须查看源代码才能理解其行为逻辑。 非 SDK 接口的函数签名 (包括参数列表和返回值)、行为逻辑都有可能在下个 Android 版本中被大幅修改，甚至 API 本身也可能被删除。这会导致使用非 SDK 接口的应用在新的 Android 版本中无法运行，或运行时产生不符合预期的行为，开发者必须投入相当的研发资源保持其在未来每个 Android 新版本中的适配。 直接使用底层的非 SDK 接口有可能会绕过一些 Android 对用户的安全性和隐私性方面的，不但影响用户体验、妨害用户隐私，也很可能会被 Google Play Protect 判定为恶意软件而提示用户卸载应用。 只使用 Android SDK 中的公开接口进行应用开发。公开 SDK 接口有详细的技术文档和支持渠道，未来的 Android 新版本也会公开 SDK 接口的兼容性 (即使有改动，也会在文档中详细阐明)。 请尽早在 Android P 预览版中测试您的应用，您可以运行并操作应用，然后在 adb logcat 中查找类似下方的内容，其中包含了应用调用的非 SDK 接口名，所属黑/灰名单和调用的方式: 如果您有合理的理由，必须使用某个非 SDK 接口，请在文章下方留言给我们，我们非常期待聆听和与您进行讨论，并会在充分评估必要性和可行性后，提供可能的方案来满足合理的功能需求。 从一开始，dex2oat 就被设计为系统内部使用的编译部署工具，Android 从来都未支持过开发者直接调用 dex2oat 的场景。我们会持续而不定期地对这个工具进行优化，而很多时候其行为变更 (如: 生成的文件及其格式) 都是与之前不兼容的。在大多数情况下，标准的类加载器 (BaseDexClassLoader / DexClassLoader / PathClassLoader) 无法找到或使用由直接调用 dex2oat 生成的文件。 Android Studio 生成的 dex 文件虽然有公开的布局格式，但具体内容还是会在运行时被系统在后台进行编译优化。如果您在 dex 文件中写入自定义的内容，很可能这些自定义的写入操作与系统优化发生冲突，以致自定义的内容被擦除或覆盖，甚至导致优化后的 dex 在执行时直接崩溃。 Android Studio 生成的 so 文件包含一些元数据 (如 ELF headers 和 section headers)，以备动态链接器进行完整性检查。 so 文件并不会带来安全性的提升 (很多工具可以重新生成元数据)，反而可能导致应用无法在未来的 Android 版本中启动 (由于动态链接器可能执行更严格的检查)。更多关于 so 文件的要求，您可在号平台发送信息 “so文件” 获取相关链接。 Android O 开始支持特长屏幕，而且已经有很多厂商开始发布特长屏幕的手机。应用对屏幕的显示比例做出错误的假设，而未能支持 16:9 以上的纵横比，进而影响用户体验。 Android O 开始支持特长屏幕，而且已经有很多厂商开始发布特长屏幕的手机。应用对未能支持 16:9 以上的纵横比会在特长屏幕的设备上启用兼容模式，把应用边缘的显示空间以黑色填充。 如果您在 Android P 的兼容性工作中有什么经验和体会，欢迎在文章下方留言与我们分享。谢谢！ |