android自定義permission

Ⅰ Android自定義動態壁紙開發

看到有些手機酷炫的動態壁紙，有沒有好奇過他們是如何實現的，其實我們自己也可以實現。

如果你了解使用過SurfaceView的話，那麼開發一款動態壁紙對你來說其實非常簡單。

動態壁紙的本質其實就是一個服務在維護一個動態壁紙引擎Engine，所以我們看到的動態效果其實是通過這個引擎畫出來的。而維護這個引擎的服務，就是WallpaperService。本篇文章並不討論內部實現原理，只是讓大家知道如何去實現動態壁紙，所以就不詳細說了。

大體上可分為三個步驟：

創建自定義WallpaperService繼承WallpaperService
在Manifest中注冊該Service並添加相關屬性
創建所需要的xml文件
1.創建自定義WallpaperService

2.Manifest注冊

一定要添加的幾個地方：permission、intent-filter、meta-data。

3.創建需要的xml文件

這個xml文件就是Manifest中meta-data中的resource需要的文件：

需要注意第二個屬性：settingsActivity，這個屬性可以設置也可以不設置，他是啟動一個設置動態壁紙的界面，一般情況下其實用不到這個界面，我們一般會使用PreferenceActivity去實現。下面是添加該屬性和不添加該屬性的區別：

完成這些之後，就是我們設計動態壁紙的時候了。回到自定義的Wallpaper類中：

我們當時在類中自定義了一個內部類MyEngine繼承自Engine。這個Engine就是用來繪制的。關於Engine的幾個主要方法如下：

onOffsetsChanged要注意一下，還記得有的手機滑動桌面時候背景圖片會跟著左右移動嗎，這個方法就可以實現這個效果，在手勢滑動的每一幀都會回調依次。一下是個人理解的參數的含義：

xOffset：x方向滑動的百分比（與桌面分頁數有關）

yOffset：y方向滑動百分比（一般用不到）

xOffsetStep：x方向每個分頁所佔的百分比（1 / xOffsetStep = 桌面的分頁數）

yOffsetStep：同

xPixelOffset：x放下像素偏移量

y。。。。。
4.繪制。

實現繪制的方式，就跟SurfaceView的繪制一樣了：

我只是簡單的話了一個紅色背景，效果如下：

當然可以實現很多不同的效果，這個就根據不同的需求去實現了。

Ⅱ 針對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 permission怎麼添加

java"><?xmlversion="1.0"encoding="utf-8"?>
<manifestxmlns:android="

package="com.android.myapplication">

<uses-permissionandroid:name="android.permission.INTERNET"/>
<uses-permissionandroid:name="android.permission.READ_LOGS"/>
<uses-permissionandroid:name="android.permission.VIBRATE"/>

<application
android:name=".App"
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme">

<activityandroid:name=".MainActivity">
<intent-filter>
<actionandroid:name="android.intent.action.MAIN"/>

<categoryandroid:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
</application>

</manifest>

Android6.0開始，對安全性要求較高的許可權，在Manifest中聲明後，還需要對許可權進行動態請求授權。

Ⅳ Android 簡單的圖片查看器

說明：在文件管理器中，可以使用這個app來打開圖片

ImageView 常用的一些XML屬性和方法：

支持的scaleType 屬性：

在打開圖片的Activity里需要必須設置以下三個屬性：

可以通過設置 mimeType 來關聯對應的類型，比如： mimeType="vedio/* 關聯視頻格式的文件等。

詳細可以參考： Android 常用 mimeType 表

讀取圖片，需要寫入到外部存儲器（SD卡）的許可權：
<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

如果是 API23 以上還需要動態許可權：

自定義許可權的格式： 包名.permission.許可權名
自定義許可權需要在 Manifest 文件里使用 <permission android:name="..." /> 語法 進行注冊。
PackageManager.PERMISSION_GRANTED 表示許可權允許； PackageManager.PERMISSION_DENIED 表示許可權拒絕。

Ⅳ 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 自定義的launcher在6.0後需要動態申請許可權

6.0許可權的基本知識，以下是需要單獨申請的許可權，共分為9組，每組只要有一個許可權申請成功了，就默認整組許可權都可以使用了。

group:android.permission-group.CONTACTS
permission:android.permission.WRITE_CONTACTS
permission:android.permission.GET_ACCOUNTS
permission:android.permission.READ_CONTACTS group:android.permission-group.PHONE
permission:android.permission.READ_CALL_LOG
permission:android.permission.READ_PHONE_STATE
permission:android.permission.CALL_PHONE
permission:android.permission.WRITE_CALL_LOG
permission:android.permission.USE_SIP
permission:android.permission.PROCESS_OUTGOING_CALLS
permission:com.android.voicemail.permission.ADD_VOICEMAIL group:android.permission-group.CALENDAR
permission:android.permission.READ_CALENDAR
permission:android.permission.WRITE_CALENDAR group:android.permission-group.CAMERA
permission:android.permission.CAMERA group:android.permission-group.SENSORS
permission:android.permission.BODY_SENSORS group:android.permission-group.LOCATION
permission:android.permission.ACCESS_FINE_LOCATION
permission:android.permission.ACCESS_COARSE_LOCATION group:android.permission-group.STORAGE
permission:android.permission.READ_EXTERNAL_STORAGE
permission:android.permission.WRITE_EXTERNAL_STORAGE group:android.permission-group.MICROPHONE
permission:android.permission.RECORD_AUDIO group:android.permission-group.SMS
permission:android.permission.READ_SMS
permission:android.permission.RECEIVE_WAP_PUSH
permission:android.permission.RECEIVE_MMS
permission:android.permission.RECEIVE_SMS
permission:android.permission.SEND_SMS
permission:android.permission.READ_CELL_BROADCASTS

• 以下是普通許可權，只需要在AndroidManifest.xml中申請即可。

  android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
  android.permission.ACCESS_NETWORK_STATE
  android.permission.ACCESS_NOTIFICATION_POLICY
  android.permission.ACCESS_WIFI_STATE
  android.permission.ACCESS_WIMAX_STATE
  android.permission.BLUETOOTH
  android.permission.BLUETOOTH_ADMIN
  android.permission.BROADCAST_STICKY
  android.permission.CHANGE_NETWORK_STATE
  android.permission.CHANGE_WIFI_MULTICAST_STATE
  android.permission.CHANGE_WIFI_STATE
  android.permission.CHANGE_WIMAX_STATE
  android.permission.DISABLE_KEYGUARD
  android.permission.EXPAND_STATUS_BAR
  android.permission.FLASHLIGHT
  android.permission.GET_ACCOUNTS
  android.permission.GET_PACKAGE_SIZE
  android.permission.INTERNET
  android.permission.KILL_BACKGROUND_PROCESSES
  android.permission.MODIFY_AUDIO_SETTINGS
  android.permission.NFC
  android.permission.READ_SYNC_SETTINGS
  android.permission.READ_SYNC_STATS
  android.permission.RECEIVE_BOOT_COMPLETED
  android.permission.REORDER_TASKS
  android.permission.REQUEST_INSTALL_PACKAGES
  android.permission.SET_TIME_ZONE
  android.permission.SET_WALLPAPER
  android.permission.SET_WALLPAPER_HINTS
  android.permission.SUBSCRIBED_FEEDS_READ
  android.permission.TRANSMIT_IR
  android.permission.USE_FINGERPRINT
  android.permission.VIBRATE
  android.permission.WAKE_LOCK
  android.permission.WRITE_SYNC_SETTINGS
  com.android.alarm.permission.SET_ALARM
  com.android.launcher.permission.INSTALL_SHORTCUT
  com.android.launcher.permission.UNINSTALL_SHORTCUT
  

Ⅶ Android許可權目錄

android:name="android.permission.INTERNET"————訪問網路

android:name="android.permission.ACCESS_NETWORK_STATE"————獲取網路狀態

android:name="android.permission.ACCESS_WIFI_STATE"————獲取WiFi狀態

android:name="android.permission.WRITE_EXTRNAL_STORAGE"————寫入外部儲存

android:name="android.permission.READ_EXTRNAL_STORAGE"————讀取外部儲存

android:name="android.permission.WRITE_EXTRNAL_STORAGE"————寫入外部儲存

android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEM"

tools:ignore="ProtectedPermission"————掛載卸載文件系統

android:name="android.permission.READ_PHONE_STATE"————讀取電話狀態

android:name="android.permission.VIBRATE"————允許震動

android:name="android.permission.WAKE_LOCK"————允許後台運行

android:name="android.permission.READ_LOGS"

tools:ignore="ProtectedPermission"————讀取系統文件

android:name="android.permission.CAMERA"————調用相機許可權

android:name="android.permission.CALL_PHONE"————調用打電話許可權

android:name="com.fingerprints.service.ACCESS_FINGERPRINT_MANAGER"————指紋識別

android:name="com.samsung.android.providers.context.permission.WRITE_USE_APP_FEATURE_SURVEY"————

android:name="com.samsung.android.providers.context.permission.EXPAND_STATUS_BAR"————通知欄伸縮

android:name="android.permission.REQUEST_INSTALL_PACKGES"————允許請求未知來源許可權

Ⅷ Android 許可權管理之 <uses-permission> 標簽

<uses-permission> 標簽位於 Manifest.xml 文件里，現在的 IDE 會提示需要把 <uses-permission> 標簽寫於 <application> 之前。

語法：

Requests a permission that the application must be granted in order for it to operate correctly. Permissions are granted by the user when the application is installed, not while it's running.

為了應用操作的正確，需要請求相應的許可權。許可權在應用安裝的時候，而不是運行的時候，需要得到用戶的確認。

Android 許可權管理之 <uses-permission> 標簽

Ⅸ Android開發中怎麼主動請求許可權

自定義屬於自己的permission 或屬於開發者使用的同一個簽名的permission。定義一個permission 就是在menifest文件中添加一個permission標簽。

<permission android:description="string resource"
android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permissionGroup="string"
android:protectionLevel=["normal" | "dangerous" |
"signature" | "signatureOrSystem"] />

android:description :對許可權的描述，一般是兩句話，第一句話描述這個許可權所針對的操作，第二句話告訴用戶授予app這個許可權會帶來的後果
android:label: 對許可權的一個簡短描述
android:name :許可權的唯一標識，一般都是使用 報名加許可權名
android:permissionGroup: 許可權所屬許可權組的名稱
android:protectionLevel: 許可權的等級，
normal 是最低的等級，聲明次許可權的app，系統會默認授予次許可權，不會提示用戶
dangerous 許可權對應的操作有安全風險，系統在安裝聲明此類許可權的app時會提示用戶
signature 許可權表明的操作只針對使用同一個證書簽名的app開放
signatureOrSystem 與signature類似，只是增加了rom中自帶的app的聲明

android:name 屬性是必須的，其他的可選，未寫的系統會指定默認值

1、許可權的聲明(APP1)

<permission android:name="com.xxx.permission" />

<receiver

android:name="com.example.demo1"

android:permission="com.xxx.permission" >

<intent-filter>

<action android:name="com.test.action" />

</intent-filter>

</receiver>

<activity
android:name=".MainActivity"
android:label="@string/title_activity_main"
android:permission="com.xxx.permission" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

2、許可權的使用(APP2)
<uses-permission android:name="com.xxx.permission" />

Ⅹ android可以為本工程中的一個服務自定義一個permission屬性么

service所在的app不需要uses-permission吧。其他要用到改服務的才需要uses-permission。而且你的service也沒有設置exported=true，其他的應用也用不到。