Develop Reference

Huawei Android devices - properly requesting permissions for background locations

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.

Android Do not Disturb (DnD) permission in managed profile

I have the following problem:
My app is distributed over an MDM system and runs in Android for Work.
In certain situation, the app must temporarily terminate the DnD mode. To achieve this, the user must grant the DnD permission when the app is started.
So far so good. If I install the app in the unmanaged area, the app shows up in the list and the permission can be granted without any problems.
As soon as the app is distributed via an MDM system, the app no longer appears in the list and the permission cannot be granted. All authorizations have been granted in the MDM system. As an example, I have distributed the Google App over the MDM system. This app appears in the list.
In the Manifest I have set the following permission:
<uses-permission android:name="android.permission.ACCESS_NOTIFICATION_POLICY" />
When the app is started, the following code is executed:
NotificationManager nm = (NotificationManager).getApplicationContext().getSystemService(Context.NOTIFICATION_SERVICE);
if(android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.M && !nm.isNotificationPolicyAccessGranted()) {
Intent intent = new
Intent(Settings.ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS);
startActivity(intent);
}
The problem only occurs with DnD permission. All other permissions such as overlay permission, are displayed without problems.
I hope anyone can help me.

According to Android documentation: NOT POSSIBLE
Users can grant and deny access to Do Not Disturb configuration from here. Managed profiles cannot grant Do Not Disturb access.

I haven't found a proper solution for the problem yet but I found a workaround to display the app in the work area. It seems that the app is only displayed in the dialog if the same app is also installed in the private area.
If the app is not installed in the private area, it will also not appear in the work area.
My workaround was to install the app in the private and work area. After the permission in the work area was granted, I removed the app from the private area. Like I said, it's not a solution to the problem itself, but it worked.
To me this looks like a bug in Android, because for all other permissions the app appears in the list

Apparently there is issure reported regarding this on Google Issue Tracker
https://issuetracker.google.com/issues/77939714
This is the reply from Google:
Status: Won't Fix (Intended Behavior) 11:41AM You can not change DND
settings from a managed profile app. We will be updating the
documentation to clarify this.
There is also a reply stating:
Microsoft Intune has released their fully managed Android Enterprise
profile setup for Android Devices. ... and it can now access and
grant the DnD permission. Not sure if its the fact that we have gone
to fully managed devices or if something else has changed.
And I would believe this is actually because the device is fully managed.
So according to my understadning there are two options:
Fully managed device (will require a factory reset on the phone)
Install it on the personal profile

We have the same issue with the app SignOnSite. Can't get access to the DnD function for emergency evacuations unless we also install the app in the Personal space as well. Makes it to risky doing it this way, so ended up just installing the app in the Personal space.
Using Intune for our MDM.

Try this -
Intent intent = new Intent("android.settings.NOTIFICATION_POLICY_ACCESS_SETTINGS");
startActivity(intent);

Options for dealing with Android 6.0's new permissions requirements from a service or model component?

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

How to manage installed apps (with root permission if necessary )?

Android users can go to the "manage application" (AKA "applications manager") screen, choose an app and make a choice of what to do there using the "App-info" screen.
I wish to make an app that allows the user to make those choices in even an easier way (maybe even batch operations).
How do I access each of the features there? Which permissions would I need and for features that are not available via the API, how could I get them via root access?
The features I'm talking about are:
Force stop.
Uninstall last updates.
Disable.
Uninstall - for this I actually know how to do it, but it needs confirmation of course:
final Uri packageURI=Uri.parse("package:"+packageName);
final Intent uninstallIntent=new Intent(Intent.ACTION_DELETE,packageURI);
Toggle "show notificaions".
Clear data
Clear cache
Clear defaults. I would also like to know how to set as default and get all registered intents and their currently default apps (which will handle them).
View app storage usage in both external & internal storage (and cache)
If you don't know what I mean, here's a screenshot of the app-info page:
I've also found some interesting Android permissions that existed ever since API 1, but I can't find any examples of how to use them. Such permissions are CLEAR_APP_CACHE , DELETE_PACKAGES , and CLEAR_APP_USER_DATA.
What I have found is a Samsung code example (available here) that has a permission of CLEAR_APP_CACHE, but I can't find where they use it, if at all.

How to show an Activity BEFORE my app is uninstalled (Android) [duplicate]

This question already has answers here:
Is it possible to detect Android app uninstall?
(8 answers)
Perform a task on uninstall in android [duplicate]
(4 answers)
Closed 7 years ago.
I though it was not possible but I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called.
I would like to replicate this behavior in my App.
I tried with an Activity listening to "android.intent.action.DELETE" Intent, as suggested here:
How to know my app is uninstalled from the device...?
But as I'm about to uninstall my app, the chooser pops up asking to pick my application or the package uninstaller. How can I avoid this?
Is there a different way to intercept your application UNINSTALL event? (before answering that it is not possible, please try to uninstall NQ Mobile Security and see what happens. On my Android 2.3.4 it shows a nice screen saying that is not safe to go without a security app).

I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called
They must be exploiting some security flaw in Android. I will research it and see if I can get it fixed. Apps are not supposed to get control at uninstall time.
Thanks for pointing this out!
Is there a different way to intercept your application UNINSTALL event?
I sure hope not.

Opera Max is an app that does something similar - after being uninstalled opens a webpage.
How do they do this?
By using libevent, from native code, they watch /data/data/com.opera.max directory to be removed and then post good old action.VIEW broadcast when it happens.
Install their app, run it, and on rooted device from adb shell remove /data/data/com.opera.max directory
UPDATE: I created a sample app that shows how it works. BTW it doesn't work with recent (KitKat+ I think) Android versions: https://github.com/pelotasplus/ActionAfterUninstall

I'm pretty sure that they are monitoring the LogCat to intercept when the Activity Manager calls the PackageUninstaller. I think they kill the task and start their own Activity.
It's pretty clever but it's definitely exploiting a security hole in Android.

They are likely asking for a very critical permission that the user is granting them unknowingly. Look at the "Permissions" tab for this app (as of 6/15/2012): https://play.google.com/store/apps/details?id=com.nqmobile.antivirus20&hl=en.
The list of permissions this app gets is downright chilling. Among other things:
SYSTEM TOOLS RETRIEVE RUNNING APPS Allows the app to retrieve
information about currently and recently running tasks. Malicious apps
may discover private information about other apps.
CHANGE/INTERCEPT NETWORK SETTINGS AND TRAFFIC Allows the app to change network settings
and to intercept and inspect all network traffic, for example to
change the proxy and port of any APN. Malicious apps may monitor,
redirect, or modify network packets without your knowledge.
PREVENT TABLET FROM SLEEPING PREVENT PHONE FROM SLEEPING Allows the app to
prevent the tablet from going to sleep. Allows the app to prevent the
phone from going to sleep.
CHANGE YOUR UI SETTINGS Allows the app to
change the current configuration, such as the locale or overall font
size.
MODIFY GLOBAL SYSTEM SETTINGS Allows the app to modify the
system's settings data. Malicious apps may corrupt your system's
configuration.
DISPLAY SYSTEM-LEVEL ALERTS Allows the app to show
system alert windows. Malicious apps may take over the entire screen.
MOUNT AND UNMOUNT FILESYSTEMS Allows the app to mount and unmount
filesystems for removable storage.
CHANGE NETWORK CONNECTIVITY Allows
the app to change the state of network connectivity.
CHANGE WI-FI STATE Allows the app to connect to and disconnect from Wi-Fi access
points, and to make changes to configured Wi-Fi networks.
-- Update --
I also found that the Android Package Manager pretty much just deletes a package if it is asked to do so. The only check it performs prior to doing so is whether the package being deleted is currently registered as having an active device admin:
try {
if (dpm != null && dpm.packageHasActiveAdmins(packageName)) {
Slog.w(TAG, "Not removing package " + packageName + ": has active device admin");
return PackageManager.DELETE_FAILED_DEVICE_POLICY_MANAGER;
}
} catch (RemoteException e) {
}
See line 6900 in PackageManagerService in the AOSP source here.
For this, the application must be explicitly registered as a device admin by the user. See notes on device administration here: http://developer.android.com/training/enterprise/device-management-policy.html.

As per https://stackoverflow.com/a/26829978/1317564, here is some example code that does it: https://github.com/zzljob/android-uninstall-feedback/blob/master/library/jni/feedback-uninstall.c. This won't actually stop the uninstall from taking place, but does provide a way to catch it and take some action. I'm honestly surprised that this works in Android and the team may have plugged the gap in recent releases.