一些常識：

1）全書70個程式碼例子中，涉及到外掛的例子，請先assemble外掛的專案，這會在HostApp專案中生成assets目錄，並在該目錄下plugin1.apk。這樣，HostApp才能正常執行。

2）本書基於Android6.0（API level 23）的原始碼進行分析，本書的程式碼在Android7.0（API level 24）手機上測試都是能正常工作的。對於Android 7.0以上版本，有些外掛化的解決方案，已經過時了，比如AMN的gDefault欄位。

3）針對於Android8.0（API 26），Android8.1（API 27），Android9（API 28），外掛化所需要做的適配工作，參加以下3篇文章（第2版作為第23章會放入書中）：

-----------------------------------------------------------

2018年8月第1版第1次印刷

1）前言

比如說AssetsManager的addAssetPath方法，ActivityThread的currentActivityThread方法。

這句話刪除，舉例不當。

2）第2章，P25

ActivityManagerNativ改為ActivityManagerNative

3）第3章，P73

如果只想獲取類的所有public建構函式，就不能再使用Class的getConstructors方法了，而要使用getDeclaredConstructors方法。

這裡寫反了，訂正如下：

如果只想獲取類的所有public建構函式，只要呼叫Class的getConstructors方法就足夠了。

4）第6章，P133

applicationVariants.all { variant ->
        variant.outputs.each { output ->
            def file = output.outputFile
            output.outputFile = new File(file.parent,
                    "plugin1.apk")

            println("$buildDir/outputs/apk/")
            println("$rootDir/HostApp/src/main/assets")

            copy {
                from "$buildDir/outputs/apk/plugin1.apk"
                into "$rootDir/HostApp/src/main/assets"
            }
        }
}
 

上面這段指令碼，有個瑕疵，要執行兩次的外掛專案中的assembleRelease命令，才能在HostApp的assets目錄下生成plugin1.apk，訂正如下：

assemble.doLast {
    android.applicationVariants.all { variant ->
        // Copy Release artifact to HostApp's assets and rename
        if (variant.name == "release") {
            variant.outputs.each { output ->
                File originFile = output.outputFile
                println originFile.absolutePath
                copy {
                    from originFile
                    into "$rootDir/HostApp/src/main/assets"
                    rename(originFile.name, "plugin1.apk")
                }
            }
        }
    }
}

接下來，執行外掛專案的assemble命令，只要1次，即可生成在HostApp的assets目錄下生成plugin1.apk。

5)第2章 P32

App和ASM頻繁地向對方傳送訊息

修改為：App和AMS頻繁地向對方傳送訊息

6) 第2章，P44

2.9.2

在Service中，通過AMM/AMP

訂正為：

在Service中，通過AMN/AMP

7)第2章，P37

仍然是通過AMM/AMP

訂正為：仍然是通過AMN/AMP

8）前言，P5

把android-pluginmgr設計為對Instrumentation的思想進行Hook

訂正為： 把android-pluginmgr設計為對Instrumentation進行Hook

9）第18章，P287

ZeusStudy和1.6之間不應該有空格

10）第2章 P21

AndvoidManifest修改為AndroidManifest

11）第2章 P22

哪個，修改為那個

12）P101

圖中，多了一個-

13）P102，第9行末尾，重寫的邏輯，把英文句點改為中文句號。

14）P56

“主要邏輯都再此實現”中的“再此”應該為“在此”

15）113頁

“對AMN的getDafault方法進行Hook”中“getDafault”應該為“getDefault”。default寫錯了

16）110頁

“currentActivity-Thread”多了一個橫線“-”

17）124頁：

倒數第三行“會把asset目錄中的外掛”中的“asset目錄”應該為“assets目錄”。缺個s

18）

292頁：“它有一個getsSring函式”中的“getsSring”應該為“getString”

19）

319頁：“在Android Studio中建立一個過程”中的“過程”修改為“工程”。

 20）

320頁：第2行：“同時在自定義的Class-Loader中”中的“Class-Loader”修改為“ClassLoader”。 21） 320頁 第13行：“但是AndroidAndroid系統原始碼中也有一些類”中的“AndroidAndroid”修改為“Android“ 22）235頁 那麼就通過10.3.2介紹的proxyCreateService方法 10.3.2改為14.4.2 23）238頁 ServiceManager（省略了10.3.1介紹的proloadServices和10.3.2介紹的proxyCreateService） 10.3.2改為14.4.2 10.3.1改為14.4.3 preloadServices 改為preLoadServices 24）P97 RefInvoke.setFieldObject(sPackageManager,”sPackageManager”,proxy); 修改為
RefInvoke.setFieldObject(currentActivityThread,”sPackageManager”,proxy); 25）P100 圖5-2中 Context/Contexztimpi  修改為Context/ContextImpl