android許可權框架

❶ 如何管理安卓許可權：Xposed框架+X隱私模塊

supersu用來管理root許可權，我的理解僅此而已，請大神指點指點。xposed框架是安卓手機之魂，無XP，不安卓

❷ android 6.0動態許可權寫在第一個activity中就行了嗎

不是的，要在申請許可權的過程中。

❸ Android有哪些"許可權"

Android是在linux內核上建立一個硬體抽象層(Android HAL)，通過Dalvik以及各種庫來執行android應用的。在手機啟動時，首先需要由Bootloader(HTC手機上稱作Hboot)引導Linux及手機上各個硬體設備的驅動程序，之後才啟動Android系統。所以其實我們會涉及到四種不同涵義的許可權：
Android許可權(Permission)
這指Android中的一系列"Android.Permission.*"對象，是本文的中心內容。
Google在Android框架內把各種對象(包括設備上的各類數據，感測器，撥打電話，發送信息，控制別的應用程序等)的訪問許可權進行了詳細的劃分，列出了約一百條"Android.Permission"。應用程序在運行前必須向Android系統聲明它將會用到的許可權，否則Android將會拒絕該應用程序訪問通過該"Permission"許可的內容。
比方說，搜狗輸入法提供了一個智能通訊錄的功能，用戶可以在輸入聯系人拼音的前幾個字元，或首字母，輸入法就能自動呈現相關聯系人的名字。為了實現這個功能，輸入法必須聲明它需要讀取手機中聯系人的能力，也就是在相關代碼中加上聲明"android.permission.READ_CONTACTS"對象。
圖5 搜狗輸入法的智能聯系人功能
原生Android只提供了對"一刀切"式的管理，要麼同意使用，否則就根本就不安裝應用程序。當用戶遇到希望使用程序的同時，又想禁止部分Permission的場合，他就無路可走。
於是，不少開發者就搗鼓出了"第三條道路"；可惜的是，沒有一種方法能同時做到既不需要將手機固件Root，又完全不涉及對原始應用程序進行反向工程的方法。
RootRoot指獲得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的世界有很多自由，壞人也能自由地做壞事。它的生態系統很強調自主：用戶可以自主地減小風險，僅使用官方市場的應用程序，也可以自主地解除安全限制，從而獲得更多自由。因此，在遇到壞事的時候，用戶也不得不自主一下：
1， 抵制不道德，乃至非法行為
幾乎所有的Android安全軟體都能對來電、信息進行控制，以減少騷擾。
另一方面，很多應用都會要求它們實際功能以外的許可權，表現在非(主動)告知地搜集設備序列號，位置信息，誘使用戶默認地上傳聯系人列表等方面。
更壞一點的應用程序，則會踏入犯罪的范疇，比如能偷偷發出扣費信息，或是作為黑客的偷窺工具。
2， 減少惡意軟體的損害
惡意軟體即便潛伏成功，也難以獲得許可權，從而減少損失。
3， 用戶有權自主地在抑制應用程序的部分許可權時，繼續使用該應用程序，而只承擔由於自行設置不當而帶來的後果。
用戶擁有設備的所有權，因此有權自主控制設備上的內容、感測器等對象的訪問；同時有權(不)運行，(不)編譯設備上的應用程序。
大多數應用程序在運行時，並未達成主動告知的義務，是失誤；然而即使主動告知，用戶還是可以不理會。
通過Android官方市場，"打包安裝器"安裝應用程序時，所顯示的"許可權"僅是在安裝包內AndroidManifest.xml聲明的值，而非應用程序實際上會調用的內容。該值僅用來表明Android系統能向應用授予的最大可能的許可權。即便一個"Hello World"式的應用程序，也可以在AndroidManifest.xml中聲明所有可能的Android Permission。
這就是說，在AndroidManifest.xml中聲明的值與應用程序實際調用的許可權有關聯，但不等同，且這種提示是由Android系統負責實施的強制行為。
正確的理解是："應用程序(被迫地)讓Android系統告知用戶，它在AndroidManifest.xml中所聲明的事項。"
這意味著應用程序在使用重要許可權前，依然需要自行、主動地通知用戶相關事宜。

❹ Android6.0的sd卡許可權怎麼搞

安卓6.0加入了更嚴格得許可權驗證，SD卡讀寫許可權是這樣得
1. 在AndroidManifest.xml添加<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

2. 現在大應用一般都匯集成進去許可權框架，這樣在你讀寫SD卡得時候判斷有沒有許可權，有的話執行，沒有的話彈出添加許可權對話框點擊確定添加許可權。
3.現在許可權框架比較多有EasyPermission，PermissionGen 和 MPermissions。
4.EasyPermission修改了一個框架library,可直接使用

❺ 如何管理android手機中app的許可權

1、（以魅族手機為例）打開手機設置選項。

❻ 如何限制安卓app許可權

控制許可權當然首推Xposed框架中的XPrivacy

根據我自己歸納，控制許可權的方式大致分為以下幾種:

0. AppOps. 4.3以上系統的原生許可權控制。但是目前官方的Android系統還未開放這項功能，需要自己找工具開啟。(應該是一個Xposed下的工具，所以不如直接用XPrivacy)即使開啟後能控制的范圍也比較有限。

1. 第三方應用。也就是LBE、360這一類XX手機助手，它們的使用門檻最低，但是缺點在於提供的選項比較單一、效率較低在舊機子上明顯卡頓、而且這些軟體發行者本身的可信任程度值得商榷。

2. 強行吊銷應用許可權。包括修改apk文件和CM系統自帶的許可權管理。效率最高，但是有些應用不吃這套，修改後直接閃退，估計是在啟動時會先檢查許可權的完整性(鄙視之)。

3. 也就是這里推薦的 XPrivacy. 基於Xposed框架，直接從虛擬機層面進行操作，具體的原理我不太清楚，但可以肯定效率高於第一類應用。更大的好處在於極為豐富具體的選項，精確控制每一項許可權，還可以用偽造數據等方法確保應用穩定運行。最重要的是完全開源，安全性更高。但有一定的使用門檻，建議至少對Android有基本的了解再使用。

❼ 安卓6.0的SD卡許可權怎麼破

沒有ROOT的情況下，參照MIUI系統，在設置裡面找到「全部應用」，找到「文檔」（或者相近的名詞），點擊打開後標注為「啟用」或者「使用」，重啟。那麼可以使用SD卡的app都可以讀寫SD卡，如某某導航的離線據包可以放在SD卡，拇指玩、當樂下載的APK都可以放在SD卡，小雞、啪啪模擬器下載的ROM都可以放在SD卡等等。如果APP本身定製只能放在內置存儲不能轉移到SD卡，那就沒有用了。

❽ 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 的許可權管理是怎麼實現的

Android 作為一個移動設備的平台，其軟體層次結構包括了一個操作系統（OS），中間件（MiddleWare）和應用程序（Application）。根據 Android 的軟體框圖，其軟體層次結構自下而上分為以下幾個層次：
操作系統層（OS）
各種庫（Libraries）和 Android 運行環境（RunTime）
應用程序框架（Application Framework）
應用程序（Application）
以下分別介紹 Andoid 各個層次的軟體的重點及其相關技術：
（1）操作系統層（OS）
Android 使用 Linux2.6 作為操作系統，Linux2.6 是一種標準的技術，Linux 也是一個開放的操作系統。Android 對操作系統的使用包括核心和驅動程序兩部分，Android 的 Linux 核心為標準的 Linux2.6 內核，Android 更多的是需要一些與移動設備相關的驅動程序。主要的驅動如下所示：
顯示驅動（Display Driver）：常用基於 Linux 的幀緩沖（Frame Buffer）驅動
Flash 內存驅動（Flash Memory Driver）
照相機驅動（Camera Driver）：常用基於 Linux 的 v4l（Video for ）驅動。
音頻驅動（Audio Driver）：常用基於 ALSA（Advanced Linux Sound Architecture，高級 Linux 聲音體系）驅動
WiFi 驅動（Camera Driver）：基於 IEEE 802.11 標準的驅動程序
鍵盤驅動（KeyBoard Driver）
藍牙驅動（Bluetooth Driver）
Binder IPC 驅動：Andoid 一個特殊的驅動程序，具有單獨的設備節點，提供進程間通訊的功能。
Power Management（能源管理）
（2）各種庫（Libraries）和 Android 運行環境（RunTime）
本層次對應一般嵌入式系統，相當於中間件層次。Android 的本層次分成兩個部分一個是各種庫，另一個是 Android 運行環境。本層的內容大多是使用 C++ 實現的。 在其中，各種庫包括：
C 庫：C 語言的標准庫，這也是系統中一個最為底層的庫，C 庫是通過 Linux 的系統調用來實現。
多媒體框架（MediaFrameword）：這部分內容是 Android 多媒體的核心部分，基於 PacketVideo（即 PV）的 OpenCORE，從功能上本庫一共分為兩大部分，一個部分是音頻、視頻的回放（PlayBack），另一部分是則是音視頻的紀錄（Recorder）。
SGL：2D 圖像引擎。
SSL：即 Secure Socket Layer 位於 TCP/IP 協議與各種應用層協議之間 , 為數據通訊提供安全支持。
OpenGL ES 1.0 ：本部分提供了對 3D 的支持。
界面管理工具（Surface Management）：本部分提供了對管理顯示子系統等功能。
SQLite：一個通用的嵌入式資料庫
WebKit：網路瀏覽器的核心
FreeType：點陣圖和矢量字體的功能。
Android 的各種庫一般是以系統中間件的形式提供的，它們均有的一個顯著特點就是與移動設備的平台的應用密切相關。 Android 運行環境主要指的虛擬機技術—— Dalvik。Dalvik 虛擬機和一般 JAVA 虛擬機（Java VM）不同，它執行的不是 JAVA 標準的位元組碼（bytecode ）而是 Dalvik 可執行格式（.dex）中執行文件。在執行的過程中，每一個應用程序即一個進程（Linux 的一個 Process）。 二者最大的區別在於 Java VM 是以基於棧的虛擬機（Stack-based），而 Dalvik 是基於寄存器的虛擬機（Register-based）。顯然，後者最大的好處在於可以根據硬體實現更大的優化，這更適合移動設備的特點。
（3）應用程序框架（Application Framework）
Android 的應用程序框架為應用程序層的開發者提供 APIs，它實際上是一個應用程序的框架。由於上層的應用程序是以 JAVA 構建的，因此本層次提供的首先包含了 UI 程序中所需要的各種控制項： 例如： Views ( 視圖組件 ) 包括 lists( 列表 ), grids( 柵格 ), text boxes( 文本框 ), buttons( 按鈕 ) 等，甚至一個嵌入式的 Web 瀏覽器。一個 Android 的應用程序可以利用應用程序框架中的以下幾個部分： Activity （活動）、Broadcast Intent Receiver （廣播意圖接收者）、Service （服務）、Content Provider （內容提供者）。
（4）應用程序（Application）
Android 的應用程序主要是用戶界面（User Interface），通常以 JAVA 程序編寫，其中還可以包含各種資源文件（放置在 res 目錄中）。JAVA 程序及相關資源經過編譯後，將生成一個 APK 包。Android 本身提供了主屏幕（Home），聯系人（Contact），電話（Phone），瀏覽器（Browsers）等眾多的核心應用。同時應用程序的開發者還可以使用應用程序框架層的 API 實現自己的程序。