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

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 中的代碼，權限級別和咱們開發中編寫的代碼是同樣的。

因此這就存在兩個方向的問題：

一、區分來自 Support Library 的調用和開發者調用。

二、一刀切，直接修改 Support Library 源碼和系統源碼，從新審視那些如今被標記爲 @hide 的方法，將那些不會影響安全和隱私的 APIs 所有開放出來，容許開發者調用。

下面咱們繼續開腦洞，仔細說說這些的區別。

一、區分調用來源

若是 Google 有辦法區分調用來自哪裏，而後針對不一樣的調用來源來實行不一樣的調用權限控制。

對開發者而言，實際上就是有漏洞可讓咱們模擬成一個來自 Support Library 的調用，就依然能夠繞過不容許調用 @hide 方法的限制，這個明顯是有隱患的。

二、一刀切

從現有 Support Library 中的代碼能夠看到，其實它使用的 @hide 方法，並不全都是涉及安全和隱私的。

就拿最近分析的 Autosizing 來講，它其中大量的調用了一些 TextView 的諸如 getHorizontallyScrolling()、getLineSpacingMultiplier()、getLineSpacingExtra() 方法，這些方法其實並不觸及安全和隱私。

只是爲了拿個文本控件的屬性而已，能有什麼不安全或者不隱私的？慎重考慮以後，拿掉這些方法的 @hide 就行了，開放調用，就不須要區分那麼多了。

結語

以上都是個人簡單猜想和開腦洞後的想法，說了這麼多，Android 依然爲向着安全、易用的方向發展，因此不管是限制或是不限制，都是爲了讓用戶好的使用。

對 Google 可能會限制 @hide APIs 的調用，你有什麼獨特的見解？歡迎在留言區分享！

今天在承香墨影公衆號的後臺，回覆『成長』。我會送你一些我整理的學習資料。

我另外還維護了一個技術交流的微信羣，有興趣能夠在公衆號後臺回覆："加羣"

推薦閱讀：

• 站在Android開發的角度，聊聊Airbnb的Lottie
• 這些工具，讓你寫博客的時候，只須要專一寫做！
• 找了一天找不到 Bug ? 試試 Git 的二分法吧！！！
• 如何更精準的在 Github 上搜索開源庫？你須要這些技巧！
• Android 開發，趕上 Emoji 頭疼嗎？