CODEWITHSUNDEEP
androidwear-osandroid-wear-data-api
Jarett Millard
Jarett Millard

Reputation: 5958

Permissions for a WearableListenerService

I've implemented a WearableListenerService in both my main app and the companion Wear app. In the manifests, the service needs to be declared as android:exported="true" (or not declared at all and left to default to true) since it's started by Google Play Services. An exported service with no permissions can be called by any app on the system, but I can't find the correct permission to add to the service declaration to secure it. I've looked through the permissions on both the phone and the Wear device with pm list permissions but I don't see anything that looks like what I need.

  1. Is there a permission that I can/should add to secure my services?
  2. If not, is it a good idea to manually secure the service by checking the package name of the caller?

Upvotes: 5

Views: 4023

Answers (2)

Volo
Volo

Reputation: 29438

  1. Is there a permission that I can/should add to secure my services?
  2. If not, is it a good idea to manually secure the service by checking the package name of the caller?

You don't need to worry about securing your WearableListenerService implementation with permissions or caller package checks. As @Wayne pointed in his answer: there is a security check that happens in the framework. This check is done in the WearableListenerService base class. You can find further security analysis of the Wearable SDK in the following article: https://labs.mwrinfosecurity.com/blog/android-wear-security-analysis. Here is the quote from it:

The method pr() first checks if com.google.android.gms is Google signed and then calls cU() to check if the calling process UID is for the package com.google.android.gms (the Google Play Service package). If the class is further decompiled, it can be seen that this security check happens in each method exposed in WearableListenerService.

 

Unfortunately currently Lint checker produces false positive warning for the wearable listener service declaration whenever it doesn't contain BIND_LISTENER filter (which inclusion produces other warning since it's now deprecated and should be avoided):

Exported services should define a permission that an entity must have in order to launch the service or bind to it. Without this, any application can use this service.

This is certainly a bug in the security detector code (it just wasn't updated when BIND_LISTENER intent became deprecated). I've opened an issue regarding this on the Android bug tracker. Meanwhile to get rid of the warning one needs to add tools:ignore="ExportedService" to its wearable listener service declaration.

Upvotes: 3

Wayne Piekarski
Wayne Piekarski

Reputation: 3232

The best way to see how to implement a WearableListenerService on Android Wear is to look at one of the existing samples provided by the SDK. If you look at the DataLayer sample included at $SDK/samples/android-20/wearable/DataLayer it has a full implementation of what you are wanting to do.

If you look in the AndroidManifest.xml for the wearable side, you can see it has the following:

    <meta-data
            android:name="com.google.android.gms.version"
            android:value="@integer/google_play_services_version" />

    <service
            android:name=".DataLayerListenerService" >
        <intent-filter>
            <action android:name="com.google.android.gms.wearable.BIND_LISTENER" />
        </intent-filter>
    </service>

For your security concerns ... When we declare a service in manifest and add a filter to it, it automatically becomes an exported service. So in general, other apps can bind to that service. In case of WearableListenerService, there is a security check that happens in the framework to make sure that the agent binding to that is Google Play Services so no one else can really bind to that service, unless the app developer exposes other intent filters in which case the intention is for others to access it.

So if you implement your code in the same way as the Wear SDK samples, your app should be secure and you do not need to worry about any extra permissions, etc.

Upvotes: 10

Related Questions