应用使用permisson权限

最新推荐文章于 2020-08-24 20:23:18 发布

binn_chern

最新推荐文章于 2020-08-24 20:23:18 发布

阅读量598

点赞数

分类专栏： Android应用开发文章标签：权限

本文链接：https://blog.csdn.net/mcsbary/article/details/88721336

版权

Android应用开发专栏收录该内容

11 篇文章 2 订阅

订阅专栏

概述

在android系统的安全模型中，应用程序在默认的情况下不可以执行任何对其他应用程序，系统或者用户带来负面影响的操作。如果应用需要执行某些操作，就需要声明使用这个操作对应的权限。在manifest文件中添加标记，如

<uses-permission android:name="com.example.project.DEBIT_ACCT" />

android 系统提供了一系列这样的权限，具体可以查看android 权限，另外，android系统在新的版本中会增加一些permission，可以查看android 版本信息。

一般来说，在满足安全性要求的前提下尽可能少定义权限。对于大多数应用来说，它们很少会创建新权限，如果必要，用户也可以自定义权限。

系统默认权限

开发中app调用android api，api使用说明部分会列出具体需要的权限。如蓝牙模块相关api操作：
在这里插入图片描述
把需要的权限使用在中即可。有些权限不仅需要声明还需要特定的签名，运行中才可以通过权限申请，在后面的自定义签名属性说明。

创建和使用应用特有权限

自定义权限原则

如果必须创建新权限，尽量考虑创建 “signature” 保护级别的权限。“签名”级别权限的内容对用户完全透明开放，而且只有由执行权限检查的应用的开发者签名的应用才可访问这些内容。

如果创建了 “dangerous” 保护级别的权限，则事情就会更加复杂，需要注意：

该权限必须包含一个字符串，清楚明确地说明他们需要做出的安全决策。
该权限的字符串必须翻译成多种不同语言。
用户可能会因为权限含糊不清或存在风险而选择不安装应用。
应用可能会在权限创建程序尚未安装的情况下请求权限。

这些事情会给开发者带来巨大的非技术性挑战，也让用户感到困惑，因此不鼓励使用 “dangerous” 权限级别。

自定义权限和使用

示例:
在中定义新权限用元素来声明。例如，Activity 可受到如下保护：

<manifest . . . >
    <permission android:name="com.example.project.DEBIT_ACCT" . . . />
    <uses-permission android:name="com.example.project.DEBIT_ACCT" />
    . . .
    <application . . .>
        <activity android:name="com.example.project.FreneticActivity"
                  android:permission="com.example.project.DEBIT_ACCT"
                  . . . >
            . . .
        </activity>
    </application>
</manifest>

在此示例中，DEBIT_ACCT 权限不仅是通过元素来声明，而且其使用也是通过元素来请求。要让应用的其他组件也能够启动受保护的 Activity，必须请求其使用权限，即便保护是由应用本身施加的亦如此。

同样还是在此示例中，如果将 permission 属性设置为在其他位置（例如，android.permission.CALL_EMERGENCY_NUMBERS）声明的权限，则无需使用元素再次声明。但是，仍有必要通过请求其使用权限。

语法详解

语法

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

description，该标签就是权限的介绍。
icon，权限的显示图标
lable，展示给用户的权限名称
name，开发者使用该权限时需要的名称
permissionGroup,把该权限分配到一个已定义的权限组中。该权限组在其他应用或当前应用中使用定义。
protectionLevel,指定保护级别，由“a base permission|falgs ”。flags可以没有。

下面针对protectionLevel，详细说明不同级别的定义使用方式。

定义Normal级别权限

base permission是“normal”，权限被声明为Normal级别，任何应用都可以申请，在安装应用时，不会直接提示给用户，点击全部才会展示。

定义dangerous级别权限

base permission是“dangerous”，高风险权限，一般这种权限会访问用户私有数据或者控制设备（使用摄像头，定位）。任何应用申请使用该权限，系统会询问用户是否同意。尽量不要使用这个级别的权限，若有需求，用其他方法绕过较好。

定义signature级别权限

base permission是“signature”，该级别权限，申请使用该权限的应用签名需要和声明该权限的应用前面相同。如果校验签名一致，系统会自动授权，不会询问用户。

定义signatureOrSystem级别权限

base permission是“signatureOrSystem”，包含上面的signature，另外如果是system image中自带的app申请这个权限，那么system也会自动授予它权限而不需要询问用户。

flags值

？？？

使用场景

自定义权限一般用于暴露出去的组件，提高安全性。Android允许一个应用（客户端）调用另一个应用（服务端）的组件。那么作为服务端的应用就得暴露相应的组件，客户端应用才能访问。当然，在暴露的时候，权限是非必须的，如果暴露的组件没有权限的话，那么任何的其他应用都可以来调用该组件；如果该组件申请了权限，那么只有拥有该权限的应用才能调用该组件。

<activity
    android:name=".TestA_Activity"
    android:exported="true"
    ...  />

exported属性就是代表是否暴露。该例子并没有要求调用者需要申请权限，也就是说，任何的应用就可以调用才组件。如果每个应用都可以调用我们的组件的话，显然是不安全的，我们希望只有使用了我们的权限的应用，才能调用我们暴露的组件，我们可以在activity中加入permission属性。

<activity
    android:name=".TestA_Activity"
    android:exported="true"
    ...  />

Intent intent = new Intent();
intent.setClassName("com.bright.permission", "com.bright.permission.TestA_Activity");
startActivity(intent);

除了上面的方式，还可以通过intent-filter隐式启动：

<activity
    android:name=".TestA_Activity"
    android:exported="true"
    ... >
    <intent-filter>
            <action android:name="com.bright.permission.action.TEST"/>
            <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Intent intent = new Intent();
intent.setAction("com.bright.permission.action.TEST");
startActivity(intent);

自定义权限注意点

两个应用声明了相同的权限

Android不允许两个不同的应用定义一个相同名字的权限（除非这两个应用拥有相同的签名），所以在命名的时候，需要特别注意。
拥有相同自定义权限的软件必须使用同样的签名，否则后一个程序无法安装。

和应用安装顺序的关系

场景：App A中声明了权限PermissionA，App B中使用了权限PermissionA。

情况一：PermissionA的保护级别是normal或者dangerous
App B先安装，App A后安装，此时App B无法获取PermissionA的权限，从App B打开App A会报权限错误。
App A先安装，App B后安装，从App B打开App A一切正常。
情况二：PermissionA的保护级别是signature或者signatureOrSystem
App B先安装，App A后安装，如果App A和App B是相同的签名，那么App B可以获取到PermissionA的权限。如果App A和App B的签名不同，则App B获取不到PermissionA权限。
即，对于相同签名的app来说，不论安装先后，只要是声明了权限，请求该权限的app就会获得该权限。
这也说明了对于具有相同签名的系统app来说，安装过程不会考虑权限依赖的情况。安装系统app时，按照某个顺序（例如名字排序，目录位置排序等）安装即可，等所有app安装完了，所有使用权限的app都会获得权限。