android提示許可權訪問許可權

① 針對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.
轉載

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

一般你添加了許可權，在第一次安裝運行時就會提醒，你也可以強制，比如照相機許可權檢查

java">finalprivateintREQUEST_CODE_ASK_PERMISSIONS=123;//許可權請求碼

//在執行掃描二維碼之前檢查是否具有打開照相機的許可權
try{
inthasWriteContactsPermission=context.checkSelfPermission(Manifest.permission.CAMERA);//許可權檢查
if(hasWriteContactsPermission!=PackageManager.PERMISSION_GRANTED){
requestPermissions(newString[]{Manifest.permission.CAMERA},
REQUEST_CODE_ASK_PERMISSIONS);
return;//沒有許可權，結束
}else{
//做自己的操作
}
}catch(Exceptione){
e.printStackTrace();
ToastUtil.defaultToast(getContext().getApplicationContext(),"許可權異常");
}

//回調函數，無論用戶是否允許都會調用執行此方法@Override
(intrequestCode,@NonNullString[]permissions,@NonNullint[]grantResults){
switch(requestCode){
caseREQUEST_CODE_ASK_PERMISSIONS:
if(grantResults[0]==PackageManager.PERMISSION_GRANTED){
//PermissionGranted用戶允許許可權繼續執行（我這里執行的是二維碼掃描，檢查的是照相機許可權）
Intentintent=newIntent(getActivity(),
CaptureActivity.class);
startActivityForResult(intent,REQUEST_CODE_SCAN);
}else{
//PermissionDenied拒絕
ToastUtil.defaultToast(context.getApplicationContext(),"獲取許可權失敗，無法掃描");
}
break;
default:
super.onRequestPermissionsResult(requestCode,permissions,grantResults);
}
}

③ 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

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

android藍牙自動配對連接的具體代碼如下： 1. 獲取藍牙適配器BluetoothAdapter blueadapter=BluetoothAdapter.getDefaultAdapter(); 如果BluetoothAdapter 為null，說明android手機沒有藍牙模塊。 2. 判斷藍牙模塊是否開啟，blueadapter.isEnabled() true表示已經開啟，false表示藍牙並沒啟用。 3. 啟動配置藍牙可見模式，即進入可配對模式Intent in=new Intent(BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE); in.putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION, 200); startActivity(in); ，200就表示200秒。 4. 獲取藍牙適配器中已經配對的設備Set<BluetoothDevice> device=blueadapter.getBondedDevices(); 當然，還需要在androidManifest.xml中聲明藍牙的許可權 <uses-permission android:name="android.permission.BLUETOOTH" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> 5.自動配對設置Pin值 static public boolean autoBond(Class btClass, BluetoothDevice device, String strPin) throws Exception { Method autoBondMethod = btClass.getMethod("setPin", new Class[] { byte[].class }); Boolean result = (Boolean) autoBondMethod .invoke(device, new Object[] { strPin.getBytes() }); return result; } 6.開始配對請求 static public boolean createBond(Class btClass, BluetoothDevice device) throws Exception { Method createBondMethod = btClass.getMethod("createBond"); Boolean returnValue = (Boolean) createBondMethod.invoke(device); return returnValue.booleanValue(); }

⑤ 如何提示Android用戶開啟許可權

//檢查系統是否開啟了地理位置許可權;
//注意：此時的Manifest的導入包路徑import android.Manifest;
if (ContextCompat.checkSelfPermission(mContext, Manifest.permission.ACCESS_COARSE_LOCATION)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.ACCESS_COARSE_LOCATION}, 1);
}

執行完requestPermissions方法後，Activity會自動回調一個onRequestPermissionsResult方法：//requestPermissions方法執行後的回調方法
/*
* requestCode:相當於一個標志，
* permissions：需要傳進的permission，不能為空
* grantResults：用戶進行操作之後，或同意或拒絕回調的傳進的兩個參數;
* */
@Override
public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
super.onRequestPermissionsResult(requestCode, permissions, grantResults);
//這里實現用戶操作，或同意或拒絕的邏輯
/*grantResults會傳進android.content.pm.PackageManager.PERMISSION_GRANTED 或 android.content.pm.PackageManager.PERMISSION_DENIED兩個常，前者代表用戶同意程序獲取系統許可權，後者代表用戶拒絕程序獲取系統許可權*/
}

⑥ 如何解除vivo安卓11文件訪問許可權

若是指進入【文件管理--手機存儲--Andriod--data/obb】，提示：因Android許可權限制，無法訪問此目錄，建議前往「文件」應用查看的現象，由於安卓系統安全機制升級，基於消費者的隱私和信息安全，應用產生的數據不允許文件管理直接訪問，建議點擊「前往查看」跳轉到谷歌原生文件管理界面查看相關文件。進入谷歌原生文件管理界面後，如果文件夾名稱尾部顯示」...「導致無法識別出文件夾名稱，可以點擊頁面右上角的方形網格圖標，切換成列表顯示，如果身邊有電腦，建議暫時通過數據線連接電腦與手機，手機端選擇：管理文件，通過電腦訪問手機存儲目錄，即可進入相應目錄查看文件。
註：【文件管理--常用分類】中，QQ、微信、釘釘軟體進行了單獨分類，如果需要查看這些軟體下載的圖片、視頻等資料，可進入這些分類查看。

⑦ 安卓11怎麼解除文件訪問限制

在手機設置的「安全和隱私」選項中取消即可。

1、在手機桌面上找到「設置」，打開設置。如下圖所示：

⑧ 安卓data訪問許可權問題

建議你查看手機使用技巧，一般接收或下載保存的文件到文件管理里的對應文件夾里查看，你看過沒有保存的到data文件夾里查看，訪問受限到隱私和安全關閉。

⑨ 安卓開源Android_permission訪問許可權

android.permission.ACCESS_NETWORK_STATE允許程序訪問有關GSM網路信息(Allowsapplications to access information about networks)

android.permission.ACCESS_WIFI_STATE允許程序訪問Wi-Fi網路狀態信息(Allowsapplications to access information about Wi-Fi networks)

android.permission.BLUETOOTH允許程序連接到已配對的藍牙設備(Allowsapplications to connect to paired bluetooth devices)

android.permission.BLUETOOTH_ADMIN允許程序發現和配對藍牙設備(Allowsapplicationsto discover and pair bluetooth devices)

android.permission.CHANGE_WIFI_STATE允許程序改變Wi-Fi連接狀態(Allowsapplications to change Wi-Fi connectivity state)

android.permission.DEVICE_POWER允許訪問底層電源管理(Allowslow-level access to power management)

android.permission.DISABLE_KEYGUARD允許程序禁用鍵盤鎖(Allowsapplications to disable the keyguard )

android.permission.EXPAND_STATUS_BAR允許一個程序擴展收縮在狀態欄,Android開發網提示應該是一個類似WindowsMobile中的托盤程序(Allows an application to expand or collapse the status bar.)

android.permission.GET_DETAILED_TASKS 檢索正在運行的應用的詳細信息，惡意程序可藉此獲得其他應用的私密信息

android.permission.GET_TASKS 檢索正在運行的應用，可用於了解當前設備上使用了哪些應用

android.permission.INJECT_EVENTS 將自身的輸入事件(例如按鍵)提供給其他應用，惡意程序可堅持控制手機

android.permission.INTERNAL_SYSTEM_WINDOW 允許創建未授權的內部系統窗口，普通應用絕不應該使用此許可權

android.permission.MANAGE_APP_TOKENS 創建和管理令牌，普通應用絕不應該使用此許可權

android.permission.MASTER_CLEAR 恢復出廠設置

android.permission.MANAGE_NETWORK_POLICY

android.permission.MANAGE_USB

android.permission.MOUNT_UNMOUNT_FILESYSTEMS允許掛載和反掛載文件系統可移動存儲(Allowsmounting and unmounting file systems for removable storage. )

android.permission.RECEIVE_BOOT_COMPLETED允許一個程序接收到 ACTION_BOOT_COMPLETED廣播在系統完成啟動(Allowsan application to receive the ACTION_BOOT_COMPLETED that is broadcast after thesystem finishes booting. )

android.permission.REORDER_TASKS允許程序改變Z軸排列任務(Allowsan application to change the Z-order of tasks)

android.permission.READ_PHONE_STATE 讀取手機的狀態和身份，可以確定手機的號碼/序列號/是否處於通話狀態/被叫號碼

android.permission.READ_FRAME_BUFFER 讀取幀緩沖區的內容

android.permission.REMOVE_TASKS 停止正在運行的進程，惡意程序可以藉此停止其他程序的運行

android.permission.READ_EXTERNAL_STORAGE

android.permission.REMOTE_AUDIO_PLAYBACK

android.permission.START_ANY_ACTIVITY 允許應用啟動任何活動(不考慮許可權保護和導出狀態)

android.permission.SYSTEM_ALERT_WINDOW 在其他應用之上或用戶界面的特定部分繪圖，可能會干擾對用戶界面的使用，或者使其他應用中看到的內容發生變化

android.permission.SET_ORIENTATION允許底層訪問設置屏幕方向和實際旋轉(Allowslow-level access to setting the orientation (actually rotation) of the screen.)

android.permission.STATUS_BAR允許程序打開、關閉或禁用狀態欄及圖標Allows an application to open, close, or disable the statusbar and its icons.

android.permission.SET_SCREEN_COMPATIBILITY 允許控制其他應用的屏幕兼容模式，惡意程序可以藉此影響其他應用的行為

android.permission.START_ANY_ACTIVITY 允許應用啟動任何活動(不考慮許可權保護和導出狀態)
android.permission.STOP_APP_SWITCHES讓應用程序始終運行

android.permission.STATUS_BAR_SEBVICE

android.permission.SHELL

android.permission.UPDATE_DEVICE_STATS 允許應用修改電池的統計信息，普通應用絕不應該使用此許可權

android.permission. VIBRATE控制振動器

android.permission.WRITE_EXTERNAL_STORAGE 允許寫入或刪除SD卡

android.permission.WRITE_SETTINGS 修改系統設置，惡意程序可以藉此破壞系統

android.permission.WAKE_LOCK 阻止手機進入休眠狀態