Android 9.0?
Hi，大家好，我是承香墨影！
距離 Android 8.0 發布，已經過了五個月，雖然現在占有率並不高，不過呢，Google 已經着手准備下一版本的 Android 系統。
上周，據快科技爆出來的消息，在 XDA社區 有人發現最近的 AOSP（Android Open Source Project）提交記錄中，懷疑是下一代 Android 系統版本的代碼：PI，這可能是 Android 9.0 的版本名稱。不過根據 Android 之前版本的命名習慣，Google 鍾愛使用甜點來命名版本，很多人猜測 Pi可能是 Pie（餡餅）的縮寫。
在 AOSP 最新的 commit 中，還暴露出來一些特別的信息，可能會開始限制一些沒有被文檔提及的非公開 APIs 的調用，例如被標記為 @hide 的 APIs。
上面是 commit 的截圖，有興趣可以去這里 AOSP 里看看細節。
https://android-review.googlesource.com/c/platform/external/doclava/+/589515
簡單看了一下這個 commit 的改動，可以看到，在 Stubs 中增加了一個 privateDexApiWriter，應該是用來記錄這些被標記為 @hide 的方法。
具體用來做什么的，也沒有深入深究，不過單純從這個 commit 里看到的內容猜測，應該是要着手限制一些 @hide APIs 的訪問。
那么我們繼續開一下腦洞，想想 Google 想要限制 @hide APIs 的調用，有那些需要考慮的。
@hide 方法
眾所周知，Android 系統在迭代的過程中，越來越重視安全這個因素。而有一些方法可能會涉及到系統安全、用戶隱私或者其他一些原因，總之有一些因素考量，在發布出來的時候，被 Google 標記為 @hide，表示並不希望開發者去使用它們。
而這些標記為 @hide 的方法，我們也是無法直接調用的，只能使用反射的方式去調用它們，這本身就是不安全的操作。
不過呢，我們有時候確實為了實現一些功能，需要使用到這些被標記為 @hide 的方法。
從前面提到的 commit 的描述中，可以看到，這種限制是 Dex-level 層的，也就是它應該可以做到無視反射調用。例如加個權限限制，調用的時候判斷無權調用則直接報錯或者讓你反射的時候調用，也無法起作用，其實都是限制的方式，現在還不用太深究原理。
Support Library
雖然 Google 是可以做到對 @hide 方法的限制的，不過有一點不知道大家注意到沒有，那就是 Support Library 中，也包含了大量 @hide APIs 的調用。
例如最近說到的 Autosizing 功能的實現中，就專門用來寫了一個方法，來做反射的調用，獲取 TextView 中的一些屬性值。
private <T> T invokeAndReturnWithDefault(@NonNull Object object,
@NonNull final String methodName, @NonNull final T defaultValue) {
T result = null;
boolean exceptionThrown = false;
try {
// Cache lookup.
Method method = getTextViewMethod(methodName);
result = (T) method.invoke(object);
} catch (Exception ex) {
exceptionThrown = true;
Log.w(TAG, "Failed to invoke TextView#" + methodName + "() method", ex);
} finally {
if (result == null && exceptionThrown) {
result = defaultValue;
}
}
return result;
}
Google 提供的一系列 Support Library 的庫，本質上都是 Google 為開發者准備的一些 APIs 擴展包，但是它不同於系統本身的 APIs。
我們在開發 Android 的階段，會指定一個 Api Level ，從 IDE 的表現來看，它會引用一個 android.jar ，本質上是為了我們開發階段能夠成功編譯而存在的，這個 Jar 包本身是不會被打包在 APK 中的。
在 Support Library 則不一樣，它只是 Google 提供的一個工具包，會真實的被編譯進 APK 中，會占用 APK 的體積。這就是為什么 Support v26 刪除了一些方法來促使體積減小，是一件讓人高興的事情。
而如果 Google 對 @hide 方法進行了一刀切的限制之后，Support Library 中的一些功能，應該也會受到影響，因為本質上它就是我們 Apk 中的代碼，權限級別和我們開發中編寫的代碼是一樣的。
所以這就存在兩個方向的問題：
1、區分來自 Support Library 的調用和開發者調用。
2、一刀切，直接修改 Support Library 源碼和系統源碼，重新審視那些現在被標記為 @hide 的方法，將那些不會影響安全和隱私的 APIs 全部開放出來，允許開發者調用。
下面我們繼續開腦洞，仔細說說這些的區別。
1、區分調用來源
如果 Google 有辦法區分調用來自哪里，然后針對不同的調用來源來實行不同的調用權限控制。
對開發者而言，實際上就是有漏洞可以讓我們模擬成一個來自 Support Library 的調用，就依然可以繞過不允許調用 @hide 方法的限制，這個明顯是有隱患的。
2、一刀切
從現有 Support Library 中的代碼可以看到，其實它使用的 @hide 方法，並不全都是涉及安全和隱私的。
就拿最近分析的 Autosizing 來說，它其中大量的調用了一些 TextView 的諸如 getHorizontallyScrolling()、getLineSpacingMultiplier()、getLineSpacingExtra() 方法，這些方法其實並不觸及安全和隱私。
只是為了拿個文本控件的屬性而已，能有什么不安全或者不隱私的？慎重考慮之后，拿掉這些方法的 @hide 就好了，開放調用，就不需要區分那么多了。
結語
以上都是我的簡單猜測和開腦洞后的想法，說了這么多，Android 依然為向着安全、易用的方向發展，所以無論是限制或是不限制，都是為了讓用戶好的使用。
對 Google 可能會限制 @hide APIs 的調用，你有什么獨特的看法？歡迎在留言區分享！
今天在承香墨影公眾號的后台，回復『成長』。我會送你一些我整理的學習資料。
我另外還維護了一個技術交流的微信群，有興趣可以在公眾號后台回復："加群"
推薦閱讀：
- 站在Android開發的角度，聊聊Airbnb的Lottie
- 這些工具，讓你寫博客的時候，只需要專注寫作！
- 找了一天找不到 Bug ? 試試 Git 的二分法吧！！！
- 如何更精准的在 Github 上搜索開源庫？你需要這些技巧！
- Android 開發，遇上 Emoji 頭疼嗎？
