I know that in order to draw any view over other apps you have to enable this <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/> permission. But I have accidentally found out that some apps have this permission enabled by default (e.g. Fabulous, Android Ultimate). How on earth is that possible?
If an app is installed via Play Store and it requests SYSTEM_ALERT_WINDOW, permission is granted automatically to that app.
This was introduced in Marshmallow.
Related
Instead of the interactive/runtime permissions, how can I set the permissions at install OR sticky permission so that this doesnt come up everytime I run the app.
The two permissions are LOCATION & CAMERA.
In general you request permissions in your manifest file so that the user can agree when he installs the application.
However, there has been a change recently in Android 6.0 which requires that the user is asked at runtime if the permission is dangerous. The android.permission.CAMERA permission is on of those dangerous permissions. As noted by mmBs you could set your target API level to less than Android 6.0 (e.g. 21 = 5.0) to achieve backwards compatible behaviour. But I would recommend to always update the target API level to the latest platform.
Nevertheless, you can take photos by capturing the photo using an intent (https://developer.android.com/training/camera/photobasics.html). That way your app doesn't need the CAMERA permission (the other app invoked by your intent does, but not yours).
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.
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.
Android M not showing normal permission like Internet, WIFI in the permission list. Its just saying No special permission to display. Is that how Android M will display permission, it will never show permission prior to install. Can any one experienced this before.
attached screenshot,please check it.
Please help me to finding this answer.
Thanks.
Quoting the documentation:
When the user installs or updates the app, the system grants the app all permissions listed in the manifest that fall under PROTECTION_NORMAL. For example, alarm clock and internet permissions fall under PROTECTION_NORMAL, so they are automatically granted at install time. For more information about how normal permissions are handled, see Normal Permissions.
The system may also grant the app signature permissions, as described in System components and signature permissions. The user is not prompted to grant any permissions at install time.
(emphasis added)
I have an app that plays audio. I recently added the permission:
android.permission.READ_PHONE_STATE
so I could tell when a call was coming in so I could mute the audio during the call. I also added the permission:
android.permission.CALL_PHONE
So the user could press a icon to call a phone number. These were minor changes and really don't affect how most people use the app. After I published it I now have users who have tablets that don't have phone capability that they can not download the update and new users who have tablets do not see it in the play store anymore.
I read several posts about using this in the manifest instead of the permissions:
<uses-feature android:name="android.hardware.telephony" android:required="false">
But when I try to test the app on the device I get this error:
Caused by: java.lang.SecurityException: Neither user 10022 nor current process has android.permission.READ_PHONE_STATE.
Does anyone have any suggestions on how I can add these minor features to the app without alienating all of the non-phone users?
I read several posts about using this in the manifest instead of the permissions
You use <uses-feature> in addition to the permissions, not instead of the permissions.
Quoting the documentation:
For any of the permissions below, you can disable filtering based on the implied feature by explicitly declaring the implied feature explicitly, in a element, with an android:required="false" attribute.
So, add back your permissions. Then, use PackageManager and hasSystemFeature() at runtime, to see whether the device has android.hardware.telephony, so you can react as needed.
As #CommonsWare suggested use the following code to check if the device has telephony features available using the PackageManager
PackageManager pm = getBaseContext().getPackageManager();
pm.hasSystemFeature(PackageManager.FEATURE_TELEPHONY);