android 代码中加权限,android framework中添加自定义权限

本文详细解读了Android系统中的`signatureOrSystem`权限类型,探讨其工作原理,以及在不同场景下的使用规则。通过实例演示,展示了如何影响应用安装和权限授予,并介绍了与normal和dangerous权限的区别。关键实验结果揭示了签名一致性在决定权限授予中的重要性。
摘要由CSDN通过智能技术生成

protectionLevel分为四级:

"normal"

The default value. A lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. The system automatically grants this type of permission to a requesting application at installation, without asking for the user's explicit approval (though the user always has the option to review these permissions before installing).

"dangerous"

A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Because this type of permission introduces potential risk, the system may not automatically grant it to the requesting application. For example, any dangerous permissions requested by an application may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities.

"signature"

A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.

"signatureOrSystem"

A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificates as those in the system image. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The "signatureOrSystem" permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.

前面几个很好理解

现在重点记忆下最后一个signatureOrSystem 顾名思义就是在拥有权限的同时还必须满足signature一致或System级别APK才拥有!

现在做了如下尝试

Test Result:

TestCustomPermission是我自定义了一个Activity的访问权限的APK

TestPermission 去访问TestCustomPermission的Activity

EclipseSignature 中两个都用eclipse的签名

OtherSignature 中两个都用相同的另一种签名

DifferentSignature 中两个签名不想同

以下是测试结果:

APP级别

权限设置为signatureOrSystem

1. EclipseSignature 成功访问 ! 可以加入权限!

2. OtherSignature 成功访问 ! 可以加入权限!

3. DifferentSignature  访问失败!

权限设置为normal

1. DifferentSignature   成功访问 ! 可以加入权限!

System 级别

权限设置为signatureOrSystem

1. EclipseSignature 成功访问 ! 可以加入权限!

2. OtherSignature 成功访问 ! 可以加入权限!

3. DifferentSignature  成功访问 ! 可以加入权限!

TestCustomPermission再 system TestPermission 在APP

1.DifferentSignature 失败

2.签名相同成功!

最后一个实验

在TestCustomPermission中注册 signatureOrSystem!APP层访问 在framework API中验证!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Android,非定向广播(Non-Ordered Broadcast)是一种广播形式,它可以被多个应用程序同时接收。与有序广播(Ordered Broadcast)不同,非定向广播不需要等待一个接收者完全处理完广播后再传递给下一个接收者。 在为应用程序添加非定向广播权限时,您需要使用`<uses-permission>`标记来声明所需的权限。例如,如果您的应用程序需要接收网络状态更改广播,则可以使用以下代码: ``` <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> ``` 要在应用程序注册非定向广播接收器,您需要创建一个继承自BroadcastReceiver的类,然后在您的AndroidManifest.xml文件声明该类。例如,以下代码注册了一个接收网络状态更改广播的接收器: ``` public class NetworkStateReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { // 处理网络状态更改广播 } } ``` ``` <receiver android:name=".NetworkStateReceiver"> <intent-filter> <action android:name="android.net.conn.CONNECTIVITY_CHANGE" /> </intent-filter> </receiver> ``` 在上面的代码,接收器将接收名为“android.net.conn.CONNECTIVITY_CHANGE”的广播。这是一个非定向广播,因此可以在多个应用程序同时接收。 最后,请注意,非定向广播可以在不经过用户许可的情况下发送和接收。这使得它们成为一种潜在的安全风险。因此,您应该只在必要的情况下使用非定向广播,并确保您的应用程序有必要的权限来接收它们。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值