從一個線上問題 重新認識R8編譯器
背景
在過去的一段時間內，京東Android APP通過圖片壓縮、圖片轉下載、資源混淆編譯、插件化、插件后裝、混合開發等一系列手段對安裝包大小進行了優化，取得了不錯的瘦身收益。在完成這些常規瘦身手段優化后，為了進一步優化安裝包的大小，調研了谷歌官方新推出的 R8 編譯器，了解到R8編譯器在提升構建效率的同時，又能優化包體積大小，所以我們開始嘗試升級AGP版本來啟用R8編譯，升級的過程不是很順利，遇到了下面這些問題。
混淆工具介紹
對于Android應用，為了提高應用的安全性，常將代碼混淆作為手段之一。代碼混淆就是將源代碼轉換成功能上等價，但是難于閱讀和理解的形式，降低代碼的可讀性，即使被反編譯成功也很難得出代碼的真正含義，通過代碼混淆可以提升應用被反編譯破解的難度。另一方面代碼混淆后，由于類、方法或者字段的名稱被映射成簡短無意義的名稱，也能減少應用的包體積。
01ProGuard
在AGP3.4.0之前，Android打包流程中默認使用ProGuard作為優化工具，ProGuard對源代碼采用如下4個步驟進行優化，分別為壓縮（shrink）、優化（optimize）、混淆（obfuscate）和預校驗（preveirfy）。
- 壓縮（shrink）：移除未被使用的類、方法、字段等；
- 優化（optimize）：字節碼優化、方法內聯等操作；
- 混淆（obfuscate）：使用簡短無意義的名稱重命名類名、方法名、字段名等，增加反編譯難度；
- 預校驗（preverify）：對class進行預校驗。
上面四個階段是可以獨立運行的，默認都是開啟的，可以通過在混淆配置文件中設置-dontshrink、-dontoptimize、-dontobfuscate、-dontpreverify規則來關閉對應的階段。ProGuard對.class文件進行代碼壓縮優化與混淆后會交給D8編譯器進行脫糖，并將.class 文件轉換成.dex文件，執行流程如下：
圖1 ProGuard與D8的優化流程
02R8
AGP 3.3.0之后谷歌官方開始引入R8，是ProGuard的替代品，但是兼容ProGuard的keep規則。R8將代碼脫糖、壓縮、混淆、優化和dex處理(D8)等優化流程整合在一個步驟中完成，啟用R8編譯后，在實際的開發過程中工程的構建效率要優于ProGuard，其編譯流程如下。
圖2 R8 的優化流程
- 搖樹優化：從應用及其庫依賴項中檢測并安全地移除未使用的類、字段、方法和屬性；
- 資源壓縮：從應用中移除未使用的資源，包括應用的庫依賴項中未使用的資源；
- 混淆：縮短類和成員的名稱；
- 優化：優化字節碼、簡化代碼等操作，以進一步減小應用 DEX 文件的大小。例如，如果 R8檢測到從未采用過給定 if/else 語句的 else {} 分支，R8 便會移除 else {} 分支的代碼。
在Android正式發布Release包時，我們通常如下設置來開啟優化功能：
release {
// 開啟代碼收斂
minifyEnabled true
// 開啟資源壓縮
shrinkResources true
// 定義ProGuard混淆規則
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}踩坑經驗
01R8 混淆規則
1.1 問題現象
首先我們來看下在AGP 3.3.3構建工具打包混淆后生成的mapping.txt文件，觀察數據類混淆后的映射關系，其中OtherBean數據類在混淆配置文件中添加了排除混淆規則-keep class com.jd.obfuscate.bean.OtherBean{ *; }，而WatermelonBean數據類沒有添加keep規則，而且這兩個數據類擁有3個相同名稱的字段name、color、shape：
com.jd.obfuscate.bean.OtherBean -> com.jd.obfuscate.bean.OtherBean:
java.lang.String name -> name
java.lang.String color -> color
java.lang.String shape -> shape
java.lang.String otherPrice -> otherPrice
java.lang.String otherComment -> otherComment
java.lang.String otherProducer -> otherProducer
java.lang.String otherCategory -> otherCategory
int otherWeight -> otherWeight
int otherQuality -> otherQuality
int otherScore -> otherScore
com.jd.obfuscate.bean.WatermelonBean -> com.jd.obfuscate.bean.a:
java.lang.String name -> name
java.lang.String color -> color
java.lang.String shape -> shape
java.lang.String price -> aMR
java.lang.String comment -> aMS
java.lang.String producer -> aMT
java.lang.String cate -> aMU
int weightAttr -> aMV
int qualityAttr -> aMW
int scoreAttr -> aMX
仔細觀察這兩個數據類混淆后的類名和字段名，由于WatermelonBean數據類沒有添加keep規則，發現WatermelonBean數據類的類名和其余字段名都被混淆成無意義的名稱，而字段name、color、shape卻沒有被混淆。
接下來我們再來看下升級AGP 3.6.4后啟用R8編譯后，WatermelonBean數據類會被混淆成什么樣：
com.jd.obfuscate.bean.WatermelonBean -> b.b.a.a.a:
java.lang.String name -> a
java.lang.String color -> b
java.lang.String shape -> c
java.lang.String price -> d
java.lang.String comment -> e
java.lang.String producer -> f
java.lang.String cate -> g
int scoreAttr -> j
int weightAttr -> h
int qualityAttr -> i
在啟用R8編譯后，發現未添加keep規則的WatermelonBean數據類里的name、color、shape3個字段也都被混淆了。
在開發過程中與服務端交互時，使用Gson、FastJson等框架解析服務端數據時，會涉及到反序列化或反射相關，對應的對象數據類不能被混淆，應該添加相應的keep規則，否則無法將json數據解析成正確的對象。所以如果你的項目工程在升級AGP后，在應用上線前沒有檢查到所有的網絡解析數據類都添加了相應的keep規則，那么業務功能就會出現問題。
1.2 原因分析
是什么原因導致了上面的現象？
①當你升級AGP啟用R8編譯時，如果仔細查看打包日志，你會發現關于"-useuniqueclassmembernames"混淆規則的警告提醒：
AGPBI: {"kind":"warning","text":"Ignoring option: -useuniqueclassmembernames",
"sources":[{"file":"xxx/proguard-project.txt","tool":"R8"}②熟悉ProGuard混淆規則的同學，針對上面的混淆現象應該一眼就能看出是"-useuniqueclassmembernames"的混淆規則引起的，對該規則解釋是：為不同類中相同名稱的成員變量在混淆后生成全局唯一的混淆名。在沒有設置該規則時，不同類的方法或者字段都有可能被映射為a、b、c等無意義的名稱。
③將"-useuniqueclassmembernames"混淆規則移除后進行驗證，我們看下WatermelonBean數據類混淆后mapping文件：
com.jd.obfuscate.bean.WatermelonBean -> com.jd.obfuscate.bean.a:
java.lang.String name -> a
java.lang.String color -> b
java.lang.String shape -> c
java.lang.String price -> d
java.lang.String comment -> e
java.lang.String producer -> f
java.lang.String cate -> g
int weightAttr -> h
int qualityAttr -> i
int scoreAttr -> j
發現WatermelonBean數據類中的字段name、color、shape都被混淆成了字母，證實是該混淆規則會導致類名被混淆而它的部分字段名未被混淆的現象。
Proguard 對字段名是如何進行混淆的？
開發過自定義 Android Gradle 插件的開發者應該對 Gradle Transform 抽象類比較熟悉，Gradle Transform是Android 官方提供給開發者在項目構建階段class文件轉換為dex文件期間用來修改.class文件的一套標準API，通過這些API可以操作字節碼，實現通用的功能。
AGP源碼查看方式，在項目工程中添加依賴：
implementation 'com.android.tools.build:gradle:3.3.3'
定位源碼到com.android.build.gradle.internal.transforms.ProGuardTransform：
public void transform(final TransformInvocation invocation) {
final SettableFuture<TransformOutputProvider> resultFuture = SettableFuture.create();
Job job = new Job(this.getName(), new Task<Void>() {
public void run(Job<Void> job, JobContext<Void> context) throws IOException {
ProGuardTransform.this.doMinification(invocation.getInputs(),
invocation.getReferencedInputs(), invocation.getOutputProvider());
}
}, resultFuture);
SimpleWorkQueue.push(job);
job.awaitRethrowExceptions();
}創建ProGuard處理的異步任務添加到WorkQueue隊列中，執行doMinification() -> runProguard() -> (new ProGuard(this.configuration)).execute();
// 核心方法，根據混淆規則配置執行相應的操作
public void execute() throws IOException {
System.out.println(VERSION);
// 檢查GPL許可協議
GPL.check();
if (configuration.printConfiguration != null) {
// 打印配置文件
printConfiguration();
}
// 檢查混淆規則配置是否正確
new ConfigurationChecker(configuration).check();
if (configuration.programJars != null &&
configuration.programJars.hasOutput() &&
new UpToDateChecker(configuration).check()) {
return;
}
if (configuration.targetClassVersion != 0) {
configuration.backport = true;
}
// 讀取所有class文件到類池中，programClassPool和libraryClassPool
readInput();
if (configuration.shrink || configuration.optimize ||
configuration.obfuscate || configuration.preverify) {
// 清除類中所有的JSE預驗證信息
clearPreverification();
}
if (configuration.printSeeds != null || configuration.shrink ||
configuration.optimize || configuration.obfuscate ||
configuration.preverify || configuration.backport) {
// 檢索類的依賴關系
initialize();
}
if (configuration.printSeeds != null)
// 將keep住的類輸出到seeds.txt文件中
printSeeds();
}
if (configuration.shrink) {
// 執行壓縮優化
shrink();
}
// 根據設置的優化級別進行代碼指令優化：-optimizationpasses 5
if (configuration.optimize) {
for (int optimizationPass = 0;
optimizationPass < configuration.optimizationPasses;
optimizationPass++) {
if (!optimize(optimizationPass+1, configuration.optimizationPasses)) {
break;
}
// Shrink again, if we may.
if (configuration.shrink) {
// Don't print any usage this time around.
configuration.printUsage = null;
configuration.whyAreYouKeeping = null;
// 再次壓縮優化
shrink();
}
}
// 在方法內聯和類合并等優化之后，消除所有程序類的行號
linearizeLineNumbers();
}
if (configuration.obfuscate) {
// 執行混淆處理步驟
obfuscate();
}
if (configuration.preverify) {
// 預校驗
preverify();
}
......
}
上面就是ProGuard執行的基本流程，我們著重看下obfuscate()混淆方法:
execute()方法執行真正的混淆操作:
new Obfuscator(configuration).execute(programClassPool, libraryClassPool);
Obfuscator類是真正做混淆處理的類，包含類混淆ClassObfuscator，成員混淆MemberObfuscator。
在執行的方法中，發現2處關于"-useuniqueclassmembernames"規則的處理邏輯：
// If the class member names have to correspond globally,
// link all class members in all classes, otherwise
// link all non-private methods in all class hierarchies.
ClassVisitor memberInfoLinker =
configuration.useUniqueClassMemberNames ?
(ClassVisitor)new AllMemberVisitor(new MethodLinker()) :
(ClassVisitor)new BottomClassFilter(new MethodLinker());
programClassPool.classesAccept(memberInfoLinker);
// Create a visitor for marking the seeds.
NameMarker nameMarker = new NameMarker();
ClassPoolVisitor classPoolvisitor =
new KeepClassSpecificationVisitorFactory(false, false, true)
.createClassPoolVisitor(configuration.keep,
nameMarker,
nameMarker,
nameMarker,
null);
// Mark the seeds.
programClassPool.accept(classPoolvisitor);
// Come up with new names for all class members.
NameFactory nameFactory = new SimpleNameFactory();
// Maintain a map of names to avoid [descriptor - new name - old name].
Map descriptorMap = new HashMap();
// Do the class member names have to be globally unique?
if (configuration.useUniqueClassMemberNames) {
// Collect all member names in all classes.
programClassPool.classesAccept(
new AllMemberVisitor(
new MemberNameCollector(configuration.overloadAggressively, descriptorMap)));
// Assign new names to all members in all classes.
programClassPool.classesAccept(new AllMemberVisitor(
new MemberObfuscator(configuration.overloadAggressively, nameFactory, descriptorMap)));
} else { ...... }
混淆分為六個步驟：
第一步：如果設置了"-useuniqueclassmembernames"混淆規則，首選通過ClassVisitor)new AllMemberVisitor(new MethodLinker())創建MethodLinker訪問者對象，將所有類中的字段信息轉為鏈表連接起來，以字段名稱和字段類型作為key，查詢memberMap中是否已經存在該字段的visitorInfo信息，如果沒有查詢到就調用lastMember()方法嘗試獲取該字段在鏈表中的visitorInfo，并存入memberMap中；如果能查詢到，則將該字段信息作為visitorInfo加入到字段信息的鏈表中：
public void visitAnyMember(Clazz clazz, Member member) {
// 取得字段的名稱和描述符
String name = member.getName(clazz);
String descriptor = member.getDescriptor(clazz);
String key = name + ' ' + descriptor;
Member otherMember = (Member)memberMap.get(key);
if (otherMember == null) {
// Get the last method in the chain.
Member thisLastMember = lastMember(member);
// Store the new class method in the map.
memberMap.put(key, thisLastMember);
} else {
// Link both members.
link(member, otherMember);
}
}
public static Member lastMember(Member member) {
Member lastMember = member;
while (lastMember.getVisitorInfo() != null &&
lastMember.getVisitorInfo() instanceof Member) {
lastMember = (Member)lastMember.getVisitorInfo();
}
return lastMember;
}
private static void link(Member member1, Member member2) {
// Get the last methods in the both chains.
Member lastMember1 = lastMember(member1);
Member lastMember2 = lastMember(member2);
// Check if both link chains aren't already ending in the same element.
if (!lastMember1.equals(lastMember2)) {
// Merge the two chains, with the library members last.
if (lastMember2 instanceof LibraryMember) {
lastMember1.setVisitorInfo(lastMember2);
} else {
lastMember2.setVisitorInfo(lastMember1);
}
}
}第二步：將添加keep規則的類名、方法或字段名進行標記（NameMarker）而不被混淆。ProGuard源碼大量使用了訪問者模式，通過創建ClassVisitor的實現類nameMarker對象來訪問對象池，最終會執行NameMarker類中的方法：
public void visitProgramClass(ProgramClass programClass) {
// 標記keep規則中的類名
keepClassName(programClass);
// Make sure any outer class names are kept as well.
programClass.attributesAccept(this);
}
public void keepClassName(Clazz clazz) {
ClassObfuscator.setNewClassName(clazz, clazz.getName());
}
public void visitProgramField(ProgramClass programClass,
ProgramField programField) {
// 標記keep規則中的字段名
keepFieldName(programClass, programField);
}
private void keepFieldName(Clazz clazz, Field field) {
MemberObfuscator.setFixedNewMemberName(field, field.getName(clazz));
}
// 給字段標記固定的名稱
static void setFixedNewMemberName(Member member, String name) {
VisitorAccepter lastVisitorAccepter = MethodLinker.lastVisitorAccepter(member);
if (!(lastVisitorAccepter instanceof LibraryMember) &&
!(lastVisitorAccepter instanceof MyFixedName)) {
lastVisitorAccepter.setVisitorInfo(new MyFixedName(name));
} else {
lastVisitorAccepter.setVisitorInfo(name);
}
}
public void visitProgramMethod(ProgramClass programClass,
ProgramMethod programMethod) {
// 標記keep規則中的方法名
keepMethodName(programClass, programMethod);
}
private void keepMethodName(Clazz clazz, Method method) {
String name = method.getName(clazz);
if (!ClassUtil.isInitializer(name)) {
MemberObfuscator.setFixedNewMemberName(method, name);
}標記字段keep名稱做法比較簡單，只要通lastVisitorAccepter.setVisitorInfo(name)來設置。
第三步：收集所有類中的所有成員的映射關系（MemberNameCollector），先從字段鏈表中獲取上一步中標記的keep名稱(visitorInfo)，并將相同類型的方法或字段放入同一個Map<混淆后名稱,原始名稱>中：
public void visitAnyMember(Clazz clazz, Member member) {
String name = member.getName(clazz);
// Get the member's new name.
// 在鏈表中獲取該成員的visitorInfo
String newName = MemberObfuscator.newMemberName(member);
// keep的名稱
if (newName != null) {
// Get the member's descriptor.
String descriptor = member.getDescriptor(clazz);
if (!allowAggressiveOverloading) {
descriptor = descriptor.substring(0, descriptor.indexOf(')')+1);
}
// Put the [descriptor - new name] in the map,
// creating a new [new name - old name] map if necessary.
Map nameMap = MemberObfuscator.retrieveNameMap(descriptorMap, descriptor);
String otherName = (String)nameMap.get(newName);
if (otherName == null ||
MemberObfuscator.hasFixedNewMemberName(member) ||
name.compareTo(otherName) < 0) {
// 把相同描述符的方法或字段放入同一個
// Map<混淆后名稱,原始名稱>中
nameMap.put(newName, name);
}
}第四步：創建混淆名稱混淆，如果在keep名稱鏈表中找不到映射關系，就創建新的混淆名稱（MemberObfuscator）：
public void visitAnyMember(Clazz clazz, Member member) {
String name = member.getName(clazz);
// Get the member's descriptor.
String descriptor = member.getDescriptor(clazz);
// Get the name map, creating a new one if necessary.
Map nameMap = retrieveNameMap(descriptorMap, descriptor);
// Get the member's new name.
// 1.如果前面已經有keep的名稱，就不進行混淆，
// 如果沒有就分配新的混淆名稱
String newName = newMemberName(member);
// Assign a new one, if necessary.
if (newName == null) {
// Find an acceptable new name.
nameFactory.reset();
do {
// 2.生成新的名稱
newName = nameFactory.nextName();
}
while (nameMap.containsKey(newName));
// Remember not to use the new name again
// in this name space.
nameMap.put(newName, name);
// Assign the new name.
// 3. 為這個成員設置新的名稱
setNewMemberName(member, newName);
}
}
static void setNewMemberName(Member member, String name) {
MethodLinker.lastVisitorAccepter(member).setVisitorInfo(name);
}NameFactory接口類主要負責生成新的混淆名稱，如果沒有設置自定義 obfuscationDictionary 字典的話，NameFactory接口的實現類SimpleNameFactory類，主要通過newName方法生成新的混淆名稱：
private static final int CHARACTER_COUNT = 26;
private String newName(int index) {
// If we're allowed to generate mixed-case names,
// we can use twice as
// many characters.
int totalCharacterCount = generateMixedCaseNames ?
2 * CHARACTER_COUNT : CHARACTER_COUNT;
int baseIndex = index / totalCharacterCount;
int offset = index % totalCharacterCount;
char newChar = charAt(offset);
String newName = baseIndex == 0 ?
new String(new char[] { newChar }) :
(name(baseIndex-1) + newChar);
return newName;
}
private char charAt(int index) {
return (char)((index < CHARACTER_COUNT ? 'a' -0 :
'A' - CHARACTER_COUNT) + index);
CHARACTER_COUNT被定義為26，正好是26個字母的意思，nextName()方法里通過index計數器，每次產生新名稱都往上自加，所以ProGuard的混淆名字是從a開始到z。
第五步：應用混淆名稱，創建ClassRenamer訪問者對象，通過ConstantPoolEditor對象向常量池添加新的混淆名稱，并更新字段名稱的索引u2nameIndex指向新的混淆名稱。
// Actually apply the new names.
programClassPool.classesAccept(new ClassRenamer());
public void visitProgramMember(ProgramClass programClass,
ProgramMember programMember) {
// Has the class member name changed?
String name = programMember.getName(programClass);
String newName = MemberObfuscator.newMemberName(programMember);
if (newName != null && !newName.equals(name)) {
programMember.u2nameIndex = new ConstantPoolEditor(programClass).addUtf8Constant(newName);
}
第六步：常量池壓縮，新的混淆名稱是通過在常量池中新增數據，原先的數據并沒有被刪除，需要進行修復，由于篇幅優先不做詳細分析。
R8 編譯器為什么不支持該混淆規則？
從上面的現象上看，R8編譯器是忽略了"-useuniqueclassmembernames"的混淆規則，但是在谷歌Android開發文檔“縮減應用大小”用戶指南里也沒有提到該規則的相關信息，接下來嘗試通過源碼層面查找該規則被忽略的原因。通過查找資料，在?提交記錄?。"-useuniqueclassmembernames"混淆的規則在ProGuard中主要用于增量?混淆?，但是引入R8編譯器的主要目標是進一步縮減應用的大小，如果在R8中支持該規則只會增加代碼混淆的復雜性，并沒有帶來真正的好處。
R8 還有哪些混淆規則不支持？
查看ProguardConfigurationParser.java源碼(https://r8.googlesource.com/r8/+/3a100449ba5b490cd13d466b8c7e17dcd500722a/src/main/java/com/android/tools/r8/shaking/ProguardConfigurationParser.java)，以下混淆規則會被R8編譯器忽略：
-forceprocessing
-dontusemixedcaseclassnames
-dontpreverify
-experimentalshrinkunusedprotofields
-filterlibraryjarswithorginalprogramjars
-dontskipnonpubliclibraryclasses
-dontskipnonpubliclibraryclassmembers
-invokebasemethod
-mergeinterfacesaggressively
-android
-shrinkunusedprotofields
-allowruntypeandignoreoptimizationpasse
-addconfigurationdebugging
-assumenoescapingparameters
-assumenoexternalreturnvalues
-dump
-keepparameternames
-outjars
-target
-useuniqueclassmembernames
1.3 混淆小結
如果你的項目工程中同時滿足以下情況，就有可能在升級AGP的過程中，出現字段解析獲取不到對應值的問題，導致業務功能異常：
- 添加了"-useuniqueclassmembernames"混淆規則；
- 有多個業務線不同的數據類又包含一些相同的字段；
- 不能保證所有的數據類在進行網絡json數據解析時添加了keep規則；
- 打算升級AGP啟用R8編譯。
針對Android開發的混淆建議：
- 開發檢查數據類是否添加了keep規則的Gradle自定義插件，在工程打包調式階段通過錯誤日志提前提醒開發者是否有混淆風險；
- 針對混淆形成最佳實踐來指導開發者正確使用混淆規則，例如將所有的數據類放在統一的包中，添加該包名的keep規則，或者涉及到反序列化或反射相關的，也可以添加@Keep注解。
02v1簽名邏輯
2.1 v1簽名丟失問題
京東APP調試包會讀取v1簽名的信息，在升級AGP 3.6.4 后運行調試包崩潰，排除原因發現是通過Android Studio run按鈕生成的調試包中的v1簽名丟失導致的。
我們通常會在工程app目錄的build.gradle文件進行簽名相關設置：
signingConfigs {
release {
storeFile file('xxx')
storePassword 'xxx'
keyAlias 'xxx'
keyPassword 'xxx'
v1SigningEnabled true
v2SigningEnabled true
}
}
buildTypes {
debug {
minifyEnabled false
shrinkResources false
zipAlignEnabled true
signingConfig signingConfigs.release
}
release {
minifyEnabled true
shrinkResources true
zipAlignEnabled true
signingConfig signingConfigs.release
}
}2.2 原因分析
通過查閱AGP 3.6.4源碼發現在PackageAndroidArtifact類執行doTask()靜態方法中會創建IncrementalPackagerBuilder會涉及到簽名相關，代碼如下：
public IncrementalPackagerBuilder withSigning(
@Nullable SigningConfigData signingConfig, int minSdk,
@Nullable Integer targetApi) {
boolean enableV1Signing =
enableV1Signing(
signingConfig.getV1SigningEnabled(),
signingConfig.getV2SigningEnabled(),
minSdk,
targetApi);
boolean enableV2Signing = (targetApi == null || targetApi >= NO_V1_SDK)
&& signingConfig.getV2SigningEnabled();
creationDataBuilder.setSigningOptions(
SigningOptions.builder()
.setKey(certificateInfo.getKey())
.setCertificates(certificateInfo.getCertificate())
.setV1SigningEnabled(enableV1Signing)
.setV2SigningEnabled(enableV2Signing)
.build());
} catch (KeytoolException|FileNotFoundException e) {
throw new RuntimeException(e);
}
return this;
}
private static int NO_V1_SDK = 24;
static boolean enableV1Signing(boolean v1Enabled, boolean v2Enabled,
int minSdk, @Nullable Integer targetApi) {
if (!v1Enabled) {
return false;
}
// If there is no v2 signature specified we have to sign with v1 even if the versions are
// high enough otherwise we would not have signed at all
if (!v2Enabled) {
return true;
}
// Case where both v1Enabled==true and v2Enabled==true
return (targetApi == null || targetApi < NO_V1_SDK) && minSdk < NO_V1_SDK;
從上面enableV1Signing()方法中可以看到，targetApi是指連接電腦的手機的系統版本，會根據當前連接的測試機的系統版本是否小于Android7.0來判斷是否啟用v1簽名，如果手機系統大于Android7.0的話，v1簽名將會失效。
解決方案，將targetApi通過反射置為null，在build.gralde文件添加如下設置：
project.afterEvaluate {
project.android.getApplicationVariants().all { appVariant ->
String variantName = appVariant.name.capitalize()
Task packageTask = project.tasks.findByName("package${variantName}")
try {
if (packageTask.getTargetApi() != null) {
Field field = packageTask.getClass().getSuperclass().getSuperclass().getDeclaredField("targetApi")
field.setAccessible(true)
field.set(packageTask, null)
}
} catch (Exception e) {
e.printStackTrace()
}
}
}從源碼IncrementalPackagerBuilder.java提交的變更記錄來看，啟用v1/v2簽名的邏輯變化了多次。
03打包流程
3.1 現象
京東APP在打包過程中通過APT技術識別代碼中的注解，然后將注解信息生成json文件存放到工程assets目錄，隨后該json文件會被一起打包進apk中，但是在升級 AGP 后，在進行打包時該json文件丟失導致功能異常。排查原因發現是打包過程中的某些任務執行順序發生了變化：
升級 AGP 前：
> Task :AndroidPhone:compileXXXJavaWithJavac
> Task :AndroidPhone:mergeXXXAssets
升級 AGP 后：
> Task :AndroidPhone:mergeXXXAssets
> Task :AndroidPhone:compileXXXJavaWithJavac
由于注解處理邏輯在 compileXXXJavaWithJavac 任務中，上述兩個任務在執行順序發生變化后，會導致合并assets資源文件任務優先于拷貝json文件到項目工程assets目錄，最終導致json文件在apk包中丟失。
3.2 解決方案
將兩任務設置先后依賴的關系，build.gradle中添加如下腳本：
project.afterEvaluate {
project.android.applicationVariants.all {
def variantName = it.name.capitalize()
Task compileJavaWithJavacTask = project.tasks.findByName("compile${variantName}JavaWithJavac")
Task mergeAssetsTask = project.tasks.findByName("merge${variantName}Assets")
mergeAssetsTask.dependsOn(compileJavaWithJavacTask)
}
}AGP升級建議
- 首先將升級AGP前后的apk產物進行對比，檢查資源文件等是否有缺失；
- 制作腳本工具來對比升級前后生成的mapping.txt文件，檢查本該添加keep規則的類或字段是否有遺漏；
- 針對R8編譯器不支持的，影響全局的ProGuard混淆規則做好潛在風險評估：例如混淆規則"-useuniqueclassmembernames"；
- 全面評估升級AGP的風險，做好降級預案。
總結
本文主要介紹的是京東APP在升級Android構建工具AGP 3.6.4過程中的踩坑記錄，升級完成后包體積減少了約1.5MB，希望上面的踩坑經驗能夠幫助到打算升級AGP的讀者。
