I have a device management application, which essentially runs as a service in the background from boot. I'd like to start this application immediately after installation. How do I achieve this?
You cannot do this -- there is no way to automatically start your service merely because it was installed.
The application must first be invoked by the user through some sort of activity. Or, you are going to need to hook into some relevant broadcast Intent via the manifest, so you can get control when one of those events occur and kick off your service that way. Or, you are going to need to ask the user to reboot so your BOOT_COMPLETED Intent filter can get control.
There was a hole - the Android Analytics SDK used to send an intent right after installation - but that got closed (producing lots of confusion, of course).
But the final answer, I believe, is here:
http://developer.android.com/about/versions/android-3.1.html#launchcontrols
This seems to suggest that, as of 3.1, Google made the decision that apps are in a stopped state until the user explicitly activates them, e.g. by launching app or placing widget.
This means that the strategy of listening of a common broadcast (i.e. to get your app launched surreptitiously) won't work either.
Related
My app needs to know when the user last interacted with the phone, or when the device screen went off. Answers to similar questions suggested:
registering a SCREEN_OFF/DEVICE_IDLE_MODE_CHANGED broadcast receiver in manifest.
Problem: won't work since it's a protected broadcast
dynamically registering and unregistering SCREEN_OFF/DEVICE_IDLE_MODE_CHANGED when an app component is live
Problem: I can't or don't want to keep the app or service running since I need to know SCREEN_OFF 24x7.
Using ActivityManager or UsageStats
Problem: Gives details only for particular packages so to be able to figure out when the app was last used, will have to iterate over a list and make many function calls. And even after that, I am not sure if this covers the case when no app is used but only a quick device unlock and relock action.
Is there a way to reliably know in the background when the user last used their device without keeping a service running?
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.
After 3.1 , Android introduced a security feature, where the application's code can't be run unless the user opens the application. Check the link for more info http://commonsware.com/blog/2011/07/13/boot-completed-regression-confirmed.html
I would like to know if anyone has found any hack or work around for this problem, where i can listen to a system broadcasts like boot, connectivity changed and run a service without opening the installed application.
This is not what the posts said. You can still register broadcast listeners, or alarms. You just need the user to actually start your application once. And, if the user forcefully stops your application, they'll need to start it manually again.
Why would you want a way around this behavior? It seems to make a lot of sense.
I am not satisfied with any of the app locker programs for Android that I have found and would like to create my own, but I am having trouble figuring out how to implement the actual lock. How does one go about implementing an app locker for Android?
There are two issues:
Detecting an Intent, usually from the launcher calling startActivity() or from an ad launching the market app (I'm not talking about broadcast intents -- I need to handle explicit Activity Intents).
The permissions for the locker apps I have seen all have "read system log files" and/or "retrieve running applications" which suggests they might use polling to look for app launches. I think I could do this, but I would like to find a better solution if possible.
Preventing the locked app from processing the Intent. I would prefer not to allow the locked app to run at all until the passcode is entered since it is impossible to tell what it might do when it starts up.
When running my current app locker, logcat shows "ActivityManager: Starting activity" first with the Intent for the locked app, then again with the Intent for the app locker, with nothing in between (separated by 10-20ms). If I enter the correct passcode then I see "ActivityManager: moveTaskToBack".
I have experimented with a test app which demonstrates that, using my current app locker, none of the Activity callbacks are invoked if the app is locked and I do not enter the correct passcode. So it appears to be preventing the app from starting (but I don't know how).
I could use ActivityManager.killBackgroundProcesses() to stop an app, but I have no guarantee that the app hasn't already started running by the time it gets "killed".
I might be able to use PackageManager.setApplicationEnabledSetting() to prevent an app from being instantiated, but I don't think that will take care of apps that are already running (which shouldn't be allowed to process new Intents or come to the foreground). I might be able to use killBackgroundProcesses() to stop all running locked processes so they would have to be re-instantiated. But I don't like this approach because other apps could mess with the Enabled settings and defeat the lock.
Optimally, the system would send every Intent to my app for inspection and allow me to stop or let it pass through, but I'm pretty sure that's not possible (at least, not for explicit intents to start activities from a launcher).
Does anyone know how app locker apps are implemented, or have any bright ideas on how it could be done?
I would look into the lifecycle. Once the app in question begins to load, some activity from that package will be added to the forefront activity.
A scan of the changes in forefront activities might do the trick.
http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle
I have a device management application, which essentially runs as a service in the background from boot. I'd like to start this application immediately after installation. How do I achieve this?
You cannot do this -- there is no way to automatically start your service merely because it was installed.
The application must first be invoked by the user through some sort of activity. Or, you are going to need to hook into some relevant broadcast Intent via the manifest, so you can get control when one of those events occur and kick off your service that way. Or, you are going to need to ask the user to reboot so your BOOT_COMPLETED Intent filter can get control.
There was a hole - the Android Analytics SDK used to send an intent right after installation - but that got closed (producing lots of confusion, of course).
But the final answer, I believe, is here:
http://developer.android.com/about/versions/android-3.1.html#launchcontrols
This seems to suggest that, as of 3.1, Google made the decision that apps are in a stopped state until the user explicitly activates them, e.g. by launching app or placing widget.
This means that the strategy of listening of a common broadcast (i.e. to get your app launched surreptitiously) won't work either.