1. 程式人生 > >聽說 Android 9.0 要禁用 @Hide Api 的呼叫,你怎麼看?

聽說 Android 9.0 要禁用 @Hide Api 的呼叫,你怎麼看?

197

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

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

簡單看了一下這個 commit 的改動,可以看到,在 Stubs 中增加了一個 privateDexApiWriter,應該是用來記錄這些被標記為 @hide 的方法。

dexFile

具體用來做什麼的,也沒有深入深究,不過單純從這個 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 的呼叫,你有什麼獨特的看法?歡迎在留言區分享!

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

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

推薦閱讀: