從一個線上問題 重新認識R8編譯器

語言: CN / TW / HK

背景

在過去的一段時間內,京東Android APP通過圖片壓縮、圖片轉下載、資源混淆編譯、外掛化、外掛後裝、混合開發等一系列手段對安裝包大小進行了優化,取得了不錯的瘦身收益。在完成這些常規瘦身手段優化後,為了進一步優化安裝包的大小,調研了谷歌官方新推出的 R8 編譯器,瞭解到R8編譯器在提升構建效率的同時,又能優化包體積大小,所以我們開始嘗試升級AGP版本來啟用R8編譯,升級的過程不是很順利,遇到了下面這些問題。

混淆工具介紹

對於Android應用,為了提高應用的安全性,常將程式碼混淆作為手段之一。程式碼混淆就是將原始碼轉換成功能上等價,但是難於閱讀和理解的形式,降低程式碼的可讀性,即使被反編譯成功也很難得出程式碼的真正含義,通過程式碼混淆可以提升應用被反編譯破解的難度。另一方面程式碼混淆後,由於類、方法或者欄位的名稱被對映成簡短無意義的名稱,也能減少應用的包體積。

0 1

ProGuard

在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的優化流程

0 2

R8

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'
}

踩坑經驗

01

R8 混淆規則

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開發文件“縮減應用大小”使用者指南里也沒有提到該規則的相關資訊,接下來嘗試通過原始碼層面查詢該規則被忽略的原因。通過查詢資料,在R8 原始碼倉庫(https://r8.googlesource.com/r8) 提供的 IssueTracker(https://issuetracker.google.com/) 中搜索關鍵詞"useuniqueclassmembernames",找到了關於R8不支援該規則的程式碼 提交記錄(https://r8-review.googlesource.com/c/r8/+/36766) 。"-useuniqueclassmembernames"混淆的規則在ProGuard中主要用於 增量混淆(https://www.guardsquare.com/manual/configuration/examples#incremental) ,但是引入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註解。

02

v1簽名邏輯

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的讀者。

參考資料

[1] ProGuard混淆規則

https://www.guardsquare.com/manual/configuration/attributes

[2] R8

https://r8.googlesource.com/r8

[3] AGP原始碼