11

Whenever you go to Google's Play Store and install an app, a list of all the necessary access is shown and a confirmation to proceed with the installation is required.

Let's imagine I would like to install Angry Birds:

  • In-app purchases
  • Identity
  • Photos/Media/Files
  • Wifi connection information
  • Device ID & call information

How exactly does Play Store come with this list?

  • Does their algorithm actually analyze the code to come up with that list?
  • Is the vendor responsible to list those needed access?
  • A different way?
12

The security model for Android is that all of the protected resources (Identity, Contacts, Camera, GPS, etc, [Full list of permissions you can request here]) are protected inside the operating system API. That means that an app does not have direct access to the hardware, instead it has to ask the operating system to talk to the hardware for it. That way, the operating system has a chance to check the app's permissions and refuse to give the data.

An Example:

Let's say I write an app that wants access to the GPS location, I have to do two things:

  1. At install time, request the appropriate permissions in the manifest file manifest.xml:

    <manifest ... > <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> ... </manifest>

  2. At runtime, ask the operating system to give me the GPS location:

    String locationProvider = LocationManager.GPS_PROVIDER; Location lastKnownLocation = locationManager.getLastKnownLocation(locationProvider);

During that call to .getLastKnownLocation(...) the operating system will check that my app has the ACCESS_FINE_LOCATION permission. If it does, then it'll hand me back the location data, if not then it'll throw a java.lang.SecurityException and refuse to give me any data.

  • 3
    To be fair, Windows apps also ask the OS to talk to hardware for them too (it's the whole point of an OS). Windows even has mechanisms to enforce security restrictions (ACLs). It's just that historically, those restrictions were set to "wide open". The major difference from a technical standpoint is that on Windows, an app inherits all of the user's access rights, whereas on Android security is handled on a per-app basis. – josh3736 Aug 7 '15 at 17:53
  • @josh3736 Fair, I'll remove that. – Mike Ounsworth Aug 7 '15 at 18:01
  • 1
    @josh3736 because a linux user is created for every app installed. It also makes outstanding isolation between apps which is not available on desktop OSes. – Smit Johnth Sep 12 '17 at 4:29
18

Every permission needs to be declared in the AndriodManifest.xml before an app can use them. For example:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>

to be able to receive SMS.

This manifest will also be used to list the permissions shown when you download the app in the store.

  • Thanks. Is there any kind of double check from Google's side to ensure those apps are really only doing what are they supposed to? – user69377 Aug 7 '15 at 11:57
  • 9
    You can't run the app if you use something that need permissions and isn't declared in the manifest. Which gives the nice SecurityException – BadSkillz Aug 7 '15 at 12:00
  • 2
    @BadSkillz Keep in mind, in Android M and forward, you should be able to annotate code that can request permissions from the user to enable more features in the application at runtime. See developer.android.com/preview/… and tools.android.com/tech-docs/support-annotations – Jared Burrows Aug 7 '15 at 14:18
  • 2
    @BadSkillz a SecurityException isn't necessarily fatal, the app could catch it and continue running. – Mike Ounsworth Aug 7 '15 at 15:34
  • 2
    @MikeOunsworth that's true, but the functionality that caused the security exception still wouldn't execute, so it still wouldn't breach the given permissions. – Woodrow Barlow Aug 7 '15 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy