I have a (FOSS) app out there which can, among other features, enable and disable Wifi.
AndroidManifest.xml contains android.permission.CHANGE_WIFI_STATE, unit tests on the emulator pass and the feature works on a real device, a HTC Desire running 2.2.2.
The SDK versions are android:minSdkVersion="7" and android:targetSdkVersion="10", so I can't say about newer releases of Android.
I have received one single crash report:
java.lang.SecurityException: Permission Denial: writing com.android.providers.settings.SettingsProvider
uri content://settings/secure from pid=6191,
uid=10114 requires android.permission.WRITE_SETTINGS
Is android.permission.WRITE_SETTINGS possibly required on recent versions of Android? The reference says the permission exists since API 1, so I'd be surprised why it wasn't on older releases.
The user message is weird, it just says "lies", so I am unsure if I should just follow this report and add android.permission.WRITE_SETTINGS.
Any thoughts?
Cheers,
Torsten
That's weird, cause I needed to check exactly the same issue, so i just wrote a few lines of code doing exactly just that : enable/disable wifi and bluetooth.
My conclusion: you dont need the WRITE_SETTINGS permission to toggle the wifi, nor the bluetooth for that matter.
wifi = access_wifi_state + change_wifi_state
BT = bluetooth + bluetooth_admin
(with 4.2.2)
Check whether you were trying something else too, which may trigger the exception ?
Related
I'm testing Bluetooth with a Huawei Honor 8 device (Android 9).
The permissions in manifest.xml are registered:
<uses-permission android: name = "android.permission.BLUETOOTH" />
<uses-permission android: name = "android.permission.BLUETOOTH_ADMIN" />
1) Why, in Android 9, when bluetoothAdapter.enable() is called, a request pops up for permission to turn on Bluetooth (and also to turn off)? Although this permission has already been given to the application. In the list of permissions (Settings-Applications-My application-Rights) there are:
Permission to "request a connection, accept a connection, transfer
data" (I assume this is BLUETOOTH)
Permission to "start scanning devices and changing Bluetooth settings"
(I assume this is BLUETOOTH_ADMIN)
On a device with Android 4.4, no additional requests arise.
In order for the system to remember the issued permission, do I need to display its request using ActivityCompat.requestPermissions() ?
2) Why are these 2 permissions not in the main list of permissions, but as additional permissions (you must specifically click on the Advanced button to see them)?
UPDATE:
If I understand correctly, all the normal permissions (which are BLUETOOTH and BLUETOOTH_ADMIN) are often found as Additional.
I use the Code A to set the enabled status of WiFi, it works well when I use Android Emulator with both API 26 and API 23 in Android Studio 3.1.3 , and none of prompt window display!
But I get a prompt window "An App is requesting permission to use WLAN. Allow?" in real mobile phone with Android 5.1 when I run the code A.
How can I make the prompt window not to display in real mobile phone? Thanks!
BTW,the real mobile phone is Samsung SM-J5008 with Android 5.1
Prompt Window
I have set the permissions
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
Code A
fun setWiFi(aWiFiDef: WiFiDef): Unit{
val wifiManager =mContext.applicationContext.getSystemService(WIFI_SERVICE) as WifiManager
wifiManager.isWifiEnabled=aWiFiDef.status
}
Android 5.1 does not have such runtime permission, so I assume, that this is a wrongly implemented permission request rational, which is shown even though the app does not need to. You wrote, that you tested with API level 26 and 23, which is Android 6.0 and higher, so these versions already have runtime permissions. Maybe you haven't seen this issue, because you haven't tested on devices below Android 6.0...
Please check if you somewhere call AppCompat.shouldShowRequestPermissionRationale() and if it is surrounded by SDK level checks or at least with a checkSelfPermission as described here: https://developer.android.com/training/permissions/requesting. Test your code in an emulator with Android 5.1 and Android 6.0. Then you should be able to reproduce that issue also on real phones.
You also need to add this to your manifest:
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
According to the website below: *App on Marshmallow needs ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission and Location services should be enabled to get wifi scan results. Google probably sees scanning for wifi as a security concern, and wanted to add the location permissions as well.
I would recommend following the blog post below if you are having trouble after adding the ACCESS_COARSE_LOCATION permission to your manifest.
https://www.intentfilter.com/2016/08/programatically-connecting-to-wifi.html
EDIT
For the people down voting, please include a comment explaining why. Was my answer flat out wrong? Did I overlook somthing?
Some more information on google's geolocation service:
Google maintains a huge database for its geolocation service ("Access coarse location" permission). It consists of:
Wifi access point mappings: Wifi MAC address resolve to a geolocation
Cell tower mapping: Cell tower ID's resolve to a geolocation
So it is very possible that this user didn't include this permission and is getting this dialog box.
So I have camera permission in manifest , Still when app goes to start camera it crashes .this happens beacuse user had denied the permission in permission manager for camera that comes with xiaomi devices
So the app Crashes , can someone help about how to handle this.
with the normal way of getting permisions , it does not give correct result
String permission = "android.permission.CAMERA";
int res = getContext().checkCallingOrSelfPermission(permission);
res is always 0(has Permission) for below 23 devices , if user has manually denied permission by going to permission manager then also
Revoking permissions on android devices below 23 is non-standard behavior and is afaik only possible through customized OS versions (like Cyanogen mod or in your case, the Xiaomi modified version). Users should be aware, that revoking permissions that way may cause error ins apps.
Prior to Android 6.0, you could reasonably assume that if your app is running at all, it has all the permissions it declares in the app manifest.
https://developer.android.com/training/permissions/best-practices.html#testing
Therefore I suggest you run your methods that require a certain permission with a try/catch. If the api lvl is below 23 and your method call fails, you know for sure if you have the permission or not.
Short and simple question:
rooted devices can grant apps with extra permissions during runtime (using "grant permission" command using the adb , as I recall). An example for this is the ability to read system logs , which became a non-user permission starting with API16 (link here) .
Is there a list of such permissions?
The command you may be thinking of is pm grant PACKAGE PERMISSION, which can be sent to an adb-connected device using adb shell pm grant PACKAGE PERMISSION.
However, only optional permissions can be granted or revoked this way. If you try to grant a permission not requested in the app's manifest, you'll get Operation not allowed: java.lang.SecurityException: Package PACKAGE has not requested permission PERMISSION. Likewise, if you try to revoke a permission not deemed optional, you'll get Operation not allowed: java.lang.SecurityException: Can't change PERMISSION. It is required by the application. Even for a rooted device or emulator.
Now, as far as what is deemed 'optional', as well as getting a list of such permissions, that's a little unclear. However, based on some experimentation, I believe these include at least the set of permissions assigned to permission group android.permission-group.DEVELOPMENT_TOOLS. You can see which these are on a running device using pm list permissions -g. On my API 19 emulator, as well as a Nexus 7 running AOSP 4.4.4, these are:
group:android.permission-group.DEVELOPMENT_TOOLS
permission:android.permission.ACCESS_ALL_EXTERNAL_STORAGE
permission:android.permission.SIGNAL_PERSISTENT_PROCESSES
permission:android.permission.READ_LOGS
permission:android.permission.SET_ALWAYS_FINISH
permission:android.permission.WRITE_SECURE_SETTINGS
permission:android.permission.SET_PROCESS_LIMIT
permission:android.permission.CHANGE_CONFIGURATION
permission:android.permission.DUMP
permission:android.permission.SET_DEBUG_AP
If (and only if) these are declared in the manifest, then you can grant/revoke them using the above command. Note that they are not granted automatically on installation; you must issue the pm grant command. I was able to observe and confirm this by using the Settings app and seeing the reported permissions change as I granted and revoked them.
There may be other permissions that behave like this, but I haven't found them. Normal permissions like android.permission.INTERNET cannot be granted or revoked in this manner.
Addendum: Per additional question in comment section regarding pm set-permission-enforced PERMISSION: As far as I know, the only permission which currently supports this is android.permission.READ_EXTERNAL_STORAGE. I'm basing this statement on my reading of the source code, which is also consistent with my experiences using the command. The purpose of the selective enforcement setting on this permission is to allow testing of apps under pre- and post-API 19 conditions as described here.
I have seen some Android apps on my phone require this android.permission.READ_PHONE_STATE permission. I don't know if I could trust them. I know this permission will give the app access to many information. I'm particularly interested in what functionality in an Android app normally require the information like DeviceId , SimSerialNumber, SubscriberId?
Phone state provides access to a lot of information about the phone. Usual usages will be for reading the IMEI of your phone and your phone number. This can be useful to identify you in their systems.
It can also be needed if the application is made compatible for Android 1.5 or lower, because this permission didn't exist back then and is added automatically by the play store to those apps
See also: https://android.stackexchange.com/questions/605/why-do-so-many-applications-require-permission-to-read-the-phone-state-and-ident
Another possible reason is so they can mute audio events if you're in the middle of a call. This is why apps like Pandora, Spotify, etc need the permission - so they can mute themselves when you get a call.
Not long ago I discovered that for some devices you should add android.permission.READ_PHONE_STATE if your application sends SMS. Probably in some cases SmsManager tries to retrieve some information about phone state before sending sms.
For example getting exception for HUAWEI GRA-L09:
java.lang.SecurityException: Requires READ_PHONE_STATE: Neither user 10174 nor current process has android.permission.READ_PHONE_STATE.
at android.os.Parcel.readException(Parcel.java:1543)
at android.os.Parcel.readException(Parcel.java:1496)
at com.android.internal.telephony.ISms$Stub$Proxy.s! endMultipartTextForSubscriber(ISms.java:1224)
at android.telephony.SmsManager.sendMultipartTextMessage(SmsManager.java:404)