技术小黑屋
·
Android 升级 targetSDK 35 解决 namespace 问题
内容提要
升级 Android targetSDK 至 35 和使用 Gradle 8.0+ 后，需在 build.gradle 中显式声明 namespace，因 AndroidManifest.xml 中的 package 属性已不再支持。解决方案包括自动设置 namespace、启用 buildConfig 特性及迁移配置，以确保第三方库符合新要求。
关键要点
-
升级 Android targetSDK 至 35 和使用 Gradle 8.0+ 后，需在 build.gradle 中显式声明 namespace。
-
AndroidManifest.xml 中的 package 属性已不再支持，导致构建失败。
-
解决方案包括自动设置 namespace、启用 buildConfig 特性及迁移配置。
-
自动设置 namespace 使用 project.group 替代点号为下划线。
-
在构建前自动执行修复，确保所有第三方库符合 Gradle 8.0+ 的要求。
-
适用场景包括 React Native 和 Flutter 项目升级、使用 Detox 测试框架的项目等。
-
此方案会自动修改第三方库的 build.gradle 和 AndroidManifest.xml 文件。
-
建议在 CI/CD 中首次构建后检查修改是否正确。
-
简化方案仅在内存中设置 namespace，不会修改任何文件。
延伸解读
命名空间的重要性
在 Android targetSDK 升级至 35 后，命名空间的显式声明变得至关重要。由于 AndroidManifest.xml 中的 package 属性不再被支持，开发者必须在 build.gradle 中定义 namespace，以避免构建失败。这一变化要求开发者对项目结构有更深入的理解，确保所有依赖库都符合新标准。
自动化修复的优势
文章中提到的自动化修复方案可以显著减少手动修改 build.gradle 和 AndroidManifest.xml 的工作量。通过在构建前自动执行修复，开发者可以确保所有第三方库都符合 Gradle 8.0+ 的要求，从而提高开发效率，降低出错风险。
CI/CD 中的检查建议
在 CI/CD 流程中，首次构建后检查自动修改的正确性是非常重要的。这可以帮助开发者及时发现潜在问题，确保项目在升级后能够顺利构建和运行。建议在构建日志中关注命名空间的设置和 package 属性的移除情况。
延伸问答
为什么在升级 Android targetSDK 至 35 时会遇到 namespace 配置问题？
因为 Android Gradle Plugin 8.0+ 不再支持在 AndroidManifest.xml 中通过 package 属性设置 namespace，必须在 build.gradle 中显式声明。
如何在 build.gradle 中显式声明 namespace？
在项目根目录的 android/build.gradle 文件中添加代码，自动设置 namespace，启用 buildConfig 特性，并迁移配置。
适用哪些项目场景需要进行此升级？
适用场景包括 React Native 和 Flutter 项目升级、使用 Detox 测试框架的项目等。
此方案对第三方库的影响是什么？
此方案会自动修改第三方库的 build.gradle 和 AndroidManifest.xml 文件，但仅在 node_modules 中生效，不影响源码仓库。
如何验证修改是否正确？
建议在 CI/CD 中首次构建后检查修改是否正确，可以通过执行 'cd android && ./gradlew clean && ./gradlew assembleDebug' 来验证。
简化方案与完整方案有什么区别？
简化方案仅在内存中设置 namespace，不会修改任何文件，可能无法解决所有第三方库的问题，而完整方案会自动修改相关文件。
