Android Inventory file details (ii)----application Rights statement

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