Android中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.
相關文章
- android中反射機制Android反射
- 共享庫soname機制
- 大叔也說Xamarin~Android篇~為HttpClient共享Session,android與api的session共享機制AndroidHTTPclientSessionAPI
- Android中的IPC機制Android
- 圖解Android中的binder機制圖解Android
- Android中TouchEvent觸控事件機制Android事件
- 淺析Android中的訊息機制Android
- docker 映象中的uidDockerUI
- Android 程式通訊機制之 AIDLAndroidAI
- ios,android和javascript的UI事件機制iOSAndroidJavaScriptUI事件
- Android程式間通訊–訊息機制及IPC機制實現薦Android
- session機制和cookie機制SessionCookie
- 虛擬機器和windows主機中的檔案共享虛擬機Windows
- Android混淆機制Android
- Android 事件機制Android事件
- Android 安全機制Android
- uniq(uid) distinct uidUI
- 淺談Android中的事件分發機制Android事件
- 如何回答Android面試中java垃圾回收機制Android面試Java
- Android中觸控事件的傳遞機制Android事件
- ADB命令獲取Android UIDAndroidUI
- Android應用程式訊息處理機制Android
- Android 訊息機制:Handler、MessageQueue 和 LooperAndroidOOP
- Android Handler機制理解和AsyncTask使用小記Android
- 【Android原始碼】Binder機制和AIDL分析Android原始碼AI
- Java 中的 Wait 和 Notify 機制JavaAI
- Android中的非同步訊息處理機制Android非同步
- 詳解 Android 中的 IPC 機制:基礎篇Android
- Android Classloader機制Android
- Android IPC 機制分析Android
- Android包管理機制Android
- Android簽名機制Android
- Android Framework : Alarm 機制AndroidFramework
- Android Handler機制理解Android
- android: 廣播機制Android
- 理解Android安全機制Android
- MySQL中的事務原理和鎖機制MySql
- 【Spark篇】---Spark中Shuffle機制,SparkShuffle和SortShuffleSpark