概述

昨天群友在群裡丟了一個日誌資訊，說Jpush的服務初始化異常,我就幫忙下了個Demo集成了下。發現是自定義使用者許可權的出錯了。下面獻上我的分析。

09-05 21:22:45.279: D/JPush(21334): [PushService] Action: init PushService
09-05 21:22:45.279: D/JPush(21334): [AndroidUtil] action:checkValidManifest
09-05 21:22:54.289: E/JPush(21334): [AndroidUtil] The permission should be defined - com
 
.machinebook.customer.permission.JPUSH_MESSAGE
09-05 21:22:54.293: W/JPush(21334): [PushService] JPush running checked failed!
09-05 21:22:54.308: D/JPush(21334): [PushService] onStartCommand - intent:Intent { act=cn.jpush.android.intent.REPORT cmp=com.machinebook.customer/cn.jpush.android.service.PushService
 
 (has extras) }, pkg:com.machinebook.customer, connection:0
09-05 21:22:54.308: D/JPush(21334): [PushService] onStartCommand - not valid JPush running - Should not be here.
09-05 21:22:54.308: D/JPush(21334): [PushService] onStartCommand - intent:Intent { act=cn.jpush.android.intent.INIT cmp=com.machinebook.customer
 
/cn.jpush.android.service.PushService (has extras) }, pkg:com.machinebook.customer, connection:0
09-05 21:22:54.308: D/JPush(21334): [PushService] onStartCommand - not valid JPush running - Should not be here.

上面的日誌可以看見，我初始化失敗了。搜尋JPUSH Android常見問題說我沒有沒有正確的定義permision，請新增許可權。檢視後發現我下面沒有新增這行許可權。

    <!-- 自定義許可權 -->
    <permission
        android:name="com.machinebook.customer.permission.JPUSH_MESSAGE"
        android:protectionLevel="signature" />

    <!--使用者許可權請求-->
    <uses-permission android:name="com.machinebook.customer.permission.JPUSH_MESSAGE" />

許可權

許可權是一種限制，用於限制對部分程式碼或裝置上資料的訪問。 施加限制是為了保護可能被誤用以致破壞或損害使用者體驗的關鍵資料和程式碼。

每種許可權均由一個唯一的標籤標識。標籤通常指示受限制的操作。 例如，以下是由 Android 定義的一些許可權：

android.permission.CALL_EMERGENCY_NUMBERS 
android.permission.READ_OWNER_DATA 
android.permission.SET_WALLPAPER 
android.permission.DEVICE_POWER

一個功能最多隻能由一種許可權保護。

如果應用需要訪問受許可權保護的功能，則必須在清單檔案中使用 元素宣告應用需要該許可權。 但是，將應用安裝到裝置上之後，安裝程式會通過檢查簽署應用證書的頒發機構並（在某些情況下）詢問使用者，確定是否授予請求的許可權。 如果授予許可權，則應用能夠使用受保護的功能。 否則，其訪問這些功能的嘗試將會失敗，並且不會向用戶傳送任何通知。

此外，應用也可以使用許可權保護自己的元件（Activity、服務、廣播接收器和內容提供程式）。 它可以採用由 Android 定義（如 android.Manifest.permission 中所列）或由其他應用宣告的任何許可權。或者，它也可以定義自己的許可權。新許可權用 元素來宣告。 例如，Activity 可受到如下保護：

<manifest . . . >
    <permission android:name="com.example.project.DEBIT_ACCT" . . . />
    <uses-permission android:name="com.example.project.DEBIT_ACCT" />
    . . .
    <application . . .>
        <activity android:name="com.example.project.FreneticActivity"
                  android:permission="com.example.project.DEBIT_ACCT"
                  . . . >
            . . .
        </activity>
    </application>
</manifest>

請注意，在此示例中，DEBIT_ACCT 許可權不僅是通過 元素來宣告，而且其使用也是通過 元素來請求。要讓應用的其他元件也能夠啟動受保護的 Activity，就必須請求其使用許可權，即便保護是由應用本身施加的亦如此。

同樣還是在此示例中，如果將 permission 屬性設定為在其他位置（例如，android.permission.CALL_EMERGENCY_NUMBERS）宣告的許可權，則無需使用 元素再次宣告。 但是，仍有必要通過 請求使用它。

一個許可權隱含的潛在風險，並指示決定是否准予許可請求它的應用程式時，系統應遵循的程式，Standard permissions有一個預定義的和永久的ProtectionLevel。如果您在應用程式中建立自定義許可權，您可以定義下面列出的值之一的ProtectionLevel屬性。如果沒有的ProtectionLevel為自定義許可權定義，系統分配的預設（“正常”）。

Android protectionLevel分4個級別：

“normal”
“dangerous”
“signature”
“signatureOrSystem”

• 如果定義的是前面兩種normal或者dangerous, 我們自己的應用需要去訪問其對應受保護的資源時只需要在androidManifest.xml中新增相同的uses-permission就行了
• 如果是signature, 我們僅僅新增對許可權的使用還不行， 必須同時具有相同的簽名。
• 如果是signatureOrSystem（這種許可權的應用第三方的應用無法單獨訪問）, 不僅要有相同的簽名，而且簽名必須是系統簽名，此外可能還需要android : sharedUserId=”android.uid.system”。

深入原始碼

系統定義許可權主要來自於兩處：
- framework/base/core/res/AndroidManifest.xml
檢視原始碼

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android" coreApp="true" android:sharedUserId="android.uid.system"
    android:sharedUserLabel="@string/android_system_label">
    <!-- ================================================ -->
    <!-- Special broadcasts that only the system can send -->
    <!-- ================================================ -->
    <eat-comment />
    <protected-broadcast android:name="android.intent.action.SCREEN_OFF" />
    <protected-broadcast android:name="android.intent.action.SCREEN_ON" />
    <protected-broadcast android:name="android.intent.action.USER_PRESENT" />
    <protected-broadcast android:name="android.intent.action.TIME_SET" />
    <protected-broadcast android:name="android.intent.action.TIME_TICK" />
    <protected-broadcast android:name="android.intent.action.TIMEZONE_CHANGED" />
    <protected-broadcast android:name="android.intent.action.DATE_CHANGED" />
    <protected-broadcast android:name="android.intent.action.BOOT_COMPLETED" />
    <protected-broadcast android:name="android.intent.action.PACKAGE_INSTALL" />
    <protected-broadcast android:name="android.intent.action.PACKAGE_ADDED" />
    <protected-broadcast android:name="android.intent.action.PACKAGE_REPLACED" />
    <protected-broadcast android:name="android.intent.action.MY_PACKAGE_REPLACED" />
    <protected-broadcast android:name="android.intent.action.PACKAGE_REMOVED" />
    <protected-broadcast android:name="android.intent.action.PACKAGE_FULLY_REMOVED" />
....

• framework/base/data/etc/platform.xml

靜態讀取

在6.0以前，APP在第一次安裝的時候,就會讀取我們的配置清單檔案，告知使用者APP獲取的許可權。這時候我們就可以選擇是否全部授權了。

動態讀取

6.0以後，系統原始碼加入了動態讀取許可權，也就是說，當某個功能使用到的時候，在去彈窗提示使用者。大大的加入了靈活性和安全性。

這裡說的比較簡單，有興趣的可以自行搜尋下其他文章。

思維拓展:

有興趣的還可以研究一下幾個問題。
為什麼Jpush要自定義許可權，對應用有什麼好處？

從上面的API來看,當第三方要讀取我們的資料時候，如果設定signature，那麼可以提高對我們自己應用資料的保護。如果是這樣我們平常來做應用的時候，如果想提高APP資料的安全，是不是相應的也可以構造自己的許可權加以利用。

1. App安裝流程，如何從原始碼的角度分析,系統怎麼讀取manifest檔案？
2. 6.0的動態申請許可權，如何做適配？

剩下的兩個問題都是大坑，今天不談了，有興趣的可以自行深究下。

參考文件