androidsystem許可權
㈠ 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 系統後，系統都會為其分配一個用戶 ID，如 app_4、app_11 等。以下是 Calendar 和 Terminal 軟體在 Android 系統中進程瀏覽的結果（其中，黑色字體標明的即為應用分配的用戶 ID）： 在 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 root root 4096 2 月 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 系統申請訪問許可權。
㈡ 安卓手機存儲目錄/system/app/目錄下的應用有root許可權嗎如果把別的應用放到裡面就會獲
Android系統的開放，使其用戶可以自己查看系統和SD卡中的文件夾。就系統和SD卡中常見的目錄代表什麼意思，下面是一個較實用的總結: 一、SD卡中 1. /mnt/sdcard或者/sdcard這是Android手機中SD卡的文件夾路徑，其中/mnt/sdcard/是android 2.2或更高版本所使用的，而/sdcard是android 2.1或早期版本的存儲卡位置。 2. /mnt/sdcard/dcim或/sdcard/dcim這個DCIM文件夾是干什麼用的，這里提示大家，一般數碼相機都有DCIM文件夾，其中進入後Camera為手機攝像頭拍攝的照片或視頻存放位置。同時在DCIM文件夾中還有.thumbnails這個目錄，在Linux中開頭為「.」的文件夾就是開頭為「點」的文件夾是隱藏目錄，這裡面記錄著手機SD卡圖片的縮略圖。 3. /mnt/sdcard/LOST.DIR或/sdcard/LOST.DIR這個LOST.DIR為SD卡掃描時發現的丟失文件，裡面的文件用處不大，可以不用理會。 二、手機或平板電腦中 1. /system/app 這里是android手機rom中的系統應用存放地，如果有Root許可權可以將手機rom中自帶的應用刪除掉，這裡面一般包含一個apk文件和odex文件，大家注意文件名一一對應。 2. /data/data 這里是每個安裝過應用的用戶文件存儲位置，一般為設置文件、資料庫或臨時緩存文件，進入後以每個軟體的package name包名來命名。 3. /dev 這里是Linux系統常規文件夾，裡面的文件很多都是設備模擬的文件系統，一般用戶無需理會。 4. /system/fonts 這裡面保存著系統的字體，如果你有root許可權，可以往裡添加自己喜歡的字體，比如雅黑。 5. /system/framework 這里是android系統的框架，裡面保存著系統核心程序或java類庫，十分重要裡面的任何文件幾乎都不要做刪除操作。 6. /media/audio 這裡面保存著安卓系統默認的鈴聲，alarms是鬧鈴提醒的，notification是簡訊或提示音，ringtones是來電鈴聲，而ui是一些界面音效，比如鍵盤敲擊聲。 7./system/lib 裡面保存的是系統底層類庫，裡面很多都是框架層的實現文件，一般以.so後綴結尾類似windows下的dll文件。
㈢ Android應用程序怎樣獲取讀取系統文件的許可權
1、必須是Android系統開發人員，否則你無法修改init.rc等文件。 2、你的應用程序必須要獲得system許可權。
在應用層 你要想用代碼獲得系統文件許可權，除非你手機root了
要麼你自己坐rom。。。。 自己修改 init，rc
具體可以參考這篇博文：http://blog.sina.com.cn/s/blog_5f35912f0100w4ld.html
㈣ Android系統中的ROOT和System許可權的區別
沒有什麼區別
root是根的意識，是最高的許可權了，也就是System許可權。
root就是手機的神經中樞，它可以訪問和修改你手機幾乎所有的文件，這些東西可能是製作手機的公司不願意你修改和觸碰的東西，因為他們有可能影響到手機的穩定，還容易被一些黑客入侵（Root是Linux等類UNIX系統中的超級管理員用戶帳戶，該帳戶擁有整個系統至高無上的權利，所有對象他都有可以操作的權利，所以很多黑客在入侵系統時，都要把許可權提升到Root許可權，就是將自己的非法帳戶添加到Root用戶組。類比於Administrator是Windows NT內核系統中的超級管理員用戶帳戶，也擁有最高的許可權。但不同的是，在WINDOWS下Administrator的資源和別的用戶資源是共享的，簡單的說，別的用戶可以訪問Administrator的文件。而Linux中，別的用戶是不能訪問Root用戶的家目錄(/root)下文件的。因此，Linux比Windows更安全）
㈤ android 讀寫文件需要哪些許可權
<!--往sdcard中寫入數據的許可權 --><uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"></uses-permission><!--在sdcard中創建/刪除文件的許可權 --><uses-permission android:name="android.permission.MOUNT_U
android中的apk必須簽名
這種簽名不是基於權威證書的，不會決定某個應用允不允許安裝，而是一種自簽名證書。
重要的是，android系統有的許可權是基於簽名的。比如：system等級的許可權有專門對應的簽名，簽名不對，許可權也就獲取不到。默認生成的APK文件是debug簽名的。
獲取system許可權時用到的簽名，見：如何使Android應用程序獲取系統許可權。基於UserID的進程級別的安全機。這種簽名不是基於權威證書的，不會決定某個應用允不允許安裝，而是一種自簽名證書。重要的是，android系統有的許可權是基於簽名的。
㈥ 如何使Android應用程序獲得root許可權
一般來說， Android 下的應用程序可以逗直接地得到的最大的許可權為 system ，但是如果我們需要在程序中執行某些需要 root 許可權的命令，如 ifconfig 等，就需要 root 許可權了。按照 Simon 的文章中提到的，應用程序有以下兩種辦法臨時獲得 root 許可權：
1) 實現一個 init 實現一個 Service ，來幫助 Android 應用程序執行 root 許可權的命令。
2) 實現一個虛擬設備，這個設備幫助 Android 應用程序執行 root 許可權的命令。
第二種辦法我這里沒有嘗試，暫時也不會。這里講講我在實現第一種辦法的過程和遇到的一些問題。
1. 將我們要執行的命令寫成腳本，或者可執行程序。
下面是我的腳本 ifconfig_test.sh ：
# ！ /system/bin/sh
ifconfig
注意： 腳本的第一行必須為 # ！ /system/bin/sh ，否則無法執行，通過 dmesg 可以查看到信息內容為 cannot execve ./ifconfig_test.sh: Exec format error
也可以採用 C/C++ 編寫需要執行的命令或者程序，並在編譯 image 的時候編譯成可執行程序。
2. 在 init.rc 中注冊 service
Android 中的 service 需要在 init.rc 中注冊， Init.rc 中定義的 Service 將會被 init 進程創建，這樣將可以獲得 root 許可權。當得到相應的通知（通過屬性設置）後， init 進程會啟動該 service 。
本文中注冊的內容如下：
service ifconfig_test /system/etc/ifconfig_test.sh
oneshot
disabled
其中， oneshot 表示程序退出後不再重新啟動， disabled 表示不在系統啟動時啟動。
注意： 這里 service name 不能超過 16 個字元。我之前的 service name 由於定義的比較長， 18 個字元，設置屬性通知 service 啟動後查看 dmesg 可以看到提示： init: no such service 。查看 /system/core/init/parser.c 的源代碼，在 parse_service->valid_name 函數中可以看到如下內容： if (strlen(name) > 16) { return 0; } ，證明 service 的名字的確不能超過 16 個字元。
3. 將 Android 應用程序提升為 system 許可權
既然應用程序可以通過啟動 service 獲得 root 許可權，那麼豈不是很不安全。 Android 考慮到了這點，規定只有 system 許可權的應用程序才能設置屬性，通知 service 啟動。關於提升 system 許可權的文章網上已有很多，這里就不再細說，
4. 在應用程序中添加屬性設置代碼
前面已經提到，對於 Android 來說，應用程序通知 init 啟動 service 是通過設置系統屬性來完成的，具體為設置 System 系統屬性 逗ctl.start地 為 逗ifconfig_test地 ，這樣 Android 系統將會幫我們運行 ifconfig_test 這個 service 了。
對該系統屬性的設置有三種方法，分別對應三種不同的應用程序：
1) Java 代碼
Android 在 Java 庫中提供 System.getProperty 和 System.setProperty 方法， Java 程序可以通過他們來設置和獲得屬性。代碼如下：
SystemProperties.set("ctl.start", "ifconfig_test");
上面的代碼是通知 Android 執行 ifconfig_test service ，如果需要查詢當前 service 執行的狀態，如是否執行完畢，可以通過如下代碼查詢：
ret = SystemProperties.get("init.svc. ifconfig_test ", "");
if(ret != null && ret.equals("stopped"))
{
return true;
}
2） JNI 代碼
當編寫 NDK 的程序時，可以使用 property_get 和 property_set 這兩個 API 來獲得和設置屬性。使用這兩個 API 必須要包含頭文件 cutils/properties.h 和鏈接 libcutil 庫。
3） Shell 腳本
Android 提供了命令行 setprop 和 getprop 來設置和獲取屬性，他們可以在腳本中被使用。
由於我的程序是在 JNI 中調用腳本，腳本中又執行 ifconfig ，因此我將設置屬性的部分放在了腳本中完成，代碼如下：
setprop ctl.start ifconfig_test
#wait for the service until it stops
ret=1
while [ $ret -ne 0 ]
do
getprop | grep "$ENABLE_MAPPER_SRV" | grep stopped
ret=$?
done
通過上面 4 個步驟， Android 應用程序就獲得了 root 許可權，更具體的說，是在執行我們需要執行的命令時臨時獲得了 root 許可權。
轉載僅供參考，版權屬於原作者。祝你愉快，滿意請~~哦
㈦ 如何用adb獲得android system的許可權
Android應用程序只在有限的范圍內有讀取許可權，如/data/data/*.*.*/，而如果想讓app訪問其它地方的資源時，就必須要獲取更高的許可權，像system或者root，root的獲取方法也是基於system的，因此本文先完成system許可權的獲取，實際上一般的應用有system的許可權基本上也夠了。
1、修改apk內的AndroidManifest.xml
在manifest節點中加入android:sharedUserId="android.uid.system"
2、編譯工程產生apk文件
eclipse自動就幫你產生
3、解壓縮工具打開*.apk
刪除META-INF文件夾中的CERT.RSA和CERT.SF兩個文件
4、給*.apk文件簽名
這步需要在android源碼中進行
1)cd build/tools/signapk
2)javac signapk.java(這里產生*.class)
3)mkdir test/com/android/signapk
4)cp *.class test/com/android/signapk
5)jar cvfm signapk.jar SignApk.mf -C test/ .(這里產生signapk.jar)
5、製作簽名後的apk文件
1)mkdir SignApk
2)步驟4中產生的signapk.jar拷貝到SignApk文件夾中
3)cp build/target/proct/security/{platform.x509.pem,platform.pk8} SignApk
4)將apk也拷貝到SignApk中
5)java -jar signapk.jar platform.x509.pem platform.pk8 *.apk new.apk
6、製作新的image文件
將new.apk導入到android源碼目錄中(一般是out/target/proct/平台/system/app/下)，編譯生成新的system.img，再download到開發板
7、測試
如果app涉及到文件讀寫，可以待系統啟動後adb shell到板子上,ls -l查看app安裝目錄(/data/data/*/*/*/)的許可權，看看是不是變成system:system了。
㈧ Android如何獲得系統（system）許可權
Android中如何修改系統時間(應用程序獲得系統許可權)在android的API中有提供 SystemClock.setCurrentTimeMillis()函數來修改系統時間，可惜無論你怎麼調用這個函數都是沒用的，無論模擬器還是真機，在logcat中總會得到"Unable to open alarm driver: Permission denied ".這個函數需要root許可權或者運行與系統進程中才可以用。 本來以為就沒有辦法在應用程序這一層改系統時間了，後來在網上搜了好久，知道這個目的還是可以達到的。 第一個方法簡單點，不過需要在Android系統源碼的環境下用make來編譯： 1. 在應用程序的AndroidManifest.xml中的manifest節點中加入 android:sharedUserId="android.uid.system"這個屬性。 2. 修改Android.mk文件，加入LOCAL_CERTIFICATE := platform這一行 3. 使用mm命令來編譯，生成的apk就有修改系統時間的許可權了。 第二個辦法麻煩點，不過不用開虛擬機跑到源碼環境下用make來編譯： 1. 同上，加入android:sharedUserId="android.uid.system"這個屬性。 2. 使用eclipse編譯出apk文件，但是這個apk文件是不能用的。 3. 用壓縮軟體打開apk文件，刪掉META-INF目錄下的CERT.SF和CERT.RSA兩個文件。 4. 使用目標系統的platform密鑰來重新給apk文件簽名。這步比較麻煩， 首先找到密鑰文件，在我的Android源碼目錄中的位置 是"build argetproctsecurity"，下面的platform.pk8和platform.x509.pem 兩個文件。 然後用Android提供的Signapk工具來簽名，signapk的源代碼是 在"build oolssignapk"下， 用法為"signapk platform.x509.pem platform.pk8 input.apk output.apk"， 文件名最好使用絕對路徑防止找不到，也可以修改源代碼直接使用。 這樣最後得到的apk和第一個方法是一樣的。 最後解釋一下原理，首先加入android:sharedUserId="android.uid.system"這個屬性。通過Shared User id,擁有同一個User id的多個APK可以配置成運行在同一個進程中。那麼把程序的UID配成android.uid.system，也就是要讓程序運行在系統進程中，這樣就有許可權來修改系統時間了。 只是加入UID還不夠，如果這時候安裝APK的話發現無法安裝，提示簽名不符，原因是程序想要運行在系統進程中還要有目標系統的platform key，就是上面第二個方法提到的platform.pk8和platform.x509.pem兩個文件。用這兩個key簽名後apk才真正可以放入系統進程中。第一個方法中加入LOCAL_CERTIFICATE := platform其實就是用這兩個key來簽名。這也有一個問題，就是這樣生成的程序只有在原始的Android系統或者是自己編譯的系統中才可以用，因為這樣的系統才可以拿到 platform.pk8和platform.x509.pem兩個文件。要是別家公司做的Android上連安裝都安裝不了。試試原始的Android 中的key來簽名，程序在模擬器上運行OK，不過放到G3上安裝直接提示"Package ... has no signatures that match those in shared user android.uid.system"，這樣也是保護了系統的安全。最最後還說下，這個android:sharedUserId屬性不只可以把apk放到系統進程中，也可以配置多個APK運行在一個進程中，這樣可以共享數據，應該會很有用的。
㈨ 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應用程序獲取system許可權
不論何種系統版本，均需要root許可權。
安卓4.4以下版本的方法：
使用re管理器移動想要獲取system許可權的軟體的apk安裝包到/system/app文件夾，更改許可權為rw-r-r確定後重啟手機。
安卓4.4和以上版本的方法：
使用re管理器移動想要獲取system許可權的軟體的apk安裝包到/system/priv-app文件夾，更改許可權為rw-r-r確定後重啟手機。
備註：安卓系統並不像windows，system許可權（uid1000）並不是最高許可權，僅僅比普通用戶擁有少量的特殊許可權，比如安裝軟體無需彈窗。而系統中最高許可權是root許可權（uid0）。