Develop Reference

Keep Flutter application active on device at all times, possible?

A client of mine is requesting for a very specific functionality, to keep the application always active, even after the user force kills it. He wants to ensure that the users have the application active at any time while using the device on which it is installed (the devices are managed in a constrained environment).
I've done some research on it, and already enabled background services for sending the user's location, but if they force kill the app then we are unable to send locations to the server. We've seen other apps do it, but wonder how they do it.
According to https://stackoverflow.com/a/34573169/640907 it should be possible in Android. We also found https://ssaurel.medium.com/how-to-auto-restart-an-android-application-after-a-crash-or-a-force-close-error-1a361677c0ce but I don't think this will work for our use-case, as the user can close the application without "force kill" aswell..
Anyone knows how to achieve this for a Flutter application?

Android app not updating when application is opened

I'm releasing a single app purpose that I update through google play store.
For those who do not know, a single app purpose is an app that is supposed to run alone on a device.
Therefore I give away the device the app, and prevent the users to use any other apps.
Anyway, I start the app automatically on boot. The devices reboot every day at 5 AM.
I've noticed that the google play store checks for updates when the device boots.
Unfortunately, it seems that the update won't perform while the app is opened.
To this I have 2 questions :
Is this odd behavior of update familiar to anybody (having the update not performing for the currently running apps)
How to solve this?
PS: I did think of updating the app versionCode on a third party server and if it's not up to date, close the app, let the update perform, then receive when the update is done performing to re-open the app.
But honestly, it feels like killing a fly with the bazooka.

I think you should depend on external server for this purpose.
App not being updated when running in foreground makes sense because Google play is not supposed to stop a running app which is necessary for updating it.
I recommend you to use Firebase cloud messaging service for the purpose. You can easily send data to the device using FCM.

Android- programmatically restrict which apps can be run

I'm building an app that needs to restrict which apps can be run along with it.
In example, when my app is running (foreground or background) I can allow user to run only GoogleMaps, and MusicPlayer.
I've read a bit about Device Policy Controller and creating profiles, and up to some point it seems to have the feature I need, but it is designed for enterprise deployment, and user needs to encrypt their phone beforehand. Is creating personalized profiles a way to go?
My other idea was to run a service that each few milliseconds check if there is any forbidden app running and finish it, but it seems to be not robust.
Is there any way of handling this problem programmatically?

I don't think that Device Policy Controller is a right thing for you.
And you can't just kill other apps without root.
So some kind of user-friendly way to achieve the goal is to check running apps list with ActivityManager.getRunningAppProcesses and to notify user that he has to finish particular apps to use your app.

Is it possible to prevent an app from being uninstalled? [duplicate]

Does anyone know if there's a way to either keep the user from uninstalling an app from an Android phone or reinstall it on removal? Before you flame me, please know that I have an app that's intended to be installed on the phone by a parent/employer/etc. and has a password-protected settings screen; the user would need to enter the password to remove the app.

What if you have it send an email alert to a registered email address on uninstall?

On the topic of email notification when your service is uninstalled--
A lot of security software runs multiple processes which monitor each other, so that it's more difficult to shut the system down. You could do something similar with two services installed, each monitoring to see if the other is installed. If something goes wrong, they can send off the e-mail.

Not without modifying the kernel, or reducing the user priviledges on the device. Think of it as a Linux computer, where the cell phone user has root.
Can you prevent them from removing your app? No.
But you can make it painful and difficult enough that it's not worth it, and include alerts that indicate it has been removed.
First, I would modify the software so it requests and successfully answers a cryptographic challenge/response periodically from a remote server - daily should be enough, and wouldn't impact battery use. This way your server knows when it has been disabled (could be sold as an additional $10/yr service charge) and you can alert the purchaser.
Second, I would tie the software into the system at the driver level so that removal also removes text services. There are drivers or services that the texting application uses that could be replaced with your custom versions, and on removal would render the texting app useless. Chances are good that you already tie into the system in a similar way to block the texting app (and other apps) while traveling too fast.
Third, I would consider installing a monitoring program that runs as a separate process (check out how the latest viruses operate for clues). It would check to make sure that not only is the app still running, but it's running the latest version, and there isn't a GPS simulator or other program that prevents your app from getting correct GPS data.
I'm curious how you differentiate between the driver texting and a friend in the passenger seat texting on the driver's cell, though.
-Adam

Well, solution would be to mount /system/apps/ to be writable and put your app there once.
When you restart the phone it would automaticly install it and prevent a user from uninstalling (as every app in that folder, list it to see it). That's how mobile providers force user to have they app.
However, user could always delete this app by rooting + mounting /system/app/ to writable and then to delete. But "normal parents" can't do that :)
Regards
P.S. This question is two years old, I've notice it just now... :S

I'd highly doubt that's possible. The permission structure of Android is going to give the user full control over what's happening on their phone (to some degree) and not being able to uninstall an app would be a pretty large security risk.
If you modified the Android core, it would probably be possible, but if you're trying to force something onto an end-user, that's a bad idea.
Maybe there's a better approach to what you're doing? If there's some required functionality in the app to keep the user from uninstalling it, that would be a small incentive to keep the app, but there's no way to keep a user from removing something they really don't want. You could have the app report uptime to a seperate server so you could be notified if the app was removed, but I think that's as far as you're going to get.

Detect if an app was uninstalled

Is there a way to get a system notification when an app has been uninstalled?
I would like to maintain a table of all clients' info currently using my app. However, that seems impossible if there is no way to detect this event.
The first solution I can think of is to have an always running service in the background listening for android.intent.action.PACKAGE_REMOVED. But then would that service be killed once the uninstallation process has ended, or would it be stopped just before the process has kicked off? Also even if this is a solution it's has the potential to put off a lot of people when they realise that part of the app is running in the background.
Any suggestions? Thanks!

You could simply do it the other way round and maintain a table of users actively using your app. Just call a webservice at a point in the program that show it is active. If an app isn't used for a certain time mark it as inactive.

The documentation for the PACKAGE_REMOVED action says the following:
The package that is being uninstalled does not receive this Intent.
So you can monitor for other applications being uninstalled but not your own.
So you'll probably need track who is still using your application, not who has stopped using it. If you don't want the overhead of having your own server to do this you could use a free service like Flurry.

From Android document, the app uninstalled by user can't not get
Intent.ACTION_PACKAGE_REMOVE
But we can use other method to implement this feature. We all know that there is a directory named with your package name under the /data/data directory after your app installed by user. If your app is uninstalled by user, the root directory of your app(/data/data/com.example.yourappname) will be removed by system. The remove action happen immediately when user click "uninstall", and the directory will be removed by framework package manager system.
So, we can monitor the existence of your app data directory(which usually /data/data/com.example.yourappname) to detect if your app uninstalled by user.
In order to monitor this directory, we have to fork a detached process from JNI.
In this new fork process, we can use Linux system api inotify(7) or access(3) to determine the existence of app's data directory.
Here is a workable implementation. But it got the permission problem when try to send an intent to start system browser on high version Android device. I have no idea how to bypass this. However the example above is enough for your question.
Hope it will be helpful!

Android doesn't provide an inbuilt function for tracking the app uninstall.
Notification can be used as an alternate way to track the app uninstall. For this send notification on the app and track the status of the notification. Count the number of undelivered notification for a particular time period. If status of undelivered notification doesn't change in that particular time period, then consider that the app has been uninstalled from the device.
For example, i have used a cron script which run every 3 days and check the status of last 10 notifications delivered to the device (2 notifications are sent in a day). If all of these 10 notifications have status "undelivered", then the app is considered to be uninstalled from the device.