I am developing an app where i need to keep background service running even if user uninstalls app. this is more like what uber did with its ios app to track users (https://www.wired.com/2017/04/uber-didnt-track-users-deleted-app-still-broke-rules/).
I tried to make service as system service which actual a bad idea.
ServiceManager.addService("downloader", new MyService());
looking forward for help.
I am developing an app where i need to keep background service running even if user uninstalls app.
That is not possible, fortunately.
Related
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?
I have developed a react-native app for Android to receive real time food orders (like Uber Eats, Postmates, etc.). The app is running in a Lenovo tablet that is constantly charging. I use a GraphQL subscription to detect new orders and Firebase Cloud Notifications to check the network status of the tablet.
The problem is that right now the system eventually kills the app after some days with no interaction. I would like to know the best approach to prevent the systems kills the app and being able to run it 24/7 in this case scenario.
Thanks!
You should write a service for your app, which starts the app when it gets killed.Never ending service has a good tutorial on how to do this.
We're currently running tests (that end in 2 weeks) with clients using an "older" version of our app.
The older app has a long-running scanner foreground service that will not restart on the MY_PACKAGE_UPDATE broadcast (wasn't implemented at the time). The new version of the app correctly handles this broadcast and restarts the scanning on MY_PACKAGE_UPDATE.
We need to roll out updates mid-test to fix a bug appearing on only some devices, and we are able to reach out to those specific users. The problem is that for any current users with auto-update turned on, their foreground scanning service will exit and not restart.
Am I correct that the MY_PACKAGE_UPDATE broadcast won't kick in yet? As in, it'll only begin working two updates from now?
Is there a way for me to turn off auto-updating for my app in the play store for all users?
When I launch an application for the first time then service should be started - but separately from current application. So when I delete this application , service should still work. Is it possible in Android?
Fortunately, no, for obvious security reasons. If the user uninstalls ("delete") the application, everything is removed.
You are welcome to have two separate applications, though.
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.