Applications use a lot of permissions including those needed to access the SD card, use the Internet and so on. Google does a great job of displaying what permissions an app uses before installing, but does not go into full detail about what exactly those permissions do.
Why does Android have permissions and how are they implemented
The sky is the limit when comes to ideas and what is possible with Android apps. Knowing this Google added permissions that need to be defined before the app is allowed to do certain things like access the Internet for example. This stops apps from doing whatever they want without the user's knowledge. When installing an app from the Google Play Store, a dialog box pops up and the user has to agree that the app can do certain things. Permissions are handled by the Android API framework in the system process. This calls the permission validation mechanism to check that the application has the permission to do what it is trying to do. Some permissions, like BLUETOOTH are handled by the Linux kernel. All of the API calling happens automatically so the developer does not have to worry about making sure the permissions are handled correctly.
What are the app permissions?
Google provides 17 different permissions developers can use in their apps. The details for each are listed here:
- In-app Purchases – The application offers ways to purchase content inside the app itself. For example, an in-game currency. This will needed to be added to the Androidmanifest to use this permission.
<uses-permission android:name="com.android.vending.BILLING" /> - Device and app history – An app may be able to do read sensitive log data, read web bookmarks and history, retrieve apps and retrieve system internal state. The last one is caused by the android.permission.DUMP which allows the app to retrieve state dump information from system services. This can reveal very sensitive information about the device using the app. All of these permissions deal with device and app history.
<uses-permission android:name="android.permission.READ_LOGS"/>
<uses-permission android:name="android.permission.DUMP"/>
<uses-permission android:name="android.permission.READ_HISTORY_BOOKMARKS"/>
<uses-permission android:name="android.permission.GET_TASKS"/> - Cellular data settings – The app can control the device's mobile network settings and possibly intercept the data received. Here are some examples of the permissions needed.
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE"/>
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> - Identity – With this permission the app can find accounts on the device, see and modify the owner's contact card and add or remove contacts from the device. The permission group CONTACTS deals with the user's contacts while ACCOUNT_MANAGER deals with the user's accounts.
<uses-permission android:name="android.permission-group.CONTACTS"/>
<uses-permission android:name="android.permission.ACCOUNT_MANAGER"/> - Contacts – This permission is similar to last one, however, this one can only access contacts on the device, however, it still has the ability to read and modify them. Googel has put all the permissions neatly into this permissions group.
<uses-permission android:name="android.permission-group.CONTACTS"/> - Calendar – This permission allows the app to access the user's calendar and events, even if they include confidential information. This also includes the app being able to make events and send emails to guests without the user's knowledge. This can be dangerous, this is the permission group needed.
<uses-permission android:name="android.permission-group.CALENDAR"/> - Location – An app can use the device's location. This includes two different location settings, approximate and precise. Using the approximate location option, the app gets the device's location from the network, and the precise option uses the device's GPS and network to determine the location. To do this, the permission allows the app to access extra location provider commands and GPS.
<uses-permission android:name="android.permission-group.LOCATION"/> - SMS – The app can use the device's SMS and MMS services. This includes the ability to receive text messages (SMS, WAP), read SMS and MMS, edit SMS and MMS, and send SMS and MMS. This can cost money.
<uses-permission android:name="android.permission-group.SMS"/> - Phone – The app can directly call phone numbers. Read and write the call log, reroute outgoing calls, modify phone state and make calls without the user knowing. Like the SMS permission, this can cost money. This permission group handles everything that has to do with telephony features.
<uses-permission android:name="android.permission-group.PHONE"/> - Photos/Media/Files – The application has the ability to use the file on the device with the application installed. This includes reading and writing to the SD card and USB storage. The app can also mount and unmount external storage as well as format external storage. This permission deals with reading external storage on newer devices.
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission-group.STORAGE"/> - Camera – The app has the ability to take pictures and video. This may occur with or without the user's permission or knowledge.
<uses-permission android:name="android.permission-group.CAMERA"/> - Microphone – The app can use the device's microphone, this may include recording audio. This may happen with or without the user's permission.
<uses-permission android:name="android.permission-group.MICROPHONE"/> - Wi-Fi connection information – The app can access the device's Wi-Fi connection information including whether or not Wi-Fi is turned off as well as connected devices.
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE"/>
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/> - Bluetooth connection information – The application can control Bluetooth which includes sending and receiving data from nearby devices.
<uses-permission android:name="android.permission.BLUETOOTH"/> - Wearable sensors/activity data – The device is able to access information from a wearable device. For example, getting heart rate information from an Android Wear device.
<uses-permission android:name="android.permission.BODY_SENSORS"/> - Device ID & call information – An app can access the device ID, phone number, whether the device is making a call, and the number connected on the other end of the call.
<uses-permission android:name="android.permission.READ_PHONE_STATE"/> - Other – If a function of an app does not fit inside one of the other permissions, there is the ability to add an "other" permission. This may include using social media streams and the like. If this is included as a permission, users will have to approve every update of the application.
How to implement permissions into an app
All of the permissions are controlled in the Androidmanifest. Here is an example of some permissions being declared in the Androidmanifest:
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<!-- watch permission -->
<uses-permission android:name="com.google.android.permission.PROVIDE_BACKGROUND" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.WAKE_LOCK" />
These permissions are used to get the weather from the device and relay the information to an Android Wear device. Google offers documentation for developers to use to determine what permissions should be used. Declaring permissions should happen in the Androidmanifest in the format provided in the image. In the sample code posted, it is not necessary to include watch permissions, they are only required if the app works with Android Wear.
How Android Marshmallow changes permission handling
Way back in the day Google added a feature in Android 4.3 that let the user control what permissions apps could access on a per app basis known as App Ops. This was a great feature that cut down on privacy issues and gave users the piece of mind knowing that random apps installed could not access the device's location for example. Unfortunately, this was removed in Android 4.4 and hasn't made an official return, until now. When Google introduced Android 6.0 Marshmallow, everyone was excited to see that App Ops would be making a comeback. 3This time around it's a little different however.
This time when an app needs to use a permission a dialog box pops up on the screen and asks the user if it is OK that the app uses a certain permission. This may get a little annoying, but at least every permission used by an app has to go through the user first. The same can be said for Nougat, which follows the app permission style first introduced by Marshmallow.
Wrap-up
There are a lot of permissions that developers can use to make their apps function as they should. Most of the permissions are harmless, while some can access quite a bit of information. With the return of App Ops in Android Marshmallow, it should be easy to control what apps can use what permissions. From a developer standpoint, it is not difficult to implement whatever permissions are needed for the app. Make sure to pay attention to the permissions when installing apps, that way the apps installed on your device can only access what you want them to.
from Android Authority http://ift.tt/1WmQqDD
via IFTTT
No comments:
Post a Comment