Since Android 6 permissions can be requested on runtime. The user has the chance to grant or revoke permissions. He is always asked by the UI in form of a dialog popping up.
Is it somehow possible to grant permissions via voice input? I searched by myself but didn't find any approach for that. Is there any information to find about this topic? At least maybe some research how to make that possible maybe in future Android versions?
It would be great to find any kind of useful information about. that topic
I do not think so. It would not be safe, the user could accuse the application after capturing his audio without permission, for example.
You must EXPLICITLY allow anything (even acess the microphone to capture anything) that involves application access. So it's complicated for you to define something as explicit when using voice. The user may claim that he was only in a normal conversation when the application was granted permissions, and this can cause problems ...
Related
We develop an application which requires several permissions in order to get the user’s location while in the background.
We are having problems requesting the required permissions on Huawei devices. It seems that in addition to location permission and white listing the app from battery optimizations, an additional step is required in order to disable battery optimizations and enable auto launching:
The problem is we found no way of automatically requesting permission from the user, and the only way we found is having the user manually go to these screens and change the settings.
We did find a shortcut to take us “half way”, to the application settings:
Intent intent = new
Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
intent.setData(Uri.parse("package:"+context.getPackageName()));
But multiple non intuitive actions are still required from the user.
Our aim:
We would very much like to make the process easier for the user. Optimally, to have a system dialog appear which asks the user for the permissions, instead of having him manually change the settings, much like the whitelisting of normal Android devices:
Is it possible using a Huawei specific SDK extension?
If (1) is not possible, at the very least we need a way to know if the user changes these settings or not. Currently we don’t know and cannot inform the user if the application works properly or not!
Are you expecting that your app displays a permission popup so that users can easily assign related permissions to your app?
If yes, you can integrate HMS Core Location Kit into your app. Before performing an operation requiring a permission, your app dynamically checks its permissions.
If your app does not have the required permission, it will display a popup to prompt the user to assign the permission. You can implement the popup with few code lines and users can easily assign permissions in the popup. For details, visit https://developer.huawei.com/consumer/en/doc/development/HMS-Guides/location-guidev4.
In addition to dynamic authorization, do not forget to apply for static permissions in the Manifest file.
The PlacePicker is a useful widget added in com.google.android.gms:play-services-places:9.4.0. Find the description here: PlacePicker
The documentation clearly states that you need the ACCESS_FINE_LOCATION permission for it to work.
On Marshmallow and above you also must ask the user to grant this permission.
But it seems to work without doing any of this! My app does
provide a maps API key
not define the permission in the AndroidManifest
not ask the user to grant this permission at any time
But running the app on an Marshmallow device DOES start the PlacePicker and I can
correctly select a place (not possible without the API key).
go to "My Location" via the MyLocation-Button (possible without API key)
Can anyone confirm this or has an explanation why this widget works without proper permissions granted?
The question is almost an year old but I was trying to find the same answer so it can help somebody else.
It's because PlacePicker works with "intent based request". The documentation is not very clear with it, but it says
1: Only use the permissions necessary for your app to work. Depending on how you are using the permissions, there may be another way to do what you need (system intents, identifiers, backgrounding for phone calls) without relying on access to sensitive information.
Source
And give some clue here:
If your requirement for access to user data is infrequent — in other words, it's not unacceptably disruptive for the user to be presented with a runtime dialogue each time you need to access data — you can use an intent based request. Android provides some system intents that applications can use without requiring permissions because the user chooses what, if anything, to share with the app at the time the intent based request is issued.
Source
I've figured it out testing permissions use cases with Marshmallow and Lollipop devices, comparing the result with PlacePicker that I thought could be using intent based permissions with MediaStore that use this kind of permission according to documentation:
For example, an intent action type of MediaStore.ACTION_IMAGE_CAPTURE or MediaStore.ACTION_VIDEO_CAPTURE can be used to capture images or videos without directly using the Camera object (or requiring the permission). In this case, the system intent will ask for the user’s permission on your behalf every time an image is captured.
For example, an intent action type of MediaStore.ACTION_IMAGE_CAPTURE or MediaStore.ACTION_VIDEO_CAPTURE can be used to capture images or videos without directly using the Camera object (or requiring the permission). In this case, the system intent will ask for the user’s permission on your behalf every time an image is captured.
Source
I'm looking into porting some existing code to take Android M's new way of dealing with permissions into consideration. However the permission API needs to have an activity associated with it (for example the requestPermissions() method's first parameter is an activity).
So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
Is it possible for the service to create a dummy invisible activity just for use with the permissions API? (if its possible I don't like the thought of doing that anyway though).
Or suppose its not a service but a model class that needs to perform a permissions check, in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API. Or potentially lots of code might have to migrate from model code into Activity code.
Any thoughts on how to migrate non activity based code that needs to check/prompt for permissions over to Android 6.0?
Update: I left out an important piece of information - this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time and run in the background. Therefore the usual situation of a user being prompted for permission when they launch the app or later (and there therefore being an activity at that point) does not necessarily apply.
So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
There is almost always an activity, except for pre-installed apps and plugins for other apps. Otherwise, your service is unlikely to ever run, as nothing will have used an explicit Intent to start up one of your app's components, so it will remain in the stopped state.
For the ~99.9% of Android apps that have an activity already, if the permissions are needed for the whole operation of the app, request them on first run. As Snild Dolkow notes, if the user later revokes the permission through Settings, you can detect that without an activity, then use other UI options (e.g., Notification, app widget) to let the user know that operation is suspended until they grant you the permissions again, which they would then do through your activity.
Is it possible for the service to create a dummy invisible activity just for use with the permissions API?
Presumably you can have a Theme.NoDisplay activity use requestPermissions(). However, from the user's standpoint, it will not make much sense, unless there's some alternative UI (app widget?) that they are interacting with. Popping up a permission dialog out of nowhere is unlikely to make you popular.
UPDATE 2019-06-15: Note that Android Q bans services popping up activities frmo the background. Please use a notification instead.
in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API
Do not touch the models until you have requested the permission, and gracefully fail if the permission is revoked. You already have to gracefully fail in other circumstances (out of disk space, no Internet connection, etc.), so a revoked permission should be handled in much the same way.
using this new 6.0 API seems like an recipe for bad design and tight coupling
You are welcome to your opinion. Based on what I have read, the Android engineers believe that asking the user for permissions is part of the user experience and is best handled at the UI layer as a result.
Again: the vast majority of Android apps will not have a problem with this, as they have a user interface. Apps that do not have a user interface and need dangerous permissions are in for some amount of rework.
this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time
First, please understand that this is so far from normal that you can't even see normal from where you are due to the curvature of the Earth. :-) You can't really complain that Google did not optimize this particular scenario.
As I understand it, even system apps should be asking for runtime permissions. The Camera app did, for example, on the 6.0 preview. That being said, there's gotta be some database on the device somewhere that is tracking what has been granted, and presumably there is some way to pre-populate it. However, the user could still revoke it from Settings, presumably. But, the manufacturer could pull some stunts (e.g., messing with the Settings app) to possibly even preclude that scenario. I'd be looking in the same area as "how do I get it so my app cannot be force-stopped?" that device manufacturers can do.
Your alternatives would be to get rid of the dangerous permissions or to migrate your app off the SDK and into a standard Linux binary that would be run as part of the boot process and be put into a Linux user group that has access to the stuff that you need.
Ask for it when the user enables whatever feature your service provides. They'll be in one of your activities at the time. Yes, it means that your activities need knowledge of what permissions your services will require.
The service can always check for the permission by itself, though, since checkSelfPermission() is available in all Context instances. So you don't need an activity for that.
I guess an alternative would be to have your service post a notification saying "feature X requires you to approve more permissions". Actually, that may be a good idea regardless, in case the user goes into settings and revokes any permissions after the fact. That notification would then take the user to some activity with an "enable feature X" button/checkbox -- ask for the permission when that is selected.
You can send a notification. Look this library to manage the permissions: permission library
I notice that (too) many applications on my Android phone require full internet access. In some cases, it seems like they just want to connect to some service. In other cases, it is clear they are phoning home. However, it seems like users have no easy way of checking which one is the case.
I realize that in the manifest permissions for Android there is a "android.permission.INTERNET", but is there a way to say "this application will only access some.domain.org", and maybe specify which protocols will be used, or something like that? Could the Android system enforce that somehow?
As far as I know, android.permission.INTERNET is the most specific you can get. I agree that it would be nice to be able to specify that my app only talked to an individual server, but in the end it wouldn't tell the user anything meaningful, since most protocols can be tunneled and proxied over most other ones with sufficient ingenuity.
The android UI devs decided to go with the broader permission rather than confusing regular users by displaying information that would not be functionally meaningful. As an alternative, you might consider including a note in either your application description or a popup immediately after installation that explains precisely how and why your application accesses the internet.
Edit:
You might be able to circumvent that permission altogether if you only wanted one-way messaging to the phone and did something excessively clever with C2DM. This would be a bad thing to do, however, and I haven't verified that it would actually work without that permission.
I would like to know what would be the top ten most deadly permissions that can be requested by an android. I know it might be a matter of opinion, but supposing that I had the 10 permission listed in by an application, I would definitely know my application did not generate a whole lot of confidence among users. What would be the permissions I would most likely like to avoid asking the user for.
I am aware of permissions like BRICK and SHUTDOWN but since they don't apply to third party devs I would like to know only of permission which can be requested by a third party developer.
PS: need not necessarily be 10. Any number of permissions you believe might lead to the user being weary of application would be nice.
CALL_PRIVILEGED - call numbers without going through the dialer
SET_ALWAYS_FINISH - controls whether or not applications become finished when put in background. Could lead to some nasty trackers or something.
READ_CONTACTS - could lead to some data stealing for ppl to add to their spammer lists.
Here are some I found that could potentially be very dangerous (not including the ones above :)
GET_ACCOUNTS - Allows access to the list of accounts in the Accounts Service
MOUNT_FORMAT_FILESYSTEMS - Allows formatting file systems for removable storage.
PROCESS_OUTGOING_CALLS - Allows an application to monitor, modify, or abort outgoing calls.
READ_SMS - Allows an application to read SMS messages.
SEND_SMS - Allows an application to send SMS messages.
READ_EXTERNAL_STORAGE - Allows an application to read from external storage
WRITE_EXTERNAL_STORAGE - Allows an application to write to external storage
And of course the best way to transmit some of this data
INTERNET - Allows applications to open network sockets.
I think it depends on what the app is meant to be doing.
Some days ago, for example, I was looking for a task killer app, and I ended not installing any because all the "Task Killers" I saw on the market requested full internet access.
Why would they need internet access in order to kill a task?
If they wanted internet access in order to display ads then they should say so, but otherwise I take the paranoid approach and I assume it is spyware.
Other than that, I am very protective of my SIM card and contacts.
Any app which uses ACCESS_INTERNET and READ_CONTACTS could be stealing your contacts. However, there are thousands of apps in the market that have these permissions and probably aren't...
Access the list of accounts in the Accounts Service
Act as an AccountAuthenticator for the AccountManager
Access information about networks
Request authtokens from the AccountManager
I routinely check permissions before download. If the application has no business doing these, then I would not even download it . Even if it does, I would think twice whether I really, really need the app to reside on my device. And BTW - the above are part of 34 permissions coded in Skype!
If we do not know who and where the developer is, we would tend not to download software on our PC's. Yet, so many don't use this logic for their Android devices.
BRICK - Disable a device