In Android Permissions grant to application determine the application over all user impact. It not only decides the increase and confidence of user regarding the application working as per it claims but also put a vital questions regarding the stability and security of the mobile device on which it will be installed. In order to put light on permissions demystification , a necessary look at the some important developer consideration regarding the permissions is required. In below cases, it is tried to determine why developers asked for unnecessary permissions. Here, we consider the prevalence of different types of developer Mistakes and considerations caused by use of un wanted Android application permissions.
Android Permission Name
Developers sometimes request permissions with names that sound related to their application functionality, even if the permissions are not required. For example, one application unnecessarily requests the MOUNT_UNMOUNT_FILESYSTEMS permission to receive the android.intent.action. MEDIA_MOUNTED Intent. As another example, the ACCESS_NETWORK_STATE and ACCESS_WIFI_STATE permissions have similar-sounding names, but they are required by different classes. Developers often request them in pairs, even if only one is necessary. Of the applications that unnecessarily request the network permission, 32% legitimately require the WiFi permission. Of the applications that unnecessarily request the WiFi permission, 71% legitimately need the network permission.
Under Commands
An application can send an Intent to another Under Command application, asking the Under Command to perform an operation. If the Under Command makes a permission-protected API call, then the Under Command needs a permission. The sender of the Intent, however, does not. We noticed instances of applications requesting permissions for actions that they asked Under Command applications to do. For example, one application asks the Android Market to install another application. The sender asks for INSTALL_PACKAGES, which it does not need because the Market application does the installation.We find widespread evidence of this type of error. Of the applications that unnecessarily request the CAMERA permission, 81% send an Intent that opens the default Camera application to take a picture. 82% of the applications that unnecessarily request INTERNET send an Intent that opens a URL in the browser. Similarly, 44% of the applications that unnecessarily request CALL_PHONE send an Intent to the default Phone Dialer application.
Related Methods and Stubs
most of the classes contain a mix of permission-protected and unprotected methods. It is observed that applications use unprotected methods but request permissions that are required for other methods in the same class. For example, android.provider. Settings.Secure is a convenience class in the API for accessing the Settings Content Provider. The class includes both setters and getters. The setters require the WRITE_SETTINGS permission, but the getters do not. Two of the applications that are reviewed use only the getters but request the WRITE_SETTINGS permission.
The factor of Copy and Paste
Popular message boards contain Android code snippets and advice about permission requirements. Sometimes this information is inaccurate, and developers who copy it will over privilege their applications.For example, one of the applications that is reviewed registers to receive the android.net.wifi.STATE_CHANGE Intent and requests the ACCESS_WIFI_STATE permission. As of May 2011, the third-highest Google search result for that Intent contains the incorrect assertion that it requires that permission .
Must watch for Deprecated Permissions
Permissions that are unnecessary in Android ver x could be necessary in older Android releases. Old or backwards-compatible applications therefore might have seemingly extra permissions. However, developers may also accidentally use these permissions because they have read out-of-date material. 8% of the over privileged applications request either ACCESS_GPS or ACCESS_LOCATION, which were deprecated in 2008. Of those, all but one specify that their lowest supported API version is higher than the last version that included those permissions.
Testing Artifacts Leftovers
A developer might add a permission during testing and then forget to remove it when the test code is removed. For example, ACCESS_MOCK_LOCATION is typically used only for testing but can be found in released applications. All of the applications in a review data set that un-necessarily include the ACCESS_MOCK_LOCATION permission also include a real location permission.
Signature or System Permissions
It was found that 9% of over privileged applications request unneeded Signature or SignatureOrSystem permissions. Standard versions of Android will silently refuse to grant those permissions to applications that are not signed by the device manufacturer. The permissions were either requested in error, or the developers removed the related code after discovering it did not work on standard handsets.
Permissions a Developer’s Consideration
It can be attributed using many instances of over privilege to developer confusion over the permission system. Confusion over permission names, related methods, deputies, and deprecated permissions could be addressed with improved API documentation. To avoid over privilege due to related methods, it is recommend that the listing permission requirements on a per-method (rather than per-class) basis. Confusion over under command applications could be reduced by clarifying the relationship between permissions and pre-installed system applications.
Despite the number of unnecessary permissions that can be attributed to error, it is possible that some developers request extra permissions intentionally. Developers are encouraged to ask for unnecessary permissions because applications will not receive automatic updates if the updated version of the application requests more permissions .So happy and safe coding.