android運行時許可權

❶ Android 的許可權管理是怎麼實現的

根據用戶的使用過程體驗，可以將 Android 涉及的許可權大致分為如下三類：

（1）Android 手機所有者許可權：自用戶購買 Android 手機後，用戶不需要輸入任何密碼，就具有安裝一般應用軟體、使用應用程序等的許可權；

（2）Android root 許可權：該許可權為 Android 系統的最高許可權，可以對所有系統中文件、數據進行任意操作。出廠時默認沒有該許可權，需要使用 z4Root 等軟體進行獲取，然而，並不鼓勵進行此操作，因為可能由此使用戶失去手機原廠保修的權益。同樣，如果將 Android 手機進行 root 許可權提升，則此後用戶不需要輸入任何密碼，都將能以 Android root 許可權來使用手機。

（3）Android 應用程序許可權：Android 提供了豐富的 SDK（Software development kit），開發人員可以根據其開發 Android 中的應用程序。而應用程序對 Android 系統資源的訪問需要有相應的訪問許可權，這個許可權就稱為 Android 應用程序許可權，它在應用程序設計時設定，在 Android 系統中初次安裝時即生效。值得注意的是：如果應用程序設計的許可權大於 Android 手機所有者許可權，則該應用程序無法運行。如：沒有獲取 Android root 許可權的手機無法運行 Root Explorer，因為運行該應用程序需要 Android root 許可權。

Android 系統許可權定義

Android 系統在 /system/core/private/android_filesystem_config.h 頭文件中對 Android 用戶 / 用戶組作了如下定義，且許可權均基於該用戶 / 用戶組設置。

在 Android 系統中，上述用戶 / 用戶組對文件的訪問遵循 linux 系統的訪問控制原則，即根據長度為 10 個字元的許可權控制符來決定用戶 / 用戶組對文件的訪問許可權。該控制符的格式遵循下列規則：

第 1 個字元：表示一種特殊的文件類型。其中字元可為 d( 表示該文件是一個目錄 )、b( 表示該文件是一個系統設備，使用塊輸入 / 輸出與外界交互，通常為一個磁碟 )、c( 表示該文件是一個系統設備，使用連續的字元輸入 / 輸出與外界交互，如串口和聲音設備 )，「.」表示該文件是一個普通文件，沒有特殊屬性。

2 ～ 4 個字元：用來確定文件的用戶 (user) 許可權；

5 ～ 7 個字元：用來確定文件的組 (group) 許可權；

8 ～ 10 個字元：用來確定文件的其它用戶 (other user，既不是文件所有者，也不是組成員的用戶 ) 的許可權。

第 2、5、8 個字元是用來控制文件的讀許可權的，該位字元為 r 表示允許用戶、組成員或其它人可從該文件中讀取數據。短線「-」則表示不允許該成員讀取數據。

第 3、6、9 位的字元控制文件的寫許可權，該位若為 w 表示允許寫，若為「-」表示不允許寫。

第 4、7、10 位的字元用來控制文件的製造許可權，該位若為 x 表示允許執行，若為「-」表示不允許執行。

舉個例子，「drwxrwxr--2 rootroot40962 月 11 10:36 lu」表示的訪問控制許可權（黑色字體標明）為：因為 lu 的第 1 個位置的字元是 d，所以由此知道 lu 是一個目錄。第 2 至 4 位置上的屬性是 rwx，表示用戶 root 擁有許可權列表顯示 lu 中所有的文件、創建新文件或者刪除 lu 中現有的文件，或者將 lu 作為當前工作目錄。第 5 至 7 個位置上的許可權是 rwx，表示 root 組的成員擁有和 root 一樣的許可權。第 8 至 10 位上的許可權僅是 r--，表示不是 root 的用戶及不屬於 root 組的成員只有對 lu 目錄列表的許可權。這些用戶不能創建或者刪除 lu 中的文件、執行 junk 中的可執行文件，或者將 junk 作為他們的當前工作目錄。

Android 應用程序許可權申請

每個應用程序的 APK 包裡面都包含有一個 AndroidMainifest.xml 文件，該文件除了羅列應用程序運行時庫、運行依賴關系等之外，還會詳細地羅列出該應用程序所需的系統訪問。程序員在進行應用軟體開發時，需要通過設置該文件的 uses-permission 欄位來顯式地向 Android 系統申請訪問許可權。

❷ Android 13 適配指南

2022 的Google I/O 發布了 Android 13 beta 2 和 Android 13 Beta 1 國內廠商的設備支持列表，雖然按照慣例， Android 13 應該是年末才發布正式版，但是相信有的開發者已經收到了平台的 Android13 的適配要求，所以本篇也是結合 Oppo 的 Android 13 應用兼容性適配指導 和官方提供的一些文檔內容做一個整理測試。

目前 Android 13 主要的兼容問題還是在於隱私許可權上，所以本次的適配指南相關內容也是著重在這一部分， 這里涉及面比較廣的應該就是相冊和通知許可權 。

這個動圖大家可能看到過， 這是 Android 13 上提供的系統圖片選擇器，通過 Intent(MediaStore.ACTION_PICK_IMAGES); 就可以打開，支持視頻、音頻、圖片分類，支持多選和單選 ，另外官方也表示過，這個特性不僅僅會在 Android 13 中出現，谷歌還會將其放置到 Play 商店中，向 Android 11 和 Android 12 設備推送。

我們通過調整 TargetSDK 設置為 PreView ，然後運行到 Tiramisu 的模擬器上進行測試，主要測試 TargetSDK 在低於 "Tiramisu" 和等於 "Tiramisu" 時的不同情況。

如下圖所示：

總結： 所以如果是 TargetSDK 在 Android 13 以下，不需要處理，如果在 Android 13 以及以上 ，需要增加申請許可權 。

在 Android R 上設置里開始支持在設置里對應用的通知許可權進行管理，但是應用自身是無法修改應用級別的通知許可權，所以 App 無法知道自身有沒有發送通知的許可權

所以在 Android 13 里增加了通知的運行時許可權 ，其中 Android 13 (33) 的通知會根據正在運行的應用程序的目標 API 級別進行不同的處理， 不過不管應用程序的目標API級別如何，Android 13 都會提示用戶授予應用程序發送通知的許可權 。

例如下圖，是 targetSdk 30 運行在 Android 13 模擬器上，依然會彈出讓用戶是否允許推送 。

當然，系統也會根據應用程序的目標 API 級別處理通知訪問:

如果是 現有應用更新 ，程序的目標 API 級別為：

最後測試和總結一下：

由於 Android 之前可以通過跟蹤附近的 Wi-Fi AP 和藍牙設備來推斷設備的位置，所以這次谷歌決定禁止應用程序 訪問藍牙 結果，除非這類應用需要聲明 ACCESS_FINE_LOCATION 許可權。

在 Android 13 中，Google 將 Wi-Fi 掃描與位置相關內容分離， Android 13 為管理設備與周圍 Wi-Fi 熱點連接的應用添加 NEARBY_WIFI_DEVICES 運行時許可權 (屬於 NEARBY_DEVICES 許可權組)，從而在不需要 ACCESS_FINE_LOCATION 許可權的情況下，也可以讓應用訪問附近的 Wi-Fi 設備。

此前，對於僅需要連接 Wi-Fi 設備，但實際上並不需要了解設備位置的應用來說，以 Android 13 (33)為目標平台的應用現在可以通過 「 neverForLocation 」 屬性來完善申請 NEARBY_WIFI_DEVICES 許可權。

這項新許可權會影響幾個不同的 Wi-Fi 用例，包括以下用例：

所以開發需要區分不同api對應的許可權；

由於 NEARBY_WIFI_DEVICES 許可權僅適用於 Android 13 或更高版本， 如果是 Android12L(32) 以及以下的 App 應保留對 ACCESS_FINE_LOCATION 的所有聲明：

以 Android 13(33) 為目標平台時，如果應用不會通過 Wi-Fi API 推導物理位置，請在清單文件中將 usesPermissionFlags 屬性設為 neverForLocation。

所以總結： 以 Android 13(33) 為目標平台的應用程序，訪問附近的 WI-FI 設備。除特例API需要申請ACCESS_FINE_LOCATION外，其他需要申請 android.permission.NEARBY_WIFI_DEVICES 運行時許可權 ；

Android 13 中引入了 「在使用時」 訪問身體感測器（例如心率、體溫和血氧飽和度）的概念，此訪問模式與 Android 10（API 級別 29）系統為位置信息 引入的模式非常相似。

如果你的 App 以 Android 13(33) 為目標平台，並且在後台運行時需要訪問身體感測器信息，那麼除了現有的 BODY_SENSORS 許可權外，還必須聲明新的 BODY_SENSORS_BACKGROUND 許可權 。

當 App 以 Android 13(33) 或更高版本為 Target 的其他應用的導出組件發送 intent 時，僅當該 intent 與接收應用中的 <intent-filter> 元素匹配時，系統才會傳送該 intent，換言之系統會屏蔽所有不匹配的 intent，但以下情況除外：

為了幫助提高運行時接收器的安全性，Android 13 允許你指定 App 中的特定廣播接收器是否應被導出以及是否對設備上的其他應用可見，此變更是 Android 12 更安全的組件 的延續；

以 Android 13(33) 或更高版本為目標平台的應用，必須為每個廣播接收器指定 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED ，否則當 App 嘗試注冊廣播接收器時，系統會拋出 SecurityException

在 Android 13中，谷歌添加了一個新的API，允許開發者降級許可權。

應用程序可以觸發撤銷授予調用 API 的包的一個或多個運行時許可權，不需要訪問特定運行時許可權控制 API 的應用程序可以自行撤銷這些許可權，這樣用戶就可以確保這些應用程序不會在不知情的情況下使用這些API。

如需撤消特定運行時許可權，請將該許可權的名稱傳入 revokeOwnPermissionOnKill() 方法，如需同時撤消一組運行時許可權，請將這組許可權的名稱傳入 revokeOwnPermissionsOnKill() 。

系統只有在安全的情況下才會觸發撤消操作，也就是當有應用組件仍在前台運行，或者有另一個應用正在訪問你應用的組件（如 content provider）時不會發生撤消。

Android 之前一直提供了一個剪貼板服務，所有 App 都可以使用它來放置和檢索文本。

盡管從技術上講，任何應用都可以清除全局剪貼板中的主內容（只要它們是前台應用或 Android 10+ 上的默認輸入法），但 Android 本身不會自動清除剪貼板。

這意味著任何留在全局剪貼板中的剪貼板內容，都可以在以後被應用程序讀取，盡管 Android 的剪貼板訪問有 toast 消息可能會提醒用戶。

Android 13 增加了剪貼板自動清除功能，此功能在默認情況下處於禁用狀態，在經過設定的時間後，將自動從全局剪貼板中清除主剪輯， 默認情況下經過3600000毫秒（60分鍾）後，剪貼板將被清除。

每次執行復制/讀取（寫入剪貼板 setPrimaryClip ，讀 getPrimaryClip ）時，會重置一個消息 timeout（60min），之後會自動清除剪貼板內存中的內容，即60min內，如果一直沒有寫入剪貼板的操作，剪貼板的內容會被自動清除。

Android 13 的新前台服務（ Foreground Services：FGS）任務管理器顯示當前運行前台服務的應用程序列表，此列表稱為活動應用程序，可以通過下拉通知抽屜並點擊啟示來訪問，這時候每個應用程序旁邊都會有一個「停止」按鈕。

利用 JobScheler，應用可使用 JobInfo.Builder.setPrefetch() 將特定作業標記為「預提取」，這意味著理想情況下這些作業應該在應用下一次啟動前提前一點運行，以提升用戶體驗。

過去，JobScheler 僅使用該信號讓預提取作業有機會使用免費或多餘的數據，在 Android 13 中系統現在會嘗試確定應用下次啟動的時間，並根據該估算值運行預提取作業，應用應嘗試使用「預提取」來完成他們想要在下次應用啟動前完成的任何工作。

Android 13 中引入了 電池資源利用率 功能，以便為系統提供多種方法來更好地管理設備電池續航時間：

❸ android6.0中哪些許可權申請被提高需要用戶運行時授權

android6.0系統許可權也被分成normal和dangerous兩類：

1、Normal類的許可權不會直接涉及到用戶隱私風險。如果APP在Manifest文件中聲明了Normal類的許可權，系統會自動授予這些許可權。

2、Dangerous類的許可權可能會讓APP涉及到用戶機密的數據。如果APP在Manifest文件中聲明了Normal類的許可權，系統會自動授予這些許可權。如果在Manifest文件中添加了Dangerous類的許可權，用戶必須明確的授予對應的許可權後APP才具有這些許可權。更具體的分類，參考下圖：

❹ Android程序運行時許可權與文件系統許可權的區別

運行時許可權是Dalvik授權
文件系統許可權是 linux 內核授權

❺ 怎麼控制安卓應用的許可權(2)

於是，不少開發者就搗鼓出了「第三條道路」；可惜的是，沒有一種方法能同時做到既不需要將手機固件Root，又完全不涉及對原始應用程序進行反向工程的方法。 Root Root指獲得Android所在的Linux系統的Root（根）許可權，有了根許可權，你才能對Linux做出任意的修改。iOS中的越獄 （Jailbreak） 相當於獲得iOS系統的Root許可權（iOS是一種類Unix系統，和Linux都使用Root的概念）。在已Root的設備中，通常都是使用一個 叫「Superuser」（簡稱SU）的應用程序來向許可的程序授以Root許可權。 Bootloader的解鎖（Unlock） 利用數字簽名，Bootloader可以限定只有正確簽名的系統可以被引導。在修改固件以獲得Root以前，解鎖Bootloader通常是必須的。安裝第三方修改、編譯的固件也需要解鎖Bootloader。 基帶（Radio）解鎖 在Android系統中，基帶是上層軟體與手機中無線設備（手機網路，Wi-Fi，藍牙等）的驅動程序之間的中介。國外的網路運營商很喜歡鎖定 基帶，從 而保證用戶只能使用運營商自己指定的sim卡。在我國，鎖定基帶是非法的，手機製造商、網路運營商也不可以通過鎖定基帶的方法對待違約客戶。iOS的「解 鎖」就是解鎖iOS中的基帶軟體。 為什麼要控制Android許可權 魚和熊掌不可兼得，Android的世界有很多自由，壞人也能自由地做壞事。它的生態系統很強調自主：用戶可以自主地減小風險，僅使用官方市場的應用程序，也可以自主地解除安全限制，從而獲得更多自由。因此，在遇到壞事的時候，用戶也不得不自主一下： 1， 抵制不道德，乃至非法行為 幾乎所有的Android安全軟體都能對來電、信息進行控制，以減少騷擾。 另一方面，很多應用都會要求它們實際功能以外的許可權，表現在非（主動）告知地搜集設備序列號，位置信息，誘使用戶默認地上傳聯系人列表等方面。 更壞一點的應用程序，則會踏入犯罪的范疇，比如能偷偷發出扣費信息，或是作為黑客的偷窺工具。 2， 減少惡意軟體的損害 惡意軟體即便潛伏成功，也難以獲得許可權，從而減少損失。 3， 用戶有權自主地在抑制應用程序的部分許可權時，繼續使用該應用程序，而只承擔由於自行設置不當而帶來的後果。 用戶擁有設備的所有權，因此有權自主控制設備上的內容、感測器等對象的訪問；同時有權（不）運行，（不）編譯設備上的應用程序。 大多數應用程序在運行時，並未達成主動告知的義務，是失誤；然而即使主動告知，用戶還是可以不理會。 為什麼Android官方市場的強制提醒許可權的行為不屬於主動告知： 通過Android官方市場，「打包安裝器」安裝應用程序時，所顯示的「許可權」僅是在安裝包內AndroidManifest.xml聲明的 值，而非應 用程序實際上會調用的內容。該值僅用來表明Android系統能向應用授予的最大可能的許可權。即便一個「Hello World」式的應用程序，也可以在AndroidManifest.xml中聲明所有可能的Android Permission。 這就是說，在AndroidManifest.xml中聲明的值與應用程序實際調用的許可權有關聯，但不等同，且這種提示是由Android系統負責實施的強制行為。 正確的理解是：「應用程序（被迫地）讓Android系統告知用戶，它在AndroidManifest.xml中所聲明的事項。」 這意味著應用程序在使用重要許可權前，依然需要自行、主動地通知用戶相關事宜。圖6 應用程序須要AndroidManifest.xml中聲明調用到的許可權 然而，即便只是讓一半的應用程序達到以上的標准，也是不可能的。應用程序需要通過收集用戶信息，程序的錯誤日誌。從而統計用戶的喜好，改進程 序。另一方 面，這也是發送精確廣告但不追溯到用戶身份信息的方式，這一點對於免費應用而言，是極其重要的。我們之所以能知道不同型號手機的佔有率，應用軟體的流行 度，是與這樣的統計不可分離的。 一旦每個應用程序都專業地主動發出提醒，不專業的用戶（大多數用戶都是不專業的）通常會將之視為如同海嘯警報一般的危機。 這么做對誰都沒有好處------用戶方的隱私權是毋庸置疑的，然而應用程序方面的獲取信息記錄的需求也是無可阻擋的。如果每個用戶都打算阻止，只會落得被迫接受不平等條約的下場，在溫飽以前，不會有人考慮小康的問題。 於是，現狀就變得有趣：用戶人享受著相同的服務；其中大部分用戶出於不知情/好意，默默地向開發者、廣告商提供了信息，剩下的少數用戶則能阻斷這種勞務。而作為維持Android平台的信息商人Google，只確保在它的地盤里，不會發生觸碰底線的事情。 一句話總結： 設備是我的，不管你怎麼說，反正我說了算，但我說的話大多是不算數的。 3 許可權控制的方法 這里開始介紹各種控制Android許可權的辦法。可惜的是，幾乎所有的手段都需要對設備進行Root，如果不這么做，則需要付出不小代價。 App Shield（國內常見的名字：許可權修改器） 它是一個需要付費的Android應用，其原理是修改應用程序的apk安裝包，刪除其中AndroidManifest.xml文件內，用於聲 明許可權的 對應「Android.Permission.*」條目，然後再用一個公開的證書對安裝包重新簽名（需要允許「未知源」），這樣一來，應用程序就不會向系 統申請原先所需的許可權。當應用運行至相應的流程時，系統將直接拒絕，從而達到用戶控制許可權的目的。 對於已安裝的應用，AppShield也會按照同樣方法製作好apk安裝包，然後讓用戶先卸載原始的應用，再安裝調整過的應用。除了該應用數字簽名外，用戶可以隨時通過執行同樣的流程，將吊銷的許可權恢復。圖7 AppShield Apk文件的結構 Android應用都是打包成以.apk擴展名結尾，實際上是zip的文件格式。 一個合法的apk至少需要這些成分： 根目錄下的「AndroidManifest.xml」文件，用以向Android系統聲明所需Android許可權等運行應用所需的條件。 根目錄下的classes.dex（dex指Dalvik Exceptionable），應用（application）本身的可執行文件（Dalvik位元組碼） 。 根目錄下的res目錄，包含應用的界面設定。（如果僅是一個後台執行的「service」對象，則不必需） Apk根目錄下的META-INF目錄也是必須的，它用以存放應用作者的公鑰證書與應用的數字簽名。 當應用被安裝後，這個apk文件會原封不動地移至設備的data/app目錄下，實際運行的，則是Dalvik將其中Classes.dex進 行編譯後 的Classes.odex（存放在Dalvik緩存中，刷機時的『cache wipe就是清除Dalvik的odex文件緩存』）。 優點： 完全不需要Root，適用於所有版本的Android設備。不會損壞系統，可以吊銷任意一項Android許可權。 問題： 1，需要重新安裝應用，該行為可能會丟失應用的配置、歷史記錄。 2，執行許可權吊銷的應用的數字簽名會被更改，無法直接更新。對於那些設計不良（沒有意料到『不聲明許可權』情況的），或有額外自校驗的應用，可能會無法運行。 3，無法用於設備上的預裝應用，除非製造商好心地將該應用設置為「可以刪除」的狀態。 4，這個方法修改了apk包中的內容------盡管實際上AndroidManifest.xml和數字簽名並不算是應用程序的本身，但修改它們可能引發著作權的問題。 5，需要開啟「未知源」。 6，這是一個收費應用。 CyanogenMod 7.1（及以上版本） Cyanogenmod是一款著名的第三方編寫的開源Android ROM。 CM7.1加入了控制許可權的開關，官方的名稱是「Permission Revoking」，任何非系統/保護應用在安裝後，可直接吊銷任意一項許可權，其效果等價於直接刪除apk包中AndroidManifest.xml的 對應條目，但不會引發自校驗的問題。CM的許可權工具的作用等同於AppShield，無非是在Android自身的許可權系統中添加了一個開關。

❻ android6.0 許可權管理有哪些

Android 6.0的許可權管理

6.0的設備會分兩種許可權：

常規許可權

只需要在xml中申明，用戶不會彈出任何讓其選擇是否開啟許可權的彈窗，即靜默許可權。

包括：網路訪問，獲取網路狀態等

注意：常規許可權，必須要在xml中申明

❼ android應用系統許可權問題

/**
* 廣播接收者. 去申請管理員許可權. 這個廣播接收者需要在清單文件中做一些特殊的配置
*
* <receiver android:name=".MyPolicyReceiver" 你的廣播接收者的名字
* android:description="@string/app_name" 給用戶的描述
* android:label="@string/app_name" 設備管理器中顯示的應用標題名
* android:permission="android.permission.BIND_DEVICE_ADMIN"> 需要申請的許可權
* <meta-data
* android:name="android.app.device_admin"
* android:resource="@xml/policy"/> policy.xml中為所聲明的設備管理員許可權
*
* <intent-filter >
* <action
* android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> 監聽改頻段的廣播
* </intent-filter>
* </receiver>
*
* @author
*

❽ android開發 彈出許可權提示框 檢查是否具有

android運行時許可權:

java">intresult=ActivityCompat.checkSelfPermission(this,Manifest.permission.WRITE_EXTERNAL_STORAGE);
if(result!=PackageManager.PERMISSION_GRANTED){
//沒有寫磁碟許可權，申請
ActivityCompat.requestPermissions(this,newString[]{Manifest.permission.WRITE_EXTERNAL_STORAGE},0);
}
//申請許可權的回調
@Override
(intrequestCode,@NonNullString[]permissions,@NonNullint[]grantResults){
switch(requestCode){
case0:
if(grantResults[0]==PackageManager.PERMISSION_GRANTED){
//用戶授權
}else{
//用戶拒絕
Toast.makeText(this,"你殘忍的拒絕了我",Toast.LENGTH_SHORT).show();
}
break;
}

❾ Android的許可權都有哪些

（一）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目錄下的內容。

❿ android許可權機制，你真的了解么

區分apk運行時的擁有的許可權與在文件系統上被訪問（讀寫執行）的許可權兩個概念。 apk程序是運行在虛擬機上的,對應的是Android獨特的許可權機制，只有體現到文件系統上時才使用linux的許可權設置。 （一）linux文件系統上的許可權 -rwxr-x--x system system 4156 2010-04-30 16:13 test/hpyfei/blog/item/a2730122c1cac7eed6cae260.html