Android custom access permission

Due to the relatively open design principles of Android, you may use Intent or PackageManager to parse and process sub-classes that call other applications. Therefore, more security processing is required for some applications, ensures internal stability and security of the application.

Stability: If a classification has no numeric value, initialization may fail and Force Close may occur.

Security: when other applications call the SQL database of the program, unexpected losses may occur.

I. Security Protection for Android apps

To consider the security of some internal sensitive data processing, add class ACL access control, of course, more flexible, such as UID, SID, PID and other methods.

1. you can use the SharedPreferences interface to handle some private configuration information or relatively lightweight content, and set it to private MODE_PRIVATE, however, you must note that this method can only be called by this process.

2. for SQLite security issues, the Content Provider's processing permissions can be directly displayed in Android, for example, in androidmanifest. in xml, the read or write permissions are declared. In the Provider node, the android: writePermission or android: readPermission attributes are declared. Of course, other programs can also declare these permissions. In this case, we can use android: the authorities attribute limits access to a class, such as android: authorities = "cn.com. android. cwj ". Eventually similar

<Provider
Android: name = "cwjProvider"
Android: authorities = "cn.com. android. cwj"
Android: writePermission = "cn.com. android. cwj. permission. WRITE_DATABASE"
Android: readPermission = "cn.com. android. cwj. permission. READ_DATABASE"/>

The read/write operations of databases can handle multithreading, but data synchronization can be considered successively. You can set the android: multiprocess = "true" attribute to ensure data correctness, related questions are not covered in this article. We may discuss these issues in future.

3. You can directly use the android: permission attribute for permission declaration of Activity, Service, and referer. The specific method is the same as the above SQLite security. The Demo code is as follows:

<Activity
Android: name = ". cwj"
Android: authorities = "cn.com. android"
Android: permission = "cn.com. android. cwj. permission. ACCESS"/>

Ii. Permission statement

<Permission
Android: name = "cn.com. android. cwj. permission. ACCESS"
Android: protectionLevel = "normal"
Android: label = "@ string/permission_aceess"
Android: description = "@ string/permission_aceess_detail"/>

Of course, there are optional attributes such as android: protectionLevel = "normal" to set protection permissions, and signatures must be signed. Of course, for permission groups, we can declare permissionGroup using permission methods, or directly use the system, such as android: permissionGroup = "android. permission-group.SYSTEM_TOOLS "is ultimately called in other applications and can be displayed in your own manifest. declaration in xml, similar to <uses-permission android: name = "cn.com. android. cwj. permission. ACCESS "/>

Iii. Account Security Statement

Directly declare in the Application in androidmanifest. xml. For example, the standard user permission is similar

Android: sharedUserId = "android. uid. shared". Of course, if you are dealing with RIL, you can declare permissions similar to android. uid. phone to process more sensitive data.

Iv. Service Security

For the Service, in addition to the restricted access package, we can also directly bind the access with parameter judgment to avoid using the android: exported = "true" Export method, of course, you can use the extra method of intent for some simple verification through broadcast communication.

V. PID security problems

PID security issues, by limiting processID access, only allow access in the same process space.

6. android permissionLevel

Android: protectionLevel is set when permissionLevel is defined. There are four optional values:
"Normal"
"Dangerous"
"Signature"
"SignatureOrSystem"
If we define the first two normal or dangerous types, our own applications only need to access the corresponding protected resources in androidManifest. add the same uses-permission to the xml file. If it is signature, we can only add the permission to use it. It must have the same signature at the same time. For signatureOrSystem, not only the same signature, but also the same sharedUserId.