Develop Reference

Android Oreo: Is there any way to auto - start the application on mobile reboot?

I am developing an application for a business entity. That application should run in the background in every employees' mobile phone. Employees are mostly salesman. The application basically detects location changes and suggest the salesman where they might visit. A kind of reminder application. It also lets other salesmen see where are their teammates.
Right now I am using a foreground activity and it works fine till the system forcefully doesn't kill the service or the phone doesn't reboot due to manual activity or battery discharge.
Ones the application is closed, as of now, the managers in the firm needs to call salespeople to turn on the application once, as on application start it automatically turn on its foreground service. But this is really an extra burden on the management team which can be automated.
I am ok to have any settings based or code based solution. One solution is to root the phones of salespeople and install some extra utility app or write the code based on root APIs, but this will be too much for this simple task.

THe permission RECEIVE_BOOT_COMPLETED was not added properly in the manifest. After adding the permission it worked calmly. In on receive method of the broadcast receiver, I am starting the foreground service.

At the moment, the best way is to use WorkManager https://developer.android.com/topic/libraries/architecture/workmanager/ Yes, it still alpha, but works very good.
From other side, you could work on automating the task "managers in the firm needs to call salespeople to turn on the application once". I mean, an app/backend could automatically call the salesman (with some pre-recorded message) or send SMS to them.

Is it possible to run an Android service under a different UID than the sharedUserId in the manifest?

I'm writing a remote management app for an android based device. The app currently runs under sharedUserId android.uid.system to enable access to restricted parts of the file system.
As a side effect of running under the system uid the app cannot access /mnt/extsd and a warning is logged every time we call sendBroadcast.
I'm looking for a way to run only the code that needs priviledged access as android.uid.system while the rest of the code can run as a standard uid. Is there any means to achieve this?

Start Service on boot without activity (but with root)

I want to create an app only for my phone, that runs all the time in background - and you should never stop that service from running.
My goal is, that this app is sending the current location data to my computer at home - to get it back, when it has been stolen for example, or when I lost it.
The problem is, that it is not possible to start a service without having an activity and/or launcher icon (because the thief should not know this).
But: My phone is rooted, so is it possible to start the service anyway?
And also: When I place my APK into the /system/app partition, will the APK persist after doing a factory reset?

Yes, you can. Rooting your phone doesn't matter for what you want to do, and if anyone tried to factory reset your phone, your app will still not be deleted, if you put your apk in /system/app partition as you said. It will react as if it was a normal system app. But of course, you must also set the correct permissions for your app when moving it to the system folder to be able to work.
And to prevent the thief from knowing your app, you can just name your app with an ambiguous name and without an icon that describes what your app does, because your app will still be visible in your application manager from your phone settings. Along with that, you can do the following:
To create an app that does not have an icon in the Home Launcher, just remove the intent filter android.intent.category.LAUNCHER of your activity from the AppManifest.xml.
To implement your background application, it strongly depends on what you want to do. You can create a Service for long running tasks, BroadcastReceiver to react to specific events or activities with intent filters.
Edit:
In order to let your app work automatically, you must put your app in this folder /system/priv-app. This way, your app will be started everytime you boot your device.

android create system service

Do android have anything like system service? Windows have services, similar. I want to create a application similar to antivirus which should run as system service and other programs should not be able remove it not other programs should be able to modify/ delete its data.

You can create a service based app and install it.
User will be able to install/uninstall as per his wish..
This service can be started as soon as the phone is started with
API's available.
Each app has its own space/memory for it use and it cannot be accessed by other apps unless given permission.

Actually you can create a system service, but you need to modify system image for this. If you can do this you can start it at the init.rc file or SystemServer.java. But for my point of view, Vinay is right - you should make an application with service. The application cannot be uninstalled by other applications, and the data of the application by default cannot be accessed by other applications (each application has its own user id. After that Android apply standard linux file permissions to the files of the applications).

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.