App requesting undeclared permission - "Test access to protected storage" - android

I've added to my manifest permission declaration for WRITE_EXTERNAL_STORAGE, and after some time I've noticed it asks also for Test access to protected storage when installing.
I declare in my manifest the minSdk as 14 and my targetSdk as 19.
How can I get rid of that ?

That prompt would appear to be tied to READ_EXTERNAL_STORAGE, which you are presumably being given automatically since you requested WRITE_EXTERNAL_STORAGE.
How can I get rid of that ?
Remove your WRITE_EXTERNAL_STORAGE permission. This, of course, has side effects. :-)

You have to be more specific. Setting WRITE_EXTERNAL_STORAGE permission also sets Test access to protected storage as this is a sub permission. I believe there is no way around this. Also you can see here: Development tools permission I did not set

Related

Can Android normal level permissions be requested at installation time (in the manifest)?

In later versions of Android (like 8.0.0), can we still declare normal level permissions in the manifest, like INTERNET permission and expect it to be granted at installation time?
<uses-permission android:name="android.permission.INTERNET" />
or do we need to explicitly request them through the code?
If the second, do we need to ask for it on every single activity?
can we still declare normal level permissions in the manifest, like INTERNET permission and expect it to be granted at installation time?
Yes. Only dangerous ones need to be requested at runtime.
Yes, you can declare normal level permissions in the manifest. But in 6.0 and above you have to check that permission is granted or not by user at runtime.

Is it really safe when using android 6.0 run time permission?

One of our developers made android application with all permission in manifest.xml (ACCESS_FINE_LOCATION, USE_FINGERPRINT ect.).
I guided him to remove unnecessary permission then he told me, "It is safe, because he used android 6.0 run-time permission (pop up the permission)".
But I think it is not safe because it can be abused.
Do I think wrong?
There are two kind of permissions, normal and dangerous. All declared normal permissions are in effect if declared in the manifest.If the app min sdk is Android 6.0 and above, until the user grants the permissions at runtime, the dangerous permissions are not in effect. It doesn't matter if they are declared in the manifest.It may be dangerous if the user grants the app dangerous permissions and you allow other apps to access some resources using your apps permissions like PendingIntent.
As suggested by Cao Minh Vu
It is better to request permissions which your app really requires.If you request a permission that is not required by your app users may think your app is malware.
For Example:
If you are requesting permissions for camera which is not required for your App even though giving permission or denying it is up to the user but it may cause user to be skeptical.And Probably user may uninstall your Application.

How to request permission on Android Things?

I'm trying to write to a value on AT. I've already declared required permission as follow in manifest,
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
And try to request permission at run-time, AT shows windows regarding permission setup. However the switch is not clickable. Regarding AT document
Requesting Permissions at Runtime is not supported because embedded
devices aren't guaranteed to have a UI to accept the runtime dialog.
Declare permissions that you need in your app's manifest file. All
normal and dangerous permissions declared in your app's manifest are
granted at install time.
However Settings.System.canWrite() always returns false.
Are there any special methods to enable permission WRITE_SETTINGS?
Like you said, the documents say:
Declare permissions that you need in your app's manifest file. All normal and dangerous permissions declared in your app's manifest are granted at install time.
Therefore you don't see the normal Android permissions UI.
From the release notes:
Dangerous permissions requested by apps are not granted until the next device reboot. This includes new app installs and new elements in existing apps.
So try powering off and on your Android Things device
After install application with the statement on AndroidManifest.xml as follow
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
It needs to be also run Settings as follow via adb
adb shell am start -S com.android.settings/.Settings
Then click APPS>YOUR_APP, then click permission.
Now the switch is clickable. So AT not granted to permission. It needs to be granted manually.
This permission is having Protection level: signature.Which means this permission is only granted to system apps.
Please find the below screenshot for your reference :

Define a permission for third-party apps to use in Android

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.

Android permissions: Phone Calls: read phone state and identity

My android app has nothing to do with phone calls, but I'm seeing that when I install a debug build on my test device it requires "Phone Calls: read phone state and identity" permissions. (I make no mention of this in AndroidManifest.xml).
I'd like to have the minimum possible permissions, and wondered if anyone knew how to get rid of this? I commented out the part where I was logging some stuff from Build.MODEL, Build.VERSION.*, etc. I also commented out the part where I was detecting the landscape/portrait orientation thinking that that might be the "phone state". But neither of those seemed to remove that permission required.
I found this bug report: http://code.google.com/p/android/issues/detail?id=4101 but it's marked working-as-intended with a note about permissions being correct from the market but not otherwise. Is this other people's experience? (I'd hate to have to publish to the market just to test that out.) Otherwise, does anyone know if there's an API I can avoid calling that will make it so my app doesn't need this permission?
Thanks!
(Answering my own question in case anyone else runs into this problem and searches for it.)
Digging around in PackageParser.java in the android source, I found out that the system will automatically assign
android.permission.WRITE_EXTERNAL_STORAGE and
android.permission.READ_PHONE_STATE
to any app that declares a targetSdk version of less than 4 (donut). There must be a compatibility reason for this, maybe apps targeting older versions could assume they had these permissions without declaring them explicitly. So, if you don't want these permissions added to your app implicitly, add a section like the following in AndroidManifest.xml
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="4" />
That is all.
Have fun, -Mike
Android 1.6 changelog: http://developer.android.com/sdk/android-1.6.html#api
WRITE_EXTERNAL_STORAGE: Allows an
application to write to external
storage. Applications using API Level
3 and lower will be implicitly granted
this permission (and this will be
visible to the user); Applications
using API Level 4 or higher must
explicitly request this permission.
But that is only one of them. For some reason the official change log is missing the info about READ_PHONE_STATE. The full story is cleared up here: http://blogs.zdnet.com/Burnette/?p=1369&page=3
New permissions. 1.6 programs must
explicitly request the
WRITE_EXTERNAL_STORAGE permission to
be able to modify the contents of the
SD card, and they must explicitly
request the READ_PHONE_STATE
permission to be able to be able to
retrieve phone state info. Apps
targeting earlier versions will always
request these permissions implicitly.
So as you can see, there is no way to publish an app targeted at 1.5 or earlier without requesting those permissions when installed on phones running 1.6 or higher.

Categories

Resources