Do I need android.permission.WAKE_LOCK for Google Play Services if I only release in Google Play Store?

Question

I am trying to integrate Google Analytics for Android. As per the documentation here, it asks to add android.permission.WAKE_LOCK (provides the comment note below). I dont understand it clearly. If I am releasing the app ONLY in the Google Play Store, do I still need this?

I really do not want to ask users for an additional permission if this is not absolutely necessary.

<!-- Optional permission for reliable local dispatching on non-Google Play devices -->
<uses-permission android:name="android.permission.WAKE_LOCK" />

In particular, I do not understand what this note actually means here:

Optionally a WAKE_LOCK permission can be requested to improve dispatching on non-Google Play devices.

Otorhinolaryngology

It says "Optional Permission". – Guppy

@Guppy Yes I understand that, just not clear on why and how does it help? – Otorhinolaryngology

I'm not sure how it helps with non-google stores, but that seems besides the question. If they're saying that it's optional and used for something that you don't plan to need, I'd say it's safe to say you can disregard it. Note many apps in the store don't have wake-lock permissions. – Guppy

Answer 1

WAKE_LOCK

Allows using PowerManager WakeLocks to keep processor from sleeping or screen from dimming.

On Google Play devices, a background service is almost always running as "Google Play Services", so WAKE_LOCK is not required.

On non-Google Play devices, WAKE_LOCK helps keeping the dispatching process / service of Google Analytics alive so it has more chances to report / upload data.

EDIT

Also, it is unclear what happens to dangerous permissions in permission groups that are not ones that the user can control via Settings, such as SYSTEM_TOOLS.

https://commonsware.com/blog/2015/06/02/random-musings-m-developer-preview-bad.html

Amygdala

Answer 2

Update: As of Android 6 (API level 23, WAKE_LOCK is classed as a "normal" permission, meaning the permission is automatically granted. Removing the WAKE_LOCK permission will often cause apps to crash (see below) so I would avoid doing it.

---

I'm in the same position. I don't want to add an extra permission as it will significantly reduce the number of people using the latest version of the app (as new permissions mean the user must explicitly opt in to receive the app update).

I believe I have managed to find a solution by combining a few of the answers on this SO question.

First, add "tools" namespace to the app's manifest

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:tools="http://schemas.android.com/tools">

Second, add the "WAKE_LOCK" permission but use the remove option

<uses-permission android:name="android.permission.WAKE_LOCK" tools:node="remove" />

Now, when I upload a new APK I can see the permission is no longer required:

Important

It seems like this solution may no longer be viable. I'm now getting a huge number of RuntimeExceptions being thrown with the message "Neither user 10182 nor current process has android.permission.WAKE_LOCK."

Fatal Exception: java.lang.RuntimeException
Unable to start receiver com.google.android.gms.measurement.AppMeasurementReceiver: java.lang.SecurityException: Neither user 10182 nor current process has android.permission.WAKE_LOCK.

Lotty

This technique works for me. Also for new permissions which is not at Manifest but show at upload time. – Lolita

This is an awesome answer. It would be good if Google can document how to avoid using the wake-lock permission. – Frizz

Good answer, thanks a lot. Btw. Google actually did document these flags. As far as I understand this is coming from some google library (like google play services for example) and is generated by the manifest-merger in Android Studio. The related docs can be found at tools.android.com/tech-docs/new-build-system/user-guide/… – Joseph

Indeed, they're documented and marked as optional. The problem is that they're automatically included in the project. Given that the permissions are optional, you'd assume Google would expect developers to opt in. developers.google.com/android/reference/com/google/android/gms/… – Lotty

I suspect you only need to add the tools:node="remove" attribute when you're merging manifests; e.g., with app libraries or different product flavours. See tools.android.com/tech-docs/new-build-system/user-guide/… . So, if you're not merging manifests all you need to do is simply delete the whole <uses-permission android:name="android.permission.WAKE_LOCK" /> entry. – Ubiety

Yes, that's the problem. The manifests get merged and the wake lock permission is automatically added (for apps installed outside of Google Play, I believe). If it's a permission in your own app then, yes, you can just delete it. However, this permission is specified in Google's code and can't easily be changed (you probably wouldn't want to either). – Lotty

I had originally added the permission manually myself. However when I deleted the entry in the manifest and then uploaded the signed apk to Google Play I saw the WAKE_LOCK permission still got merged in anyway. It probably came from some library I'd since added. So I ended up having to use the tools:node="remove" attribute anyway:). – Ubiety

@Lotty what are you doing for the crashes? I'm also getting a lot of crashes for this reason, for removing the wake lock permission. It's crazy to see that the app is crashing because of analytics in google play services. – Rhinarium

@droidster I had to add the WAKE_LOCK permission back in. It's not quite as bad as I first thought though. As of Android 6 (API Level 23) WAKE_LOCK is considered to be a "normal" permission which means the user doesn't need to grant permission. Of course, that's not much use at the moment as most people are using older versions of the OS. However, it should become less of an issue over time. developer.android.com/guide/topics/security/… – Lotty

@Lotty thanks for the quick response. So do you suggest I should add this permission? Above 50% of my users are on 6.0+ but there are still a significant number of people on older versions. I wish there was a way to stop the analytics to send data in background if play service isn't present. I think that's how they did it before, don't know why they changed it. – Rhinarium

@droidster Yes, I think it's probably the best option. Especially if more than 50% of your users on Android 6 (mine is only 28%). – Lotty

@Lotty Thanks for sharing mate! This helps. I'll try to get in touch with someone in the play services team and update here. – Rhinarium

"Neither user # nor current process has android.permission.WAKE_LOCK." Any solution for no permission crash above? – Domino

@Domino Personally, I wouldn't bother doing this as WAKE_LOCK is automatically granted on Android 6 and above (more details at the top of the issue). I suppose it depends on your user base though (i.e. whether you have a lot of users running old versions of Android). – Lotty

@Lotty thank you for reply, 46% of our users are above Android 6. – Domino

Answer 3

When removing WAKE_LOCK, also remove AnalyticsReceiver and AnalyticsService.

That way is written on this site. http://coffeee.hatenablog.com/entry/2017/11/26/035828

1. open AndroidManifest.xml
2. click the tab of "Marged Manifest"
3. right click on WAKE_LOCK and remove
4. remove AnalyticsReceiver and AnalyticsService

Good Luck

Cardsharp