Android团队项目升级Androidx环境记录

303 阅读4分钟

官方文档关于androidx升级的描述: developer.android.google.cn/jetpack/and…

升级按照如下步骤进行:

1.AndroidX需要的开发环境准备:

gradle:gradle-4.6+

AndroidStudio 3.2.0+

gradle插件:3.2.0 +

compileSdkVersion 28

2.从Android studio自带的升级AndroidX功能入手:Refactor > Migrate to AndroidX(注意Android studio版本)。

开始之后会提示是否备份项目为压缩文件,我们使用git进行版本管理,所以跳过,节省时间。

这个过程持续了近60分钟...,确保运行过程中内存充足,防止失败后重来。

3.第2步进行完成之后,工具已经处理了大部分的内容,如下:

a.在gradle.properties开启配置

android.useAndroidX=true
android.enableJetifier=true

“android.useAndroidX=true” 表明整个项目的开发环境都基于 AndroidX。

“android.enableJetifier=true”这个配置会在构建 Android 项目时,将依赖库中的旧支持库自动迁移为 AndroidX(通过修改字节码的形式实现类的替换,同时处理依赖库中的资源文件)。

这个配置理论上已经将所有依赖库内部调整为了AndroidX环境,所以不需要再更新依赖库版本。

如下:注册库本身使用的是Android support库,重新编译后已经被修改为Androidx了。

企业微信截图_17273516235967.png转存失败,建议直接上传图片文件

b.将所有对support包的依赖切换为AndroidX

依赖google仓库,并将build文件中support类型的依赖改为Androidx。

"support-v4"               : 'androidx.legacy:legacy-support-v4:1.0.0',
"recyclerview-v7"          : 'androidx.recyclerview:recyclerview:1.0.0',

c.将源码中所有support包下类的引用修改为AndroidX

将代码中对support的依赖改为androidx。

企业微信截图_17273519429214.png转存失败,建议直接上传图片文件

d.FileProvider配置修改为androidx类型

注意:android:name=“android.support.FILE_PROVIDER_PATHS” ,这个值不用变,这个字符串是在类FileProvider里面定义的。

<provider
    android:name="androidx.core.content.FileProvider"
    android:authorities="${applicationId}.fileprovider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_paths" />
</provider>

4.接下来运行项目,解决错误,直到编译通过。

接口变动或者类名变动都可能存在,所以要不停的编译,修改,直到项目能启动。

(landstar验证仅仅需要修改两到三项的代码即可编译成功)

编译通过之后提交一次代码。本次提交涉及到大量修改,所以“代码分析阶段”要消耗大概1个小时时间。所以提前提交一次,确保后边的修改都能快速提交(通过git命令行提交代码,可以绕过代码检查阶段,能节省大量时间)。

5.所有被依赖的三方库升级Androidx版本(非必要)

经过上边的步骤处理后,已经基本升级成功了,包括最繁琐的三方库升级AndroidX也完成了(android.enableJetifier=true实现)。

这里有一个需要考虑的问题,是否有必要手动将所有依赖项升级到Androidx版本?

1.手动升级所有依赖是极其繁琐的工程,会耗费大量的人力(100多个依赖都要进行验证)。

2.三方库都升级,意味着所有依赖都要更新版本,对项目的稳定性造成较大的风险。

3.官方提供的android.enableJetifier=true这种方式,是对项目代码变动成本最小的方式,因为他只是修改了Android support相关的内容,对三方库的影像最小。

4.所以从这个角度看,第三种方式实现是比较合理。

6.查漏补缺

a.类的引用(包含android.support.前缀的类)

搜索android.support.

将搜索到的需要修改的手动调整过来。

b.布局文件中通过全路径引用的类(包含android.support.前缀的类)

搜索<android.support.

将搜索到的需要修改的手动调整过来。

7.混淆配置

混淆中针对support类型的混淆需要修改为Androidx。

8.如何确认升级已成功?

构建release包,反编译,然后对反编译后的代码通过工具搜索“android.support.”关键字,对依然存在的类进行分析,即使完全是Androidx环境,也存在一些android.support.开头的类,这时候需要对照官方提供的映射表来确认是否需要修改。

developer.android.google.cn/jetpack/and…

将apk改为zip后解压,得到所有dex文件,然后将dex转为jar,一个一个的进行搜查。

9.测试

大量测试,以保证项目稳定性。

  1. 功能测试-确保升级后没有出现功能缺失或异常行为。
  2. 兼容性测试-在不同的 Android 版本和设备上进行兼容性测试,确保升级后的项目在各种环境下都能稳定运行。