A. 安卓的安全機制
android以linux操作系統內核為基礎，實現硬體設備驅動、進程和內存管理、網路協議棧、電源管理等核心系統功能。除此以外，Android還增加了一些面向移動設備的特有功能，如低內存管理LMK(Low Memory Killer)、匿名共享內存(Ashmem: Anonymous Shared Memory)，以及進程間通信Binder機制。這些功能的增強進一步提升了Android在內存管理、進程間通信等方面的安全性。
Android之前的版本並不存在硬體抽象層。鑒於硬體廠商並不希望公開其設備驅動的源代碼，Google對此將Linux內核驅動程序進行封裝，屏蔽掉底層的實現細節，向上提供統一的介面，這就是硬體抽象層。
HAL(Hardware Abstraction Layer)規定了一套應用層對硬體層的讀寫和配置的統一介面，本質上是將硬體的驅動分為用戶空間和內核空間，其中內核驅動程序運行在內核空間，HAL運行在用戶空間。上圖中的Stub，以so庫的形式存在，可以理解為proxy。上層通過調用標識獲得HAL的相關Stub，進而取得相應操作。
系統運行時庫由系統類庫和Android運行時構成。系統類庫基本上用C/C++編寫，基本功能說明如下：
當然，還有Android NDK(Native Development Kit)，使得應用程序可以不依賴Dalvik虛擬機進行開發。Android運行時核心庫提供android.os, android.net, android.media等核心API，而Dalvik虛擬機依賴Linux內核，實現進程隔離與線程調度管理、安全與異常管理、垃圾回收等功能，並被改進以適應低內存、低處理器速度的移動設備環境。
再往上就是應用程序框架層了。一系列的Android應用程序所需的類庫，使得開發人員可以快速地進行程序開發，也可以通過繼承實現個性化的擴展。如Activity Manager負責主線程ActivityThread的創建、Activity生命周期的維護，並為窗口提供交互的介面。
應用層就是與用戶直接交互的應用程序，如SMS簡訊、圖片瀏覽器、地圖以及開發人員所開發的應用程序。
B. Android許可權機制
我們知道 Android 應用程序是沙箱隔離的，每個應用都有一個只有自己具有讀寫許可權的專用數據目錄。但是如果應用要訪問別人的組件或者一些設備上全局可訪問的資源，這時候許可權機制就能系統化地規范並強制各類應用程序的行為准則。
Android 安全性概覽
在 Android 中，一個許可權，本質上是一個字元串，一個可以表示執行特定操作的能力的字元串。比如說：訪問 SD 卡的能力，訪問通訊錄的能力，啟動或訪問一個第三方應用中的組件的能力。 許可權被授予了之後，首先會在內存和本地中有記錄，這在調用系統binder服務和其他應用組件時做鑒權依據,比如調用系統binder服務時會通過Binder.getCallingUid()拿到調用者的Uid，而Uid一般都是與應用包名一一對應的，再拿這個Uid到PMS里去查這個應用對應的許可權。 其次會按被授予的許可權將應用分到某個組。 可以參考 https://www.jianshu.com/p/a17c8bed79d9
自定義許可權的應用場景在於限制其它應用對本應用四大組件的訪問。具體用法可以參考 https://www.cnblogs.com/aimqqroad-13/p/8927179.html
pm list permissions -f 命令可以詳細查看 Android 所有預定義的許可權。
更詳細的許可權信息參考 https://developer.android.com/reference/android/Manifest.permission?hl=zh-cn#WRITE_EXTERNAL_STORAGE
可以看到一個許可權的信息包括：定義的包名、標簽、描述、 許可權組 和 保護級別 。
許可權根據設備的功能或特性分為多個組。如果應用已在相同許可權組中被授予另一危險許可權，系統將立即授予該許可權，如READ_CONTACTS和WRITE_CONTACTS。
SYSTEM_ALERT_WINDOW 和 WRITE_SETTINGS 由於其特殊性，其申請方式與其它許可權都不同。
其授予流程如下：
（關於 AppOpsManager 是什麼可以參考: https://segmentfault.com/a/1190000009214983 ）
這里簡要分析下ActivityCompat#requestPermissions的流程：
更詳細的許可權授予流程源碼分析可以參考: https://segmentfault.com/a/1190000009214983
普通許可權： 清單文件中聲明即可。
危險許可權： 方式一： pm grant application_package android.permission.CHANGE_CONFIGURATION 方式二：appops set application_package permission_num 0/1
appops可以授予的許可權參考 android.app.AppOpsManager 中的聲明
系統簽名許可權： 方式一：將app遷移到system/priv-app目錄中。 方式二：看不懂，參考 https://blog.csdn.net/abcd_3344_abcd/article/details/50698759
android 4.4 訪問sd卡需要申請許可權。 您的應用在 Android 4.4 上運行時無法讀取外部存儲空間上的共享文件，除非您的應用具有 READ_EXTERNAL_STORAGE 許可權。也就是說，沒有此許可權，您無法再訪問 () 返回的目錄中的文件。但是，如果您僅需要訪問 getExternalFilesDir() 提供的您的應用特有目錄，那麼，您不需要 READ_EXTERNAL_STORAGE `許可權。
android 6.0 運行時許可權。 此版本引入了一種新的許可權模式，如今，用戶可直接在運行時管理應用許可權。這種模式讓用戶能夠更好地了解和控制許可權，同時為應用開發者精簡了安裝和自動更新過程。用戶可為所安裝的各個應用分別授予或撤銷許可權。 對於以 Android 6.0（API 級別 23）或更高版本為目標平台的應用，請務必在運行時檢查和請求許可權。要確定您的應用是否已被授予許可權，請調用新增的 checkSelfPermission() 方法。要請求許可權，請調用新增的 requestPermissions() 方法。即使您的應用並不以 Android 6.0（API 級別 23）為目標平台，您也應該在新許可權模式下測試您的應用。 如需了解有關在您的應用中支持新許可權模式的詳情，請參閱 使用系統許可權 。如需了解有關如何評估新模式對應用的影響的提示，請參閱 許可權最佳做法 。
android 7.+ 應用間共享文件要使用FileProvider。 對於面向 Android 7.0 的應用，Android 框架執行的 StrictMode API 政策禁止在您的應用外部公開 file://URI。如果一項包含文件 URI 的 intent 離開您的應用，則應用出現故障，並出現 FileUriExposedException 異常。 要在應用間共享文件，您應發送一項 content:// URI，並授予 URI 臨時訪問許可權。進行此授權的最簡單方式是使用 FileProvider `類。如需了解有關許可權和共享文件的詳細信息，請參閱 共享文件 。
android 8.+
同一許可權組的許可權在被授予了之後也需要顯式的再申請一次。
在 Android 8.0 之前，如果應用在運行時請求許可權並且被授予該許可權，系統會錯誤地將屬於同一許可權組並且在清單中注冊的其他許可權也一起授予應用。 對於針對 Android 8.0 的應用，此行為已被糾正。系統只會授予應用明確請求的許可權。然而，一旦用戶為應用授予某個許可權，則所有後續對該許可權組中許可權的請求都將被自動批准。 例如，假設某個應用在其清單中列出 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE 。應用請求 READ_EXTERNAL_STORAGE ，並且用戶授予了該許可權。如果該應用針對的是 API 級別 24 或更低級別，系統還會同時授予 WRITE_EXTERNAL_STORAGE ，因為該許可權也屬於同一 STORAGE 許可權組並且也在清單中注冊過。如果該應用針對的是 Android 8.0，則系統此時僅會授予 READ_EXTERNAL_STORAGE ；不過，如果該應用後來又請求 WRITE_EXTERNAL_STORAGE ，則系統會立即授予該許可權，而不會提示用戶。
android 9
隱私許可權變更。
為了增強用戶隱私，Android 9 引入了若干行為變更，如限制後台應用訪問設備感測器、限制通過 Wi-Fi 掃描檢索到的信息，以及與通話、手機狀態和 Wi-Fi 掃描相關的新許可權規則和許可權組。
android 10
隱私權變更。
外部存儲訪問許可權范圍限定為應用文件和媒體，在後台運行時訪問設備位置信息需要許可權，針對從後台啟動 Activity 的限制等。
android 11
隱私許可權變更。
更詳細的版本變更請參考 https://developer.android.com/preview/privacy?hl=zh-cn
C. Android的許可權都有哪些
區分apk運行時的擁有的許可權與在文件系統上被訪問（讀寫執行）的許可權兩個概念。
apk程序是運行在虛擬機上的,對應的是Android獨特的許可權機制，只有體現到文件系統上時才使用linux的許可權設置。
（一）linux文件系統上的許可權
-rwxr-x--x system system 4156 2010-04-30 16:13 test.apk
代表的是相應的用戶/用戶組及其他人對此文件的訪問許可權，與此文件運行起來具有的許可權完全不相關。
比如上面的例子只能說明system用戶擁有對此文件的讀寫執行許可權；system組的用戶對此文件擁有讀、執行許可權；其他人對此文件只具有執行許可權。
而test.apk運行起來後可以干哪些事情，跟這個就不相關了。
千萬不要看apk文件系統上屬於system/system用戶及用戶組，或者root/root用戶及用戶組，就認為apk具有system或root許可權
（二）Android的許可權規則
（1)Android中的apk必須簽名
這種簽名不是基於權威證書的，不會決定某個應用允不允許安裝，而是一種自簽名證書。
重要的是，android系統有的許可權是基於簽名的。比如：system等級的許可權有專門對應的簽名，簽名不對，許可權也就獲取不到。
默認生成的APK文件是debug簽名的。
獲取system許可權時用到的簽名，見：如何使Android應用程序獲取系統許可權
（2）基於UserID的進程級別的安全機制
大家都知道，進程有獨立的地址空間，進程與進程間默認是不能互相訪問的，是一種很可靠的保護機制。
Android通過為每一個安裝在設備上的包（apk）分配唯一的linux userID來實現，名稱為"app_"加一個數字，比如app_43
不同的UserID，運行在不同的進程，所以apk之間默認便不能相互訪問。
Android提供了如下的一種機制，可以使兩個apk打破前面講的這種壁壘。
在AndroidManifest.xml中利用sharedUserId屬性給不同的package分配相同的userID，通過這樣做，兩個package可以被當做同一個程序，
系統會分配給兩個程序相同的UserID。當然，基於安全考慮，兩個package需要有相同的簽名，否則沒有驗證也就沒有意義了。
（這里補充一點:並不是說分配了同樣的UserID，兩程序就運行在同一進程, 下面為PS指令摘取的，
顯然，system、app_2分別對應的兩個進程的PID都不同，不知Android到底是怎樣實現它的機制的）
User PID PPID
system 953 883 187340 55052 ffffffff afe0cbcc S system_server
app_2 1072 883 100264 19564 ffffffff afe0dcc4 S com.android.inputmethod.
system 1083 883 111808 23192 ffffffff afe0dcc4 S android.process.omsservi
app_2 1088 883 156464 45720 ffffffff afe0dcc4 S android.process.acore
（3）默認apk生成的數據對外是不可見的
實現方法是：Android會為程序存儲的數據分配該程序的UserID。
藉助於Linux嚴格的文件系統訪問許可權，便實現了apk之間不能相互訪問似有數據的機制。
例：我的應用創建的一個文件，默認許可權如下，可以看到只有UserID為app_21的程序才能讀寫該文件。
-rw------- app_21 app_21 87650 2000-01-01 09:48 test.txt
如何對外開放？
<1> 使用MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE 標記。
When creating a new file with getSharedPreferences(String, int), openFileOutput(String, int), or openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory), you can use the MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE flags to allow any other package to read/write the file. When setting these flags, the file is still owned by your application, but its global read and/or write permissions have been set appropriately so any other application can see it.
（4）AndroidManifest.xml中的顯式許可權聲明
Android默認應用是沒有任何許可權去操作其他應用或系統相關特性的，應用在進行某些操作時都需要顯式地去申請相應的許可權。
一般以下動作時都需要申請相應的許可權：
A particular permission may be enforced at a number of places ring your program's operation:
At the time of a call into the system, to prevent an application from executing certain functions.
When starting an activity, to prevent applications from launching activities of other applications.
Both sending and receiving broadcasts, to control who can receive your broadcast or who can send a broadcast to you.
When accessing and operating on a content provider.
Binding or starting a service.
在應用安裝的時候，package installer會檢測該應用請求的許可權，根據該應用的簽名或者提示用戶來分配相應的許可權。
在程序運行期間是不檢測許可權的。如果安裝時許可權獲取失敗，那執行就會出錯，不會提示用戶許可權不夠。
大多數情況下，許可權不足導致的失敗會引發一個 SecurityException， 會在系統log（system log）中有相關記錄。
（5）許可權繼承/UserID繼承
當我們遇到apk許可權不足時，我們有時會考慮寫一個linux程序，然後由apk調用它去完成某個它沒有許可權完成的事情，很遺憾，這種方法是行不通的。
前面講過，android許可權是經營在進程層面的，也就是說一個apk應用啟動的子進程的許可權不可能超越其父進程的許可權（即apk的許可權），
即使單獨運行某個應用有許可權做某事，但如果它是由一個apk調用的，那許可權就會被限制。
實際上，android是通過給子進程分配父進程的UserID實現這一機制的。
（三）常見許可權不足問題分析
首先要知道，普通apk程序是運行在非root、非system層級的，也就是說看要訪問的文件的許可權時，看的是最後三位。
另外，通過system/app安裝的apk的許可權一般比直接安裝或adb install安裝的apk的許可權要高一些。
言歸正傳，運行一個android應用程序過程中遇到許可權不足，一般分為兩種情況:
（1）Log中可明顯看到許可權不足的提示。
此種情況一般是AndroidManifest.xml中缺少相應的許可權設置，好好查找一番許可權列表，應該就可解決，是最易處理的情況。
有時許可權都加上了，但還是報許可權不足，是什麼情況呢？
Android系統有一些API及許可權是需要apk具有一定的等級才能運行的。
比如 SystemClock.setCurrentTimeMillis()修改系統時間，WRITE_SECURE_SETTINGS許可權好像都是需要有system級的許可權才行。
也就是說UserID是system.
（2）Log里沒有報許可權不足，而是一些其他Exception的提示,這也有可能是許可權不足造成的。
比如：我們常會想讀/寫一個配置文件或其他一些不是自己創建的文件，常會報java.io.FileNotFoundException錯誤。
系統認為比較重要的文件一般許可權設置的也會比較嚴格，特別是一些很重要的(配置)文件或目錄。
如
-r--r----- bluetooth bluetooth 935 2010-07-09 20:21 dbus.conf
drwxrwx--x system system 2010-07-07 02:05 data
dbus.conf好像是藍牙的配置文件，從許可權上來看，根本就不可能改動，非bluetooth用戶連讀的權利都沒有。
/data目錄下存的是所有程序的私有數據，默認情況下android是不允許普通apk訪問/data目錄下內容的，通過data目錄的許可權設置可知，其他用戶沒有讀的許可權。
所以adb普通許可權下在data目錄下敲ls命令，會得到opendir failed, Permission denied的錯誤，通過代碼file.listfiles()也無法獲得data目錄下的內容。
上面兩種情況，一般都需要提升apk的許可權，目前我所知的apk能提升到的許可權就是system（具體方法見：如何使Android應用程序獲取系統許可權）,
D. 針對android 有哪些關於訪問訪問方面的許可權
Android是一個多進程系統，在這個系統中，應用程序（或者系統的部分）會在自己的進程中運行。系統和應用之間的安全性是通過Linux的facilities（工具，功能）在進程級別來強制實現的，比如會給應用程序分配user ID和Group ID。更細化的安全特性是通過"Permission"機制對特定的進程的特定的操作進行限制，而"per-URI permissions"可以對獲取特定數據的access專門許可權進行限制。
安全架構
Android安全架構中一個中心思想就是：應用程序在默認的情況下不可以執行任何對其他應用程序，系統或者用戶帶來負面影響的操作。這包括讀或寫用戶的私有數據（如聯系人數據或email數據），讀或寫另一個應用程序的文件，網路連接，保持設備處於非睡眠狀態。
一個應用程序的進程就是一個安全的沙盒。它不能幹擾其它應用程序，除非顯式地聲明了"permissions"，以便它能夠獲取基本沙盒所不具備的額外的能力。它請求的這些許可權"permissions"可以被各種各樣的操作處理，如自動允許該許可權或者通過用戶提示或者證書來禁止該許可權。應用程序需要的那些"permissions"是靜態的在程序中聲明，所以他們會在程序安裝時就被知曉，並不會再改變。
應用程序簽名
所有的Android應用程序（.apk文件）必須用證書進行簽名認證，而這個證書的私鑰是由開發者保有的。該證書可以用以識別應用程序的作者。該證書也不需要CA簽名認證（註：CA就是一個第三方的證書認證機構，如verisign等）。Android應用程序允許而且一般也都是使用self-signed證書（即自簽名證書）。證書是用於在應用程序之間建立信任關系，而不是用於控製程序是否可以安裝。簽名影響安全性的最重要的方式是通過決定誰可以進入基於簽名的permisssions，以及誰可以share 用戶IDs。
用戶IDs和文件存取
每一個Android應用程序（.apk文件）都會在安裝時就分配一個獨有的Linux用戶ID，這就為它建立了一個沙盒，使其不能與其他應用程序進行接觸（也不會讓其它應用程序接觸它）。這個用戶ID會在安裝時分配給它，並在該設備上一直保持同一個數值。
由於安全性限制措施是發生進程級，所以兩個package中的代碼不會運行在同一個進程當中，他們要作為不同的Linux用戶出現。我們可以通過使用AndroidManifest.xml文件中的manifest標簽中的sharedUserId屬性，來使不同的package共用同一個用戶ID。通過這種方式，這兩個package就會被認為是同一個應用程序，擁有同一個用戶ID（實際不一定），並且擁有同樣的文件存取許可權。注意：為了保持安全，只有當兩個應用程序被同一個簽名簽署的時候（並且請求了同一個sharedUserId）才會被分配同樣的用戶ID.
所有存儲在應用程序中的數據都會賦予一個屬性-該應用程序的用戶ID,這使得其他package無法訪問這些數據。當通過這些方法getSharedPreferences(String, int), openFileOutput(String, int), or openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory)來創建一個新文件時，你可以通過使用MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE標志位來設置是否允許其他package來訪問讀寫這個文件。當設置這些標志位時，該文件仍然屬於該應用程序，但是它的global read and/or write許可權已經被設置，使得它對於其他任何應用程序都是可見的。
Using Permissions 使用許可權
一個基本的Android程序通常是沒有任何permissions與之關聯的，這就是說它不能做任何擾亂用戶或破壞數據的勾當。那麼為了使用設備被保護的features，我們就必須在AndroidManifest.xml添加一個或多個<uses-permission> 標簽，用以聲明你的應用程序需要的permissions.
下面是個例子
For example, an application that needs to monitor incoming SMS messages would specify:
Xml代碼
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app.myapp" > <uses-permission android:name="android.permission.RECEIVE_SMS" /> ... </manifest>
應用程序安裝的時候，應用程序請求的permissions是通過package installer來批准獲取的。package installer是通過檢查該應用程序的簽名和/或用戶的交換結果來確定是否給予該程序request的許可權。在用戶使用過程中不會去檢查許可權，也就是說要麼在安裝的時候就批准該許可權，使其按照設計可以使用該許可權；要麼就不批准，這樣用戶也就根本無法使用該feature,也不會有任何提示告知用戶嘗試失敗。
很多時候, 一個permission failure會導致一個SecurityException被拋回該應用程序. 但是Android並不保證這種情況會處處發生。例如，當數據被deliver到每一個receiver的時候，sendBroadcast(Intent) 方法會去檢查permissions,在這個方法調用返回之後，你也不會收到任何exception。幾乎絕大多數情況，一個permission failure都會列印到log當中。
Android系統定義的許可權可以在Manifest.permission中找到。任何一個程序都可以定義並強制執行自己獨有的permissions，因此Manifest.permission中定義的permissions並不是一個完整的列表（即有肯能有自定義的permissions)。
一個特定的permission可能會在程序操作的很多地方都被強制實施：
當系統有來電的時候，用以阻止程序執行其它功能；
啟動一個activity的時候，會控制誰可以啟動你的Acitivity；
在發送和接收廣播的時候，去控制誰可以接收你的廣播或誰可以發送廣播給你；
當進入並操作一個content provider的時候；
當綁定或開始一個service的時候。
聲明和使用Permissions
為了實現你自己的permissions，你必須首先在AndroidManifest.xml文件中聲明該permissions.通常我們通過使用一到多個<permission> tag來進行聲明。
下面例子說明了一個應用程序它想控制誰才可以啟動它的Activity：
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" > <permissionandroid:name="com.me.app.myapp.permission.DEADLY_ACTIVITY" android:label="@string/permlab_deadlyActivity"android:description="@string/permdesc_deadlyActivity" android:permissionGroup="android.permission-group.COST_MONEY" android:protectionLevel="dangerous" /> ... </manifest>
這里<protectionLevel>屬性是需要聲明的（通常系統自有的permission都會有它對應的protection level，而我們自己定義的permission一般都需要定義protecdtion level， 若不去定義，則默認為normal）。通過聲明該屬性，我們就可以告知系統如何去通告用戶以及通告哪些內容，或者告知系統誰才可以擁有該permission。具體請參看鏈接的文檔。
這我多說兩句啊，這個protectionLevel分四個等級，分別是Normal, Dangerous, Signature, SignatureOrSystem,越往後安全等級越高。
這個<permissionGroup>屬性是可選項, 只是用於幫助系統顯示permissions給用戶（實際是告知系統該permission是屬於哪個permission group的）。你通常會選擇使用標準的system group來設定該屬性，或者用你自己定義的group（更為罕見）。通常使用一個已經存在的group會更合適，因為這樣UI顯示的時候會更簡單。
需要注意的是label和description都是需要為permission提供的。這些都是字元串資源，當用戶去看permission列表(android:label)或者某個permission的詳細信息(android:description)時，這些字元串資源就可以顯示給用戶。label應當盡量簡短，之需要告知用戶該permission是在保護什麼功能就行。而description可以用於具體描述獲取該permission的程序可以做哪些事情，實際上讓用戶可以知道如果他們同意程序獲取該許可權的話，該程序可以做什麼。我們通常用兩句話來描述permission，第一句描述該permission，第二句警告用戶如果批准該許可權會可能有什麼不好的事情發生。下面是一個描述CALL_PHONE permission的label和description的例子：
<string name="permlab_callPhone">directly call phone numbers</string> <string name="permdesc_callPhone">Allows the application to call phone numbers without your intervention. Malicious applications may cause unexpected calls on your phone bill. Note that this does not allow the application to call emergency numbers.</string>
你可以通過shell指令 adb shell pm list permissions 來查看目前系統已有的permissions. 特別的，"-s"選項會以一種用戶會看到的格式一樣的格式來顯示這些permissions.
在AndroidManifest.xml中強制使用Permissions
通過AP的AndroidManifest.xml文件可以設置該AP中各個組件的訪問許可權，包括Activity，
Service，BroadcastReceiver，ContentProvider。這些組件中都包含android:permission屬性，設置這個屬性就可以控制訪問該組件的許可權。
Activity permissions許可權限制了誰才可以啟動相應的activity。Permission會在Context.startActivity()和Activity.startActivityForResult()的時候進行檢查，如果caller沒有所需的許可權，則會拋出一個SecurityException。
Service permissions用於限制誰才可以start或bind該service。在Context.startService() , Context.stopService() 和 Context.bindService() 調用的時候會進行許可權檢查。如果caller沒有所需的許可權，則會拋出一個SecurityException。
BroadcastReceiver permissions用於限制誰才可以向該receiver發送廣播。許可權檢查會在Context.sendBroadcast() 返回時進行，由系統去發送已經提交的廣播給相應的Receiver。最終，一個permission failure不會再返回給Caller一個exception；它只是不會去deliver該Intent而已。同樣地，Context.registerReceiver() 也可以有自己permission用於限制誰才可以向一個在程序中注冊的receiver發送廣播。另一種方式是，一個permission也可以提供給Context.sendBroadcast() 用以限制哪一個BroadcastReceiver才可以接收該廣播。
ContentProvider permission用於限制誰才可以訪問ContentProvider提供的數據。（Content providers有一套另外的安全機制叫做URI permissions，這些在稍後討論）不同於其它的Components，這里有兩種不同的permission屬性可以設置: android:readPermission 用於限制誰可以讀取provider中的數據，而 android:writePermission 用於限制誰才可以向provider中寫入數據。需要注意的是如果provider既被read permission保護，也被write permission保護的話，如果這時只有write permission並不意味著你就可以讀取provider中的數據了。當你第一次獲取provider的時候就要進行許可權檢查（如果你沒有任何permission，則會拋出SecurityException）。當使用ContentResolver.query() 時需要讀許可權，而當使用 ContentResolver.insert() , ContentResolver.update() , ContentResolver.delete() 時需要寫許可權。在所有這些情況下，沒有所需的permission將會導致SecurityException被拋出。
在Sending Broadcasts時強制使用Permissions
除了之前說過的Permission（用於限制誰才可以發送廣播給相應的broadcastReceiver），你還可以在發送廣播的時候指定一個permission。在調用Context.sendBroadcast() 的時候使用一個permission string，你就可以要求receiver的宿主程序必須有相應的permission。值得注意的是Receiver和broadcaster都可以要求permission。當這種情況發生時，這兩種permission檢查都需要通過後才會將相應的intent發送給相關的目的地。
其它強制使用Permissions的方式
在調用service的過程中可以設置任意的fine-grained permissions（這里我理解的是更為細化的許可權）。這是通過Context.checkCallingPermission(String) 方法來完成的。呼叫的時候使用一個想得到的permission string，並且當該許可權獲批的時候可以返回給呼叫方一個Integer（沒有獲批也會返回一個Integer）。需要注意的是這種情況只能發生在來自另一個進程的呼叫，通常是一個service發布的IDL介面或者是其他方式提供給其他的進程。
Android提供了很多其他的方式用於檢查permissions。如果你有另一個進程的pid，你就可以通過context method Context.checkPermission(String, int, int) 去針對那個pid去檢查permission。如果你有另一個應用程序的package name，你可以直接用PackageManager method PackageManager.checkPermission(String, String) 來確定該package是否已經擁有了相應的許可權。
URI Permissions
到目前為止我們討論的標準的permission系統對於content provider來說是不夠的。一個content provider可能想保護它的讀寫許可權，而同時與它對應的直屬客戶端也需要將特定的URI傳遞給其它應用程序，以便其它應用程序對該URI進行操作。一個典型的例子就是郵件程序處理帶有附件的郵件。進入郵件需要使用permission來保護，因為這些是敏感的用戶數據。然而，如果有一個指向圖片附件的URI需要傳遞給圖片瀏覽器，那個圖片瀏覽器是不會有訪問附件的權利的，因為他不可能擁有所有的郵件的訪問許可權。
針對這個問題的解決方案就是per-URI permission: 當啟動一個activity或者給一個activity返回結果的時候，呼叫方可以設置Intent.FLAG_GRANT_READ_URI_PERMISSION 和/或 Intent.FLAG_GRANT_WRITE_URI_PERMISSION . 這會使接收該intent的activity獲取到進入該Intent指定的URI的許可權，而不論它是否有許可權進入該intent對應的content provider。
這種機制允許一個通常的capability-style模型， 這種模型是以用戶交互（如打開一個附件, 從列表中選擇一個聯系人）為驅動，特別獲取更細粒化的許可權。這是一種減少不必要許可權的重要方式，這種方式主要針對的就是那些和程序的行為直接相關的許可權。
這些URI permission的獲取需要content provider（包含那些URI）的配合。強烈推薦在content provider中提供這種能力，並通過android:grantUriPermissions 或者<grant-uri-permissions> 標簽來聲明支持。
更多的信息可以參考Context.grantUriPermission() , Context.revokeUriPermission() , and Context.checkUriPermission() methods.
轉載
E. android安全沙箱機制是基於什麼
Android順其自然地繼承了Linux內核的安全機制，同時結合移動終端的具體應用特點，進行了許多有益的改進與提升。
window與unix/linux等傳統操作系統以用戶為中心，假設用戶之間是不可信的，更多考慮如何隔離不同用戶對資源（存儲區域與用戶文件，內存區域與用戶進程，底層設備等）的訪問。在Android系統中，假設應用軟體之間是不可信的，甚至用戶自行安裝的應用程序也是不可信的，因此，首先需要限制應用程序的功能，也就是將應用程序置於「沙箱」之內，實現應用程序之間的隔離，並且設定允許或拒絕API調用的許可權，控制應用程序對資源的訪問，如訪問文件，目錄，網路，感測器等。
Android擴展了Linux內核安全模型的用戶與許可權機制，將多用戶操作系統的用戶隔離機制巧妙地移植為應用程序隔離。在linux中，一個用戶標識（UID）識別一個給定用戶；在Android上，一個UID則識別一個應用程序。在安裝應用程序時向其分配UID。應用程序在設備上存續期間內，其UID保持不變。僅限用於允許或限制應用程序（而非用戶）對設備資源的訪問。如此，Android的安全機制與Linux內核的安全模型完美銜接！不同的應用程序分別屬於不同的用戶，因此，應用程序運行於自己獨立的進程空間，與UID不同的應用程序自然形成資源隔離，如此便形成了一個操作系統級別的應用程序「沙箱」。
應用程序進程之間，應用程序與操作系統之間的安全性由Linux操作系統的標准進程級安全機制實現。在默認狀態下，應用程序之間無法交互，運行在進程沙箱內的應用程序沒有被分配許可權，無法訪問系統或資源。因此，無論是直接運行於操作系統之上的應用程序，還是運行於Dalvik虛擬機的應用程序都得到同樣的安全隔離與保護，被限制在各自「沙箱」內的應用程序互不幹擾，對系統與其他應用程序的損害可降至最低。Android應用程序的「沙箱」機制如下圖，互相不具備信任關系的應用程序相互隔離，獨自運行：
在很多情況下，源自同一開發者或同一開發機構的應用程序，相互間存在信任關系。Android系統提供一種所謂共享UID（SharedUserID）機制，使具備信任關系的應用程序可以運行於同一進程空間。通常 ，這種信任關系由應用程序的數字簽名確定，並且需要應用程序在manifest文件中使用相同的UID。共享UID的應用程序進程空間