Develop Reference

Application gets restarted if the camera permission is changed

I've implemented a short Flutter App which is requesting and checking the camera permission which works as expected. But, when manually changing the camera permission from the app settings, for both Android and iOS, it will restart my app. I need to mention that I've added in AndroidManifest.xml and Info.plist the required keys for camera. One interesting thing is that for the location the behaviour is fine and the app does not get restarted.
For permissions I'm using the permission_handler flutter library.
I don't know if is a flutter issue or a general mobile known behaviour but if someone knows more please let me know. If someone need some code example I can also provide this. Thank you.

It doesn't get 'restarted', it gets killed. Meaning, it will run from app launch the next time. This is because some permission settings cannot be changed while the App is running. This is by design.

Xiaomi 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 Xiaomi devices. It seems that in addition to location permission and white listing the app from battery optimizations, two additional steps are required, specific to Xiaomi devices:
Disabling battery saver:
Enabling auto-start:
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 shortcuts to take us “half way”.
Going to power settings:
Intent intent = new
Intent("miui.intent.action.POWER_HIDE_MODE_APP_LIST").addCategory(Intent.CATEGORY_DEFAULT);
Going to auto start settings:
Intent intent = new
Intent("miui.intent.action.OP_AUTO_START").addCategory(Intent.CATEGORY_DEFAULT);
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 Xiaomi 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!

Why re-installing an application sometimes clears SP although app backup is allowed?

I noticed that re-installing my application (building it again and again in debug mode) sometimes clears my SP and sometimes not.
I thought that adding android:allowBackup="true" in the application tab in the Manifest.xml file might restore it anytime I re-build the app.
<application
android:allowBackup="true"
.
.
.
>
Does building the app over and over actually uninstall it and then re-install it? And if it actually works like that, does it work the same for release mode?
What android:allowBackup="true" actually does? I thought it creates a permanent file on the phone pointing to the important data that needs to be backed-up.
When updating an app via Google Play, what is the actual process? Is the app uninstalled and then re-installed? Or does it just update the necessary code?How does it affect the memory?
What is the real reason of my Shared-Preferences actually getting deleted?

When it comes to things like shared preferences, they typically should be preserved between debugging sessions (assuming you are not manually deleting the app from the emulator/device).
Check Visual Studio's setting to ensure that it is trying to preserve data/cache directories:
Preserve data/cache between application deploys
Read the section on "Fast Deployment" for how Xamarin handles debug build updates:
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-process
During development "Auto Backup" (android:allowBackup="true") is pretty much irrelevant, see the conditions below in which is it back up to your Google Drive account.
Backups occur automatically when all of the following conditions are met:
The user has enabled backup on the device.
At least 24 hours have elapsed since the last backup.
The device is idle.
The device is connected to a Wi-Fi network (if the device user hasn't opted in to mobile-data backups).
The Android (Back up user data with Auto Backup) documentation cover this in more detail.

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);

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.