Android中startActivity中的permission檢測與UID機制 共用進程

我們經常在一個activity中去start另一個activity，或者與另一個acitivity的結果進行互動（startActivityForResult）。但有沒有想過可能會出現的permission問題呢？如果你遇到了permission denial的Exception，那麼你需要讀讀這篇文章啦。

我們在同一個application內部，可以隨意的startActivity from Activity A to Activity B，而官方的文檔中說startActivity可能會報NotFoundException，表示被start的Activity不存在。因此，我們很容易忽略另一個可能的Exception，Permission Denial。

當我們在不同的application中，如application A中的Activity去start一個application B中的Activity，也許你什麼Exception都不會得到，也可能會直接Force Close掉。因為再Start Activity時，代碼是有去檢驗permission的。

如下情況，可以成功startActivity而不會得到permission denial

1、同一個application下

2、Uid相同

3、permission匹配

4、目標Activity的屬性Android:exported=”true”

5、目標Activity具有相應的IntentFilter，存在Action動作或其他過濾器並且沒有設定exported=false

6、啟動者的Pid是一個System Server的Pid

7、啟動者的Uid是一個System Uid（Android規定android.system.uid=1000，具有該Uid的application，我們稱之為獲得Root許可權）

如果上述調節，滿足一條，一般即可（與其他幾條不發生強制設定衝突），否則，將會得到Permission Denial的Exception而導致Force Close。

現在，我來解釋一下Uid機制

眾所周知，Pid是進程ID，Uid是使用者ID，只是Android和電腦不一樣，電腦每個使用者都具有一個Uid，哪個使用者start的程式，這個程式的Uid就是那個那個使用者，而Android中每個程式都有一個Uid，預設情況下，Android會給每個程式分配一個普通層級互不相同的Uid，如果用互相調用，只能是Uid相同才行，這就使得共用資料具有了一定安全性，每個軟體之間是不能隨意獲得資料的。而同一個application只有一個Uid，所以application下的Activity之間不存在存取權限的問題。

如果你需要做一個application，將某些服務service，provider或者activity等的資料，共用出來怎麼辦，三個辦法。

1、完全暴露，這就是android:exported=”true”的作用，而一旦設定了intentFilter之後，exported就預設被設定為true了，除非再強制設為false。當然，對那些沒有intentFilter的程式體，它的exported屬性預設仍然是false，也就不能共用出去。

2、許可權提示暴露，這就是為什麼經常要設定usePermission的原因，如果人家設定了android:permission=”xxx.xxx.xx”那麼，你就必須在你的application的Manufest中usepermission xxx.xxx.xx才能訪問人家的東西。

3、私人暴露，假如說一個公司做了兩個產品，只想這兩個產品之間可互相調用，那麼這個時候就必須使用shareUserID將兩個軟體的Uid強制設定為一樣的。這種情況下必須使用具有該公司簽名的簽名文檔才能，如果使用一個系統內建軟體的ShareUID，例如Contact，那麼無須第三方簽名。

這種方式保護了第三方軟體公司的利益於資料安全。

當然如果一個activity是又system process跑出來的，那麼它就可以橫行霸道，任意許可權，只是你無法開發一個第三方application具有系統的Pid（系統Pid不固定），但是你完全可以開發一個具有系統Uid的程式，對系統中的所有程式任意訪問，只需再Manufest中聲明shareUserId為android.system.uid即可，產生的檔案也必須經過高許可權簽名才行，一般不具備這種審核條件的application，google不會提供給你這樣的簽名檔案。當然你是在編譯自己的系統的話，想把它作成系統軟體程式，只需在Android.mk中聲明Certificate:platform則可以了，既採用系統簽名。這個系統Uid的獲得過程，我們把它叫做獲得Root許可權的過程。所以很多第三方系統管理軟體就是有Root許可權的軟體，因為他需要對系統有任意訪問的許可權。那麼它的Root簽名則需要和編譯的系統一致，例如官方的系統得用官方的簽名檔案，CM的系統就得用CM的簽名檔案。（這裡就不多講了）

講到這裡，大家應該明白Uid機制了吧。^_

安裝在裝置中的每一個Android包檔案（.apk）都會被分配到一個屬於自己的統一的Linux使用者ID，並且為它建立一個沙箱，以防止影響其他應用程式（或者其他應用程式影響它）。使用者ID 在應用程式安裝到裝置中時被分配，並且在這個裝置中保持它的永久性。

通過Shared User id,擁有同一個User id的多個APK可以配置成運行在同一個進程中.所以預設就是可以互相訪問任意資料. 也可以配置成運行成不同的進程, 同時可以訪問其他APK的資料目錄下的資料庫和檔案.就像訪問本程式的資料一樣.

對於一個APK來說，如果要使用某個共用UID的話，必須做三步：

1、在Manifest節點中增加android:sharedUserId屬性。

2、在Android.mk中增加LOCAL_CERTIFICATE的定義。

如果增加了上面的屬性但沒有定義與之對應的LOCAL_CERTIFICATE的話，APK是安裝不上去的。提示錯誤是：Package com.test.MyTest has no signatures that match those in shared user android.uid.system; ignoring!也就是說，僅有相同簽名和相同sharedUserID標籤的兩個應用程式簽名都會被分配相同的使用者ID。例如所有和media/download相關的APK都使用android.media作為sharedUserId的話，那麼它們必須有相同的簽名media。

3、把APK的源碼放到packages/apps/目錄下，用mm進行編譯。

舉例說明一下。

系統中所有使用android.uid.system作為共用UID的APK，都會首先在manifest節點中增加android:sharedUserId="android.uid.system"，然後在Android.mk中增加LOCAL_CERTIFICATE := platform。可以參見Settings等

系統中所有使用android.uid.shared作為共用UID的APK，都會在manifest節點中增加android:sharedUserId="android.uid.shared"，然後在Android.mk中增加LOCAL_CERTIFICATE := shared。可以參見Launcher等

系統中所有使用android.media作為共用UID的APK，都會在manifest節點中增加android:sharedUserId="android.media"，然後在Android.mk中增加LOCAL_CERTIFICATE := media。可以參見Gallery等。

另外，應用建立的任何檔案都會被賦予應用的使用者標識，並且正常情況下不能被其他包訪問。當通過getSharedPreferences（String，int）、openFileOutput（String、int）或者openOrCreate Database（String、int、SQLiteDatabase.CursorFactory）建立一個新檔案時，開發人員可以同時或分別使用MODE_WORLD_READABLE和MODE_WORLD_RITEABLE標誌允許其他包讀/寫此檔案。當設定了這些標誌後，這個檔案仍然屬於自己的應用程式，但是它的全域讀/寫和讀/寫入權限已經設定，所以其他任何應用程式可以看到它。

關於簽名：

build/target/product/security目錄中有四組預設簽名供Android.mk在編譯APK使用：

1、testkey：普通APK，預設情況下使用。

2、platform：該APK完成一些系統的核心功能。經過對系統中存在的檔案夾的訪問測試，這種方式編譯出來的APK所在進程的UID為system。

3、shared：該APK需要和home/contacts進程共用資料。

4、media：該APK是media/download系統中的一環。

應用程式的Android.mk中有一個LOCAL_CERTIFICATE欄位，由它指定用哪個key簽名，未指定的預設用testkey.

Uid 類似與標定 pc機使用者的許可權          許可權高 享有的資源就多

多個application共用同一個process 

<application >下的

android:process

By setting this attribute to a process name that's shared with anotherapplication, you can arrange for components of both applications to run inthe same process — but only if the two applications also share auser ID and be signed
with the same certificate.