前言

最近在開發A應用的時候對接了合作方的一個B應用，對方很快就把接口文檔發了過來，約定好我們之間通過B應用提供的XXXContentProvider來獲取相關的數據。一切看起來是如此的普通與簡單，但是從剛開始調試的那一刻起，詭異的事情就發送了。九十歲老太為何起死回生？數百頭母豬為何半夜慘叫？女生宿舍為何頻頻失竊？超市方便面為何慘招毒手？在這一切的背后，是人性的扭曲，還是道德的淪喪？事件的最后，讓我發現了Android系統的一個大坑！滴滴~ 老司機馬上開車，帶你一同踏上這段難忘的踩坑經歷~

先簡單回顧下Android的permissions機制

在AndroidManifest.xml里面聲明ContentProvider的時候，我們是可以指定對應的readPermission與writePermission的，這樣就可以限制第三方應用程序，必須聲明指定的讀寫權限，才能進行下一步的訪問，提高安全性。

<provider
    android:name=".provider.XXXContentProvider"
    android:authorities="com.aaa.bbb.ccc.provider.authorities"
    android:readPermission="com.aaa.bbb.ccc.provider.permission.READ_PERM"
    android:writePermission="com.aaa.bbb.ccc.provider.permission.WRITE_PERM"
    android:exported="true"/>

但是首先，我們得先通過<permission/>定義好相關應用的權限，且你可以通過android:protectionLevel來定義權限的訪問等級。常用的有以下幾種，更多參數介紹詳見官網permission-element。

• signature: 調用App必須與聲明該permission的App使用同一簽名
• system: 系統App才能進行訪問
• normal: 默認值，系統在安裝調用App的時候自動進行授權

<permission
    android:name="com.aaa.bbb.ccc.provider.permission.READ_PERM"
    android:protectionLevel="normal" />
<permission
    android:name="com.aaa.bbb.ccc.provider.permission.WRITE_PERM"
    android:protectionLevel="normal" />

What the fuck? SecurityException?

在調用App中，通過<uses-permission />聲明好調用需要的權限，然后通過getContentResolver().query()方法進行數據查詢，就這么簡單兩步。這個時候，程序居然崩潰了，拋出了SecurityException。這尼瑪我不是按照接口文檔聲明好權限了么？怎么會報安全問題呢？一定是我打開的方式不對。

03-29 12:08:12.839 4255-4271/com.codezjx.provider E/DatabaseUtils: Writing exception to parcel
    java.lang.SecurityException: Permission Denial: reading com.aaa.bbb.ccc.XXXProvider uri content://com.aaa.bbb.ccc.xxx/getxxx/ from pid=22529, uid=10054 requires null, or grantUriPermission()
        at android.content.ContentProvider.enforceReadPermissionInner(ContentProvider.java:539)
        at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:452)
        at android.content.ContentProvider$Transport.query(ContentProvider.java:205)
        at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112)
        at android.os.Binder.execTransact(Binder.java:500)

上面這段Log是在ContentProvider所在的應用發出來的，我們都知道ContentProvider中的各種操作其實底層都是通過Binder進行進程間通信的。如果Server發生異常，會把exception寫進reply parcel中回傳到Client，然后Client通過android.os.Parcel.readException()讀出Server的exception，然后拋出來。沒錯，就是這么暴力~

這個時候我開始懷疑接口文檔的準確性了，馬上擼起我的jadx對目標apk進行了反編譯，查了下對方的AndroidManifest.xml文件。里面聲明的permission的確沒錯，而且ContentProvider的authorities屬性也是正確的，exported屬性也是true。

SecurityException再次出現

當時一下子沒細想，為了快點把數據聯調好，我們暫時把permission給去掉了。哎呀媽，心想這下子可以安心的聯調了。沒想到，詭異的事情再次發生了。程序運行，SecurityException又再次出現了，還是跟上面的Log一模一樣。這尼瑪權限不都去掉了嗎？為什么還報這個異常呢？

java.lang.SecurityException: Permission Denial: reading com.aaa.bbb.ccc.XXXProvider uri content://com.aaa.bbb.ccc.xxx/getxxx/ from pid=22529, uid=10054 requires null, or grantUriPermission()

仔細分析了上面這段關鍵的Log，發現requires null這個關鍵的字眼。一般在ContentProvider出現權限問題的時候，會通過requires告訴你到底缺了什么permission。然而這里為什么是null呢？想想總感覺不對勁。

Read the Fucking Source Code

合作方告知，當初一直在4.4的機器上調試的，一直沒出現過這個問題。這次在5.1的機器上跑，才發現會奔潰。經過了各種嘗試與調試（此處省略一萬字），還是沒能找到報錯的原因，甚至曾一度開始懷疑人生了。這個時候，只能去啃啃源碼了，看能不能發現什么端倪。

ContentProvider的源碼位于frameworks/base/core/java/android/content/ContentProvider.java，沒有系統源碼的也可以直接翻SDK的源碼文件。直接查看Log中報錯的位置enforceReadPermissionInner()方法。

這段方法比較短，還是比較好理解的，其實就是在類似query()這些操作前會做一個檢查，確認調用方是否具有某些permission。如果沒授權，就會直接拋出SecurityException。

/** {@hide} */
protected void enforceReadPermissionInner(Uri uri, IBinder callerToken)
        throws SecurityException {
    final Context context = getContext();
    final int pid = Binder.getCallingPid();
    final int uid = Binder.getCallingUid();
    String missingPerm = null;

    if (UserHandle.isSameApp(uid, mMyUid)) {
        return;
    }

    if (mExported && checkUser(pid, uid, context)) {
        final String componentPerm = getReadPermission();
        if (componentPerm != null) {
            if (context.checkPermission(componentPerm, pid, uid, callerToken)
                    == PERMISSION_GRANTED) {
                return;
            } else {
                missingPerm = componentPerm;
            }
        }

        // track if unprotected read is allowed; any denied
        // <path-permission> below removes this ability
        boolean allowDefaultRead = (componentPerm == null);

        final PathPermission[] pps = getPathPermissions();
        if (pps != null) {
            final String path = uri.getPath();
            for (PathPermission pp : pps) {
                final String pathPerm = pp.getReadPermission();
                if (pathPerm != null && pp.match(path)) {
                    if (context.checkPermission(pathPerm, pid, uid, callerToken)
                            == PERMISSION_GRANTED) {
                        return;
                    } else {
                        // any denied <path-permission> means we lose
                        // default <provider> access.
                        allowDefaultRead = false;
                        missingPerm = pathPerm;
                    }
                }
            }
        }

        // if we passed <path-permission> checks above, and no default
        // <provider> permission, then allow access.
        if (allowDefaultRead) return;
    }

    // last chance, check against any uri grants
    final int callingUserId = UserHandle.getUserId(uid);
    final Uri userUri = (mSingleUser && !UserHandle.isSameUser(mMyUid, uid))
            ? maybeAddUserId(uri, callingUserId) : uri;
    if (context.checkUriPermission(userUri, pid, uid, Intent.FLAG_GRANT_READ_URI_PERMISSION,
            callerToken) == PERMISSION_GRANTED) {
        return;
    }

    final String failReason = mExported
            ? " requires " + missingPerm + ", or grantUriPermission()"
            : " requires the provider be exported, or grantUriPermission()";
    throw new SecurityException("Permission Denial: reading "
            + ContentProvider.this.getClass().getName() + " uri " + uri + " from pid=" + pid
            + ", uid=" + uid + failReason);
}

我們來關注下為什么會是requires null，其實就是因為missingPerm沒有被賦值。再仔細分析，如果下面這大段代碼沒有被執行的話，那么missingPerm就不會被賦值。

if (mExported && checkUser(pid, uid, context)) {
    ......
}

前面已經確認過mExported肯定是true的，那么沒執行的原因就是checkUser()方法返回了false。（之前有提到在Android4.4是不會出現這個SecurityException的，為什么呢？因為在Android5.0+后ContentProvider才增加了這段多用戶檢查的代碼，淚奔~）

我們來看下checkUser()這個方法，種種跡象表明，就是因為它返回了false，導致missingPerm沒賦值，并最終throw了SecurityException。

boolean checkUser(int pid, int uid, Context context) {
    return UserHandle.getUserId(uid) == context.getUserId()
            || mSingleUser
            || context.checkPermission(INTERACT_ACROSS_USERS, pid, uid)
            == PERMISSION_GRANTED;
}

通過反射與其他方式，我們可以逐個驗證checkUser()方法中各個boolean條件的值：

• (UserHandle.getUserId(uid) == context.getUserId()) -> false
• mSingleUser -> false
• (context.checkPermission(INTERACT_ACROSS_USERS, pid, uid) == PERMISSION_GRANTED) -> false

前面在踩坑的時候，自己寫了一套測試的demo，在正常情況下UserHandle.getUserId(uid) == context.getUserId()是會返回true的，其中返回的userId都是0（因為我測試機器就一個用戶）

種種跡象表明，合作方提供的問題應用中context.getUserId()返回值并不是0。在強烈的好奇心驅使下，我又擼起了jadx對目標apk再次進行了反編譯，全局搜索了下getUserId()方法，發現還真TM有類似的方法，在BaseApplication中，有這么一個getUserId()方法，用來返回注冊用戶的id。

而在ContentProvider中，mContext也就是Application這個Context實例，也就是說getUserId()方法被無意識的進行了重寫。因此，解決這個SecurityException異常最簡單的方法就是把BaseApplication中的getUserId()方法換個名字就好了。至此，整個踩坑經歷終于到了尾聲。

總結

通過這次踩坑，發現了Android系統中一個隱藏的問題。在自定義的Application中，如果你聲明了public int getUserId()這個方法，并且返回的不是當前用戶的userId，那么你的ContentProvider在Android5.0+的機器都會失效。不信？自己試試~

/** @hide */
@Override
public int getUserId() {
    return mBase.getUserId();
}

因為這個是一個@hide方法，所以通常這個重寫行為都是無意識的，IDE并不會提示你重寫了Application中的這個方法。但如果你比較幸運，剛好用了帶hidden-api的Android SDK Jar包，那么IDE會給你一個提示，但除了系統應用開發，一般很少人會導入hidden-api吧~

Missing `@Override` annotation on `getUserId()` more...

好了，這次的分析先到這里，希望大家以后遇到這個詭異的SecurityException異常的時候，不至于再跳進這個隱藏的大坑里~ Over~