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

上面是 commit 的截圖，有興趣可以去這裡 AOSP 裡看看細節。

簡單看了一下這個 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

例如最近說到的 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 的呼叫，你有什麼獨特的看法？歡迎在留言區分享！

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

我另外還維護了一個技術交流的微信群，有興趣可以在公眾號後臺回覆：”加群”

推薦閱讀：