My very simple app currently does not ask the user for any permissions at all when they install it. I want to keep it this way but I really need to add a widget.
I was looking over the StackWidget Example (http://docs.huihoo.com/android/3.0/resources/samples/StackWidget/) and I noticed that in the manifest they have:
<service android:name="StackWidgetService"
android:permission="android.permission.BIND_REMOTEVIEWS"
android:exported="false" />
That permission there "BIND_REMOVEVIEWS", I haven't seen before. If I were to build off of this example and include that service with that permission, will the user now be notified that my app requires a permission before it can be installed/updated?
No.
<uses-permission> elements are what trigger the user to be notified about permissions that your app is requesting.
android:permission indicates that you are defending a component with a permission that some other app (or, in this case, the firmware) must hold. Since you are not requesting the user grant you a permission, the user is not bothered with the android:permission attribute.
So:
<uses-permission android:name="com.commonsware.permission.SHAVE_YAK" /> is asking the user "may I shave your yak?"
android:permission="com.commonsware.permission.SHAVE_YAK" is telling a third-party app "the user must have agreed to allow you to shave the user's yak"
note: no actual yaks were harmed in the creation of this answer
Related
I've added this to my manifest:
<uses-permission android:name="android.permission.VIBRATE" />
I am wondering whether this will disable auto update for my current users.
This question says asking for redundant permissions will not require manual update. So I wonder will VIBRATE prevent auto update?
It will still auto update. The permission android.permission.VIBRATE is not a dangerous permission, and even if it were you would only have to ensure you are correctly requesting that permission when required.
From this google support page
For apps built for Android 6.0 and up: You won't need to review or accept permission changes for the app to update. The first time you use a feature that uses a new permission, you can allow or deny the use of that data or capability.
I notice FCM needs an Android wake lock permission. Could I remove the wake lock permission using?
<uses-permission android:name="android.permission.WAKE_LOCK" tools:node="remove" />
or will it disrupt receiving the data/notification payload?
I was reviewing this topic and started wondering if its needed. I remember in GCM its mandatory.
The other question I have is since wake lock is not a dangerous permission, I think on and after API 23, users won't even see or know about this permission as it will be transparent. Even the Play Store will not show them that the app needs a wake lock, is that right?
Referring to the GCM docs, the WAKE_LOCK permission seems to have been only optional and not mandatory:
Optionally, the android.permission.WAKE_LOCK permission if the application needs to keep the processor from sleeping when a message is received.
And nothing is stated in the FCM docs that WAKE_LOCK is needed in some way.
And yes, the app will not show that it needs WAKE_LOCK. For permissions with Normal Protection levels (docs):
If an app declares that it needs a normal permission, the system automatically grants the permission to the app.
While AL's answer is correct, I would like to add that on the Play Store listing for the app, it shows the permission under the category "Other":
I couldn't add the picture in a comment, so I was forced to create an answer.
As the guide from google states out, there are normal, dangerous and special permissions.
Dangerous are, as far as I understand, disabled as default (is this true?).
If an app declares that it needs a dangerous permission, the user has to explicitly grant the permission to the app.
Does this infect also updates or only new installs?
And what exactly is the difference between the dangerous permission and
the special permissions?
Android says for special permissions:
Special Permissions
There are a couple of permissions that don't behave like normal and dangerous permissions. SYSTEM_ALERT_WINDOW and WRITE_SETTINGS are particularly sensitive, so most apps should not use them. If an app needs one of these permissions, it must declare the permission in the manifest, and send an intent requesting the user's authorization. The system responds to the intent by showing a detailed management screen to the user.
Is that not the same like the quote above? I do not get the difference.
Thanks!
System permissions are divided into two categories, normal and dangerous:
Normal permissions do not directly risk the user's privacy. If your
app lists a normal permission in its manifest, the system grants the
permission automatically.
Dangerous permissions can give the app access to the user's
confidential data. If your app lists a normal permission in its
manifest, the system grants the permission automatically. If you
list a dangerous permission, the user has to explicitly give
approval to your app.
Ques : Dangerous are, as far as I understand, disabled as default (is this true?).
Ans : Yes Dangerous permissions will be disabled by default.
Ques : Does this infect also updates or only new installs?
Ans : There are Two cases
Case 1 : App Targeting & running on API Level 23
If your app is targeting API Level 23, then all the permission which are defined in the Android Manifest will now ask for a permission when they need it.
For example, instead of giving an app access to your camera when you install it, you’ll be prompted the first time the app wants to access your camera.
Case 2 : App Designed for Older Version
Older Android apps automatically get these permissions when you install them, but you can revoke any permission you want from Settings >> Apps >> App >>App Info >> Permissions.
http://developer.android.com/training/permissions/requesting.html
Dangerous
Basically Google decided to mark some permissions dangerous (see full list here). Those permissions need to be requested actively if you want to use them, so you can't just put them in the manifest and expect everything to work, it wont. But if the user gives access once, you can use that permission for the remainder of the applications life (unless the user goes in and clicks it off inside settings).
The request will open a dialog on top of your app where the user can decide if you are allowed the permission.
Special
Special are like dangerous, except even harder to use. In order to use special you have to start an intent requesting the permission so the user goes to a Google defined activity that manages everything.
This is how it works for apps targeting Android 6.0 and onward.
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.
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.
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
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
open AndroidManifest.xml
click the tab of "Marged Manifest"
right click on WAKE_LOCK and remove
remove AnalyticsReceiver and AnalyticsService
Good Luck
I want to define a permission in my Android app, and let other third-party apps to use. This permission is used to restrict calling of my modules. That is, third-party apps must request the right permission to call my module, just like using system permissions defined by Android system, android.permission.INTERNET or so.
In my test, I defined the permission in my app, say "my.apps.permission.my_permission", and then install it on emulator. In some of my Activities, android:permission="my.apps.permission.my_permission" property is added. This property forces the apps calling my activities must have the right permission "my.apps.permission.my_permission". Then in a test app, request the permission in AndroidManifest.xml, <uses-permission android:name="my.apps.permission.my_permission" />
The problem is, in the test app, which will call my permission-required activities, when I call startActivity(), I got a SecurityException : Permission Denied. But, if I defined a permission with the same name in the test app, everything works fine.
And, the followings are my conclusions:
1) It seems that, the permission defined in my app, "my.apps.permission.my_permission", is not visible to other third-party apps. How to make it visible, so that other apps can use my permission just like the ones defined in Android system?
2) Even is visible, Android won't check user-defined permissions with name conflicting.(I test this by define a permission with name "android.permission.INTERNET" in test app and overrides the system-defined one, and require "android.permission.INTERNET" in my app, and still, everything works fine.) If so, every other apps can define a permission with the same name that my module requires, and cheat my app. Is that right?
Anyone can help?
Thanks a lot!
I got the answer.
My own app, which defined the permission for other apps to use, must be installed before other apps who want to use my permissions. Otherwise, those apps must be re-installed, to use my permissions. No other operations or codes are needed, just <uses-permission android:name="my.apps.permission.my_permission" />, the same as other system defined permissions.
And, several apps may define permissions with the same name, conflicting with each other. The first installed app occupies the conflicting permission name, others won't overwrite or change the original permission.