I am using the Android Management API to get runtime permission android.permission.SYSTEM_ALERT_WINDOW. The app is going to be installed on fully managed devices. The policy has the below permissions defined:-
defaultPermissionPolicy: "GRANT"
I have added this to the application section of the policy as well. However, the app does not obtain these permissions and the user has to manually go to the settings and enable this permission. I understand that this permission is rated as advanced level permission, but this is a fully managed device.
Android Management API defaultPermissionPolicy can only grant/deny runtime permission requests. For example, READ_CONTACTS, WRITE_CONTACTS, ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION and etc.
SYSTEM_ALERT_WINDOW is a special permission. This permission doesn't behave like a dangerous or normal permission. This is a sensitive permission that needs user authorization.
For more information you may refer to this link.
I had the same problem with AE. The solution was set targetSdkVersion to 19 in your app.
To fully benefit from android.permission.SYSTEM_ALERT_WINDOW, it's usually necessary to request also Draw over other apps which is special permission that the user must grant manually per app. It's nicely described here.
Related
I am currently developing a Microsoft Teams tab app using Teams Toolkit.
The users of the app should be able to invite guest users to certain teams and edit some of the users information in AD. This requires higher permission level than the users have.
I have tried to use delegated permission but this limits the permission of the app based on the user's permissions. See https://learn.microsoft.com/en-us/graph/auth/auth-concepts
Is there a way using Teams Toolkit or, as a last resort, some other package to get a Graph API token that will allow the app to perform operations that requires permissions higher that what the user have?
For reference I list below some of the permission the app needs:
"User.ReadBasic.All",
"Sites.ReadWrite.All",
"Domain.ReadWrite.All",
"Directory.ReadWrite.All",
"TeamMember.ReadWrite.All",
"TeamSettings.ReadWrite.All",
Thank you!
Just as Hilton mentioned, you should use "Application" permission for your scenario.
"Application" permission is designed to running from backend, so you can setup a backend web app or Azure Function to do this.
Here are the basic steps:
Go to your AAD app, and add the permission you want
Consent the permission
copy client id and client secret from AAD portal
Follow the steps to get access token
https://learn.microsoft.com/en-us/graph/auth-v2-service#4-get-an-access-token
By the way, recommend to use Azure Function features inside Teams Toolkit, which can help you easily setup an Azure Function in you Teams Tab project, then you can write the code inside the Azure Function to call graph api with application permission
There are two main types of permissions, as you've seen. The first is "Delegated", which basically means the user is "delegating" your app to do something on his/her behalf. This is of course limited to what the user themselves can/can't do, as it's basically just doing it for them. To do something -differently-, or to do without having that specific user associated with it, you need to use Application permissions. In this case, your access is essentially unlimited, BUT it means that a tenant administrator needs to consent upfront (i.e. once-off) to your application having this level of access.
"Application" permissions are therefore what you're needing in your scenario.
Apps requesting access to the All files access permission without a permitted use will be removed from Google Play, and you won't be able to publish updates.
This is the bit that's unclear, at least to me. So if an app is currently in the Play Store but targets API 29 and has requestLegacyExternalStorage=true, will that app be removed from the Play Store in the future? If so, that's bad. I get that after November for any updates the target API must be 30.
We received this warning what does it means, we use requestLegacyExternalStorage flag and targetsdk 29, so my app will be removed from play? And what changes i need to do for this?
No, your app is not get removed from playstore...
but your app not might work if you targeted API 30 above. "requestLegacyExternalStorage=true" is a temporary solution provided by google to allow developer to smooth transition to new Secure Storage Model.
Many apps that had no legitimate need to read all the files stored on the device’s storage were requesting this permission, causing Google to narrow storage access permissions with Android 11’s “Scoped Storage” changes.
You have two option:
If your app require little to moderate use of storage > Use “Scoped Storage”
If your app is such as File Manager,Anti-virus,etc in which required all storage file access to work effectively and efficiently > Use "All files access"
Further query link_1 , link_2
We are working on a Slack app that doesn't work well when it is installed by a non-admin user. For example, if we invite a user to a channel using channels.invite we get a not_in_channel error (of course, when the installer user is not in the channel), what doesn't happen when the installer is an admin.
I see each team can configure who can install apps, but I don't see any option to indicate that the app must be installed by an admin user and throw an error if you aren't and admin of the team your are trying to install the app into. Is there a way to do that?
I think I found the answer. We need to ask for the admin scope.
Instead of asking for the admin scope I strongly recommend to ask for specific scopes (during installation) that the app needs to perform its functionality. e.g. for channels.Invite its channels:write.
Then the app also works when installed by a non-admin, provided that the user has the necessary permissions.
To learn more about the permissions system check out the official documentation on the topic.
We have an existing app that's registered in the Google Apps Marketplace. We now need to retire one scope that it uses and add another.
We are trying to decide whether we:
delete and add in one go; or
add the new one and then retire the other one at a later date.
I appreciate that adding a scope will require an admin to grant access to the App again, but can anybody confirm the impact of removing a scope? Does that also cause the admin to grant access again?
In short: does any change require admin intervention, or just scope additions?
Old scopes (that were requested and approved by user and you delete them from your marketplace SDK configuration page) that were approved by user at certain time will still remain approved for the user until he revokes the data access and re-grant it again.
New scopes as said by KENdi will not be approved until user approves (re-grant) access again, though all old scopes still will be available for you.
AFAIK you can add a new scope with the Google Apps Marketplace without deleting the old or unused scope. But take note note that your customer will still need to grant the access for the new scope/s in the ADMIN console.
Based on this FAQ, to update OAuth scopes, enable new extensions, and other application settings, go to Google API Console. Click APIs, then go to the Configuration tab under Google Apps Marketplace SDK.
For more information, check this documentation.
I want to request the permissions that I need for my android wear app upfront as per this. So Programmatically where exactly I should put my permission request code. Also is the protocol to ask for Permission the same as the mobile app like this.
All of the permissions are controlled in the Androidmanifest. Here is an example of some permissions being declared in the Androidmanifest:
These permissions are used to get the weather from the device and relay the information to an Android Wear device. Google offers documentation for developers to use to determine what permissions should be used. Declaring permissions should happen in the Androidmanifest in the format provided in the image. In the sample code posted, it is not necessary to include watch permissions, they are only required if the app works with Android Wear.
Way back in the day Google added a feature in Android 4.3 that let the user control what permissions apps could access on a per app basis known as App Ops. This was a great feature that cut down on privacy issues and gave users the piece of mind knowing that random apps installed could not access the device’s location. When Google introduced Android 6.0 Marshmallow, This time when an app needs to use a permission a dialog box pops up on the screen and asks the user if it is OK that the app uses a certain permission. This may get a little annoying, but at least every permission used by an app has to go through the user first.
If your app doesn't already have the permission it needs, the app must call one of the [requestPermissions()](https://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#requestPermissions(android.app.Activity, java.lang.String[], int)) methods to request the appropriate permissions. Your app passes the permissions it wants, and also an integer request code that you specify to identify this permission request. This method functions asynchronously: it returns
right away, and after the user responds to the dialog box, the system calls the app's callback method with the results, passing the same request code that the app passed to requestPermissions().
You should dynamically request the permissions from user on wearable devices just the same way you do on the phone side.