We know that the various modules of the Android system provide very powerful functions (such as telephones, power supplies and settings, etc.), and by using these features, the application can perform more powerfully and flexibly. However, the use of these features is not unconditional, but requires some permissions. Next, we'll start by explaining another very important point of knowledge-the Application permission statement, which includes the application's permission declarations, custom application access rights, and SDK version qualification.
Permission requests for 1.<uses-permission>--applications
Permissions |
Describe |
Android.permission.ACCESS_NETWORK_STATE |
Allow applications to access network status |
Android.permission.ACCESS_WIFI_STATE |
Allow applications to access Wi-Fi status information |
Com.android.voicemail.permission.ADD_VOICEMALL |
Allow applications to add a voice message to the system |
Android.permission.BATTERY_STATS |
Allow apps to update phone battery stats |
Android.permission.BIND_APPWIDGET |
Allows an application to notify the Appwidget service which application can access appwidget data Launcher is an instance of using this permission |
Android.permission.BLUETOOTH |
Allow an application to connect to a Bluetooth device that is already paired |
Android.permission.BLUETOOTH_ADMIN |
Allow applications to proactively discover and pair Bluetooth devices |
Android.permission.BROADCAST_PACKAGE_REMOVED |
Allow medical programs to send notification that an application package has been uninstalled |
Android.permission.BROADCAST_SMS |
Allow applications to broadcast SMS receipt notifications |
Android.permission.BROADCAST_STICKY |
Allows the application to broadcast sticky Intent. Some broadcast data is placed in the system after its broadcast, so that applications can quickly access their data without waiting for the next broadcast to arrive |
Android.permission.CALL_PHONE |
Allow an application to initialize a phone call |
Android.permission.CAMERA |
Request access to camera equipment |
Android.permission.CHANGE_CONFIGURATION |
Allows the application to modify the current configuration, such as language type, screen orientation, etc. For example, our Setup module uses this permission |
Android.permission.CHANGE_NEWWORK_STATE |
Allow applications to change connection status |
Android.permission.CHANGE_WIFI_STATE |
Allow applications to change Wi-Fi connection status |
Android.permission.DEVICE_POWER |
Allow applications to access the underlying device power management |
Android.permission.EXPAND_STATUS_BAR |
Allow applications to expand or close the status bar |
Android.permission.INSTALL_LOCATION_PROVIDER |
Allows an application to install a data provider into the local manager |
Android.permission.INSTALL_PACKAGES |
Allow an application to install another application |
Android.permission.INTERNET |
Allows the application to open the network. If you want to develop a network-related application, you should first consider whether you need this permission |
Android.permission.KILL_BACKGROUND_PROCESSES |
Allow the application to call the Killbackgroundprocesses () method |
Android.permission.MODIFY_PHONE_STATE |
Allows you to modify phone status, but does not include making calls |
Android.permission.MOUNT_FORMAT_FILESYSTEMS |
Allow applications to format removable external storage devices |
Android.permission.MOUNT_UNMOUNT_FILESYSTEMS |
Allow applications to mount or unload external storage devices |
Android.permission.NFC |
Allow applications to perform NFC input and output operations |
Android.permission.READ_CALENDAR |
Allow applications to read calendar data |
Android.permission.READ_CONTACTS |
Allow app West to read contact data |
Android.permission.READ_PHONE_STATE |
Allow applications to access phone status |
Android.permission.READ_SMS |
Allow applications to access SMS messages |
Android.permission.RECEIVE_BOOT_COMPLETED |
Allow applications to receive Android.intent.action.BOOT_COMPLETED broadcasts after the system completes |
Android.permission.RECEIVE_MMS |
Allow applications to monitor MMS |
Android.permission.RECEIVE_SMS |
Allow applications to monitor SMS |
Android.permission.RECEIVE_WAP_PUSH |
Allows applications to monitor WAP push information |
Android.permission.SEND_SMS |
Allow applications to proactively send short messages |
Android.permission.SET_TIME |
Allow application to set system time |
Android.permission.SET_TIME_ZONE |
Allow the application to set the system time zone |
Android.permission.SET_WALLPAPER |
Allow application settings Desktop wallpaper |
Android.permission.STATUS_BAR |
Allows the application to operate (open, close, disable) the status bar and its icon |
Android.permission.VIBRATE |
Allow applications to allow applications to access vibrating devices |
Android.permission.WAKE_LOCK |
Allow applications to use the Power Manager's screen lock feature |
Android.permission.WRITE_CALENDAR |
Allows the user to write calendar data. If we only apply for this permission, then we have only write permission to the calendar data and no Read permission |
Android.permission.WRITE_CONTACTS |
Allow the user to write to the contact data, if we only apply for this permission, then we have only write access to the contact data, no Read permission |
Android.permission.WRITE_EXTERNAL_STORAGE |
Allow applications to write data to external storage devices |
Android.permission.WRITE_SETTINGS |
Allow applications to read and write system settings |
Android.permission.WRITE_SMS |
Allow applications to write text messages |
The application may need some of the permissions shown in the table above in different scenarios, such as when we need to use the SD card, we need to apply for the SD card permissions. Let's take a few examples to explain the problem.
In this example, we will retrofit the HelloWorld application and add a text file named "Abc.txt" at the root of the sdcard. Because you need to access an external storage device, you need to request Android.permission.WRITE_EXTERNAL_STORAGE permissions, or the code will fail. The specific steps are shown below.
① needs to add the appropriate permissions in the Androidmanifest.xml file of the HelloWorld application, as shown in the following code:
<uses-permission android:name= "Android.permission.WRITE_EXTERNAL_STORAGE"/>
② to add some code to create the file in the original code, as follows:
public class Mainactivity extends Fragmentactivity {private static final String sdcard= Environment.getexternalstorage Directory () +file.separator; @Override protected void OnCreate (Bundle savedinstancestate) {super.oncreate (savedinstancestate); Setcontentview (R.layout.activity_main); if (savedinstancestate==null) {Getsupportfragmentmanager (). BeginTransaction (). Add (Android. R.id.content,new filefragment ()). commit (); }} public static class Filefragment extends Fragment {public filefragment () {} @Override Publi C View Oncreateview (Layoutinflater inflater, ViewGroup container, Bundle savedinstancestate) {View View=inflat Er.inflate (R.layout.file_fragment,container,false); Button mybut= (button) View.findviewbyid (r.id.mybut); Mybut.setonclicklistener (New View.onclicklistener () {@Override public void OnClick (View v) {File sdcardfile=new File (sdcard+ "Abc.txt"); try {sdcardfile.createnewfile (); } catch (IOException e) {e.printstacktrace (); } } }); return view; } }}
③ start the program, at this time in the SDcard linked directory, we will find that the Abc.txt file has been established, as shown in.
Finally, we will do an experiment, the <uses-permission> node in the Androidmanifest.xml file is deleted, in the same directory and did not find the created file, so that after the operation, we can find some exception information in the log, as shown in.
From the log we can find that the program throws a Java.io.IOException exception, and prompts "Permission denied", where it happened, exactly where the file was created. Therefore, we can draw a conclusion that when trying to read and write external storage devices, you must first apply for Android.permission.WRITE_EXTERNAL_STORAGE this permission, or the program throws a warning exception, the related operation can not be done.
Android offers a rich range of hardware and software modules that enable applications to become powerful and easier to develop, but before using it, you must request the necessary permissions for your application. This is very important, otherwise the application will have an inexplicable error.
As seen in the previous example, if you do not have the appropriate permissions to create the file, and the program does not display an exception prompt, then we may have to spend a lot of time to find the source of the problem.
Therefore, I recommend that you carefully analyze the requirements before development, analysis of why the application function, and whether these kinetic energy needs permission to access.
2.<permission> node--Customizing the access rights of the application
Before we learned how to use permissions. In fact, an application can define its own permissions to restrict access to special components or features of the application or other applications, in addition to the permissions it can use. Here, let's learn about the role of the <permission> node-how to declare your own permissions.
Manually add a <permission> node to the Androidmanifest.xml file, which can only be included under the <manifest> node with the following syntax:
<permission android:description= "string resource"
android:icon= "Drawable Resource"
android:logo= "Drawable Resource"
Android:label= "String Resource"
Android:name= "string"
Android:permissiongroup= "string"
android:protectionlevel=["Normal" | " Dangerous "|" Signature "|" Signatureorsystem "]/>
In the above code, the following 3 properties are required.
①android:name: Name of the claim permission. This name must be unique, so you should use Java-style naming, such as Com.test.permission.TEST.
②android:permissiongroup: Claims permissions belong to which permission group, this permission group can be either Android precompiled or custom. The following table lists the system permission groups that are precompiled in addition to the Android system.
Permission Group name |
Describe |
Android.permission-group.accounts |
For direct access to accounts managed by the account Manager |
Android.permission-group.cost_money |
A privilege that allows users to spend money without having to participate directly |
Android.permission-group.development_tools |
Permission groups related to development features |
Android.permission-group.hardware_controls |
Permissions to provide direct access to device hardware |
Android.permission-group.location |
Permission to allow users to access the user's current location |
Android.permission-group.messages |
Permission to allow an application to send information on behalf of a user or to intercept information received by a user |
Android.permission-group.network |
Applies to providing access to network services |
Android.permission-group.personal_info |
Applies to provide access to users ' private data, such as Contacts, calendar events, and e-mail messages |
Android.permission-group.phone_calls |
Applies to the ability to associate access and modify phone status, such as intercepting power, reading and modifying the status of the phone |
Android.permission-group.storage |
Permission groups related to SD card access |
Android.permission-group.system_tools |
Permission groups related to the system API |
③android:protectionlevel: Describes the potential risk implied in a permission, which can be a string in the following table.
Value |
Significance |
Normal |
The default value. Low-risk permissions that enable the requesting application to access orphaned application-level features, bringing minimal risk to other applications, systems, or users. When the system is installed, this type of permission is automatically granted to the requesting application without the user's explicit declaration. |
Dangerous |
High-risk permissions, which conceal things the requested application to access the user's private data or to control devices that adversely affect the user. Because of the potential risk of this permission, the system may not be automatically assigned to the requested application. For example, any dangerous permission that is requested by an application may be displayed to the user and is required to be acknowledged before processing. For example, the following permissions belong to this type of permission. <permission android:name= "Android.permission.RECEIVE_SMS" android:permissiongroup= "Android.permission-group.messages" android:protectionlevel= "Dangerous"/> If the application uses this permission, it may cause other applications to be unable to receive SMS notifications, at which point we think it is dangerous to use this permission. |
Signature |
The signature level. The system grants this permission only when the requesting application uses the same signature as the claims permission. If the authentication matches, the system does not notify the user or can automatically authorize without the user's explicit approval. |
Signatureorsystem |
Signature or system level. The system simply grants it to an application in an image file (*.img file) of an Android system, or to an application with the same authentication signature in the system image. In general, avoid using this option as much as possible because the signature protection hierarchy should meet most requirements and engineering, regardless of where the application is exactly installed. Signatureorsystem permissions apply to specific special environments in which multiple vendors have built applications into system images and need to explicitly share specific characteristics. |
In the <permission> node, in addition to the 3 properties described above, there are other properties that are only available for readability and are not described in detail here.
In applications provided by Android, some have defined their own permissions, such as launcher. The following code fragment uses Launcher's androidmanifest.xml fragment to illustrate how to manually declare your own permissions:
<permission
Android:name= "Com.android.launcher.permission.install_short-cut"
android:permissiongroup= "Android.permission-group.system_tools"
Android:protectionlevel= "Normal"
Android:label= "@string/permlab_install_shortcut"
android:description= "@string/perdesc_install_shortcut"/>
Because the ability to claim permissions is less frequently used, readers need to think about the need to declare their permissions when developing applications.
3.<uses-sdk> Node--SDK version qualification
As we all know, the software for the platform version is certain requirements. If the platform version can meet the requirements of software operation, it can guarantee the stability of the software. For example, it is known that NFC functionality cannot be run in Android 1.5, and if you are developing an application with similar functionality, you must have a requirement for your platform, and the <uses-sdk> node is designed to meet that need.
The <uses-sdk> node uses an integer value to express the compatibility of the application with one or more versions of the Android platform. It is important to note that these integer values represent the API level. The API level given by the application will be compared with the API level of a given Android system. Of course, for different Android devices, this may be different. It is necessary to note that this node is used to specify the API level, not the version number of the SDK or the Android platform.
The code that uses this node is as follows:
<USES-SDK android:minsdkversion= "Integer"
android:targetsdkversion= "Integer"
android:maxsdkversion= "integer"/>
①android:minsdkversion: Used to specify the minimum API level required to run the application. If the system's API level is smaller than the value specified by the attribute, the Android system will prevent users from installing the app. In most cases, this property should be specified. If this property is not specified, the value of this property is assumed to be "1".
②android:targetsdkversion: Used to specify the target API level for the application.
③android:maxsdkversion: Specifies the maximum API level.
4.<instrumentation> node--Application Monitor
The <instrumentation> node is used to monitor the application's interaction with the system, which is instantiated before the application component is instantiated. This node is used in most cases for unit testing. The syntax structure is as follows:
<instrumentation android:functionaltest=["true" | " False "]
Android:handleprofiling=["true" | " False "]
android:icon= "Drawable Resource"
Android:label= "String Resource"
Android:name= "string"
Android:targetpackage= "string" >
These properties are described in detail below:
①android:functionaltest: Identifies whether this instrumentation class is run as a functional test, and its default value is False.
②android:handleprofiling: Identifies whether this instrumentation object turns on and off profiling, and its default value is False.
③android:icon: This property represents the icon for this instrumentation class
④android:label: This property is the title of the instrumentation class.
⑤android:name: This property is the name of the instrumentation subclass and is the Java-style name for a class, such as Com.example.liyuanjinglyj.myInstrumentation.
⑥android:targetpackage: This property is the target application name that needs to be monitored from the Package property value of the <manifest> node in the target application androidmanifest.xml.
Of course, there is a need to create a test project specifically for Eclipse, but also to configure this node, but not in Android studio, considering that Google no longer supports eclipse at the end of 2015, so only the Android studio unit tests are explained, This is explained by the fact that Eclipse still has a large number of developers to use, so it explains the details of the node.
Here's an example of how to do unit testing:
① create a project and still experiment with the HelloWorld we've been using, you'll find a test package in the project directory:
② Right click on this package, select the New-class menu item, new myfirsttest inherit from Activityinstrumentationtestcase2<t>, as shown in:
Package Com.example.liyuanjing.helloworld;import android.test.activityinstrumentationtestcase2;/** * Created by Liyuanjing on 2015/7/14. */public class Myfirsttest extends activityinstrumentationtestcase2<mainactivity>{public myfirsttest () { super (Mainactivity.class);} }
In this code, the <T> in,activityinstrumentationtestcase2<t> is replaced with the class we tested, because we're going to test mainactivity so we'll replace it with this one.
③ We test content, enter some characters in the edit box, when the button is clicked, the text box equals the string entered by the edit box, the Mainactivity code is as follows:
public class Mainactivity extends Fragmentactivity {private static final String sdcard= Environment.getexternalstorage Directory () +file.separator; Private filefragment filefragment=new filefragment (); @Override protected void OnCreate (Bundle savedinstancestate) {super.oncreate (savedinstancestate); Setcontentview (R.layout.activity_main); if (savedinstancestate==null) {Getsupportfragmentmanager (). BeginTransaction (). Add (Android. r.id.content,filefragment). commit (); }} public static class Filefragment extends Fragment {private View mrootview; Public filefragment () {} @Override public View oncreateview (layoutinflater inflater, ViewGroup container, Bun Dle savedinstancestate) {View view=inflater.inflate (r.layout.file_fragment,container,false); Final EditText myedit= (EditText) View.findviewbyid (R.id.myedit); Final TextView content= (TextView) View.findviewbyid (r.id.content); Button mybut= (button) View.findviewbyid (r.id.mybut); Mybut.setonclicklistener (New View.onclicklistener () {@Override public void OnClick (View v) {Content.settext (Myedit.gettext (). toString ()); } }); This.mrootview=view; return view; Public View Getrootview () {return this.mrootview; }} public Filefragment getfragment () {return filefragment; }}
The code for the test class is as follows:
public class Myfirsttest extends activityinstrumentationtestcase2<mainactivity>{private TextView content; Private EditText Myedit; Private Button mybut; Private Mainactivity mainactivity; Public Myfirsttest () {super (Mainactivity.class); } @Override protected void SetUp () throws Exception {Super.setup (); This.mainactivity= (mainactivity) getactivity (); This.content= (TextView) this.mainActivity.getFragment (). Getrootview (). Findviewbyid (r.id.content); this.myedit= (EditText) this.mainActivity.getFragment (). Getrootview (). Findviewbyid (R.id.myedit); this.mybut= (Button) this.mainActivity.getFragment (). Getrootview (). Findviewbyid (R.id.mybut); } public void Testbuttonclick () {getinstrumentation (). Sendcharactersync (Keyevent.keycode_h); Getinstrumentation (). Sendcharactersync (Keyevent.keycode_e); Getinstrumentation (). Sendcharactersync (keyevent.keycode_l); Getinstrumentation (). Sendcharactersync (KeyevEnt. keycode_l); Getinstrumentation (). Sendcharactersync (Keyevent.keycode_o); Getinstrumentation (). Waitforidlesync (); Getinstrumentation (). Runonmainsync (New Runnable () {@Override public void run () {MyB Ut.performclick (); } }); Getinstrumentation (). Waitforidlesync (); Systemclock.sleep (1000); Assertequals (This.content.getText (). ToString (), This.myEdit.getText (). ToString ()); }}
Attention:
Ⅰ in the construction of the Myfirsttest class, the myfirsttest is associated with the activity because it specifies the details of the activity of the project being tested.
The Ⅱsetup () method is an overriding method that makes the necessary settings before testing, such as instantiating some objects, opening the network, and so on, which appear in pairs with the teardown () method. Here we do not implement the Teardown () method, and when the test is complete, the framework will automatically callback the base class, which is the teardown () method.
Finally, run the test class as shown in:
When the system finishes testing, you can get the results shown in the Android Studio integrated development Environment:
As can be seen in the diagram, the test test class is written with a return value of OK, which proves that the tests have achieved the intended purpose.
Android Inventory file details (ii)----application Rights statement