聽說 Android 9.0 要禁用 @Hide Api 的調用，你怎麼看？

標籤：pre   a20   交流   控制   oid   exception   判斷   block   pen   

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 頭疼嗎？

聽說 Android 9.0 要禁用 @Hide Api 的調用，你怎麼看？