I want to implement something that does/check some things every time an activity (or application) is lunched and goes in the foreground.
Something similar to those Application Protection solutions that you use to protect any installed applications on your phone and they intercept when an application is lunched and prompt you with a password, PIN, etc.. (example : http://www.appbrain.com/app/app-protector-pro/com.carrotapp.protectpronew)
I believe that this is the mechanism I need and those protection applications use, they have a running service and somehow (this is what I'm interested) the are notified when an application is lunched . I believe that the service from these application just poll every second what is running, this would be a big battery usage, they have somehow to be notified when this happens.
So my question is how this can be achieved?
You can use a BroadcastReceiever to be notified when a package is ADDED, REMOVED, RESTARTED, and so on. And there is the category LAUNCHER there, but I don't think there is any way to just be notified when every application or Activity starts (that seems excessive anyway, which is probably why there isn't such a way), though you might be able to parse the log as Alex suggests.
For reference, see this question: Registering my broadcast receiver to run when an app is launched?
Related
I have been trying to get an Android service to take pictures in the background using the action.USER_PRESENT trigger. Suprisingly enough, it works.
I am confused about the mechanisms involved however. Going to list some points below, please correct where I am wrong.
When an intent filter is registered in the BroadCastRecevier via manifest, it will be triggerred even if the app is closed, correct?
The created service runs its methods on a newly created thread, and will execute until end, no matter what.
What are the mechanistic differences in how the service behaves when the app is open, in the background (or stopped in some devices), or destroyed?
action.USER_PRESENT triggers when the user passes his lockscreen?
In addition, I would invite suggestions to alternative triggers to USER_PRESENT, when my condition is that the service be triggered whenever the user is using his device.
When an intent filter is registered in the BroadCastRecevier via manifest, it will be triggerred even if the app is closed, correct?
Android developers do not use "app is closed", as that is not a specific description. Many things might qualify as "app is closed". In this particular case, your receiver will work even if your process is terminated, which is my guess for what you mean by "app is closed".
The created service runs its methods on a newly created thread, and will execute until end, no matter what.
No.
First, in Java, objects do not run on threads. Methods run on threads.
Second, there is no requirement that any work done by a service "will execute until end".
All a service means is that you are telling the OS that you are doing work that is not tied to the foreground UI, and that will hint to the OS to try to keep your process around a little bit longer. How long "a little bit longer" is depends on Android OS version, system RAM, what the other apps on the device are doing, etc.
What are the mechanistic differences in how the service behaves when the app is open, in the background (or stopped in some devices), or destroyed?
Apps are not "destroyed". An app's process being terminated is the closest thing that I can think of to what you might mean.
Once an app's process is terminated, all running code is gone, including any running service code.
There is no difference in the behavior of the service itself whether the app has foreground UI or not. Having foreground UI means that the app's process is very unlikely to be terminated, assuming that your code does not crash.
action.USER_PRESENT triggers when the user passes his lockscreen?
Yes, IIRC.
If the call Crashlytics.start(this) is on Application's onCreate() method, will it count an active user if something wakes up my application process?
For e.g. if I have a broadcast receiver or alarm, will it count as an active user if those wake up the app?
Thanks
I'd say that it does not count, but my answer is purely based on logic and common sense.
Crashlytics' recommended approach is to initialize the SDK in your Application class, so that crash logs (and every other type of info) can be collected as soon as possible in your app's lifecycle. When they introduced the Answers panel, my guess is that they figured out their way of determining what an active user is, based on a series of parameters and actions that indicates that the user is actually operating the app (which is, by the way, differs in every Analytics SDK provider, e.g. Google Analytics).
In short, I don't think that the Crashlytics.start() method immediately counts for an active user, because that would be just nonsense. But there's a quick way of determining that:
Create a testbed application that is fired up when you send a specific broadcast message
Initialize the SDK in the Application's onCreate() method
Using adb, send the broadcast message and meanwhile keep an eye on the Answers page of Crashlytics
Wait for some time (it may take some time to register the hit): is the user being tracked as active?
You can try to reach Crashlytics support for this, but I'm not sure they are going to give away this information.
EDIT
Adding some evidence I've found here:
A session begins when the app enters the foreground and ends once the app is backgrounded for 30 seconds or longer.
This leads to believe (as I wrote above) that their way of detecting an active user does not rely purely on the SDK initialization.
I guess that it should, unless it has a more complicated logic of some "actual activity" instead of just opening the app. Application.onCreate() is being called on the beginning of any Activity, Service or Broadcast of your app.
This is what is written in android documentation:
Called when the application is starting, before any activity, service,
or receiver objects (excluding content providers) have been created.
Implementations should be as quick as possible (for example using lazy
initialization of state) since the time spent in this function
directly impacts the performance of starting the first activity,
service, or receiver in a process. If you override this method, be
sure to call super.onCreate().
But keep in mind that if the app is already running the Application.onCreate will not re-run as it is already created.
I want to implement a service (or similar) on Android KitKat (4.4.2) in order to detect which is the foreground app and make something depending on which app it is "foregrounded".
I have read a lot of threads about determining which is the app is the foregound ON THAT MOMENT (https://stackoverflow.com/a/14044662/1683141). But I'm not able to see any thread about keeping this service continuosly monitoring in order to detect any changes on foreground. Kind of loop? Event registering?
For example, I want to be notified when LINE (messaging app) has or loses foreground. So I suppose the service has to be registered to some kind of event (I think Broadcast here is useless) in order to be notified and then take some action.
I don't know if that is possible. I hope it is.
Thank you for your help.
You are unable to keep your service alive if system decide to kill it. You are also unable to keep your service alive if your app is "unloaded" (whatever you mean), because your service is part of your app (and APK) and will be unloaded too.
I have been given multiple solutions to what I thought would be a common scenario. Unfortunately, none seem to work as expected.
I have created a pretty simple android game. The users can invite friends to play and there are a few activities they are routed through during the game lifecycle. All turns and data is stored in a remote server which is exposing the data through web services. Every time an invitation is sent, or the opponents complete their turn, the user is prompted via the service to play their turn.
The service prompts the user using a standard android notification telling them it's their turn. I don't want the service to poll the web service or present notifications while the user is viewing the game (they'll already know if it's there turn).
I have tried the following solutions without any success.
Start the service in the onPause method of the main activity and stop the service in the onResume method of the main activity.
Problem - Each time the user leaves the activity for another one the service starts. The user may be writing something or creating an invitation and they are prompted to take their turn.
Bind each activity to the service and set a boolean (running) flag in the same onPause/onResume methods of all activities.
Problem - This seems logical, but for some reason the service never presents a notification. This is likely user-error, but I'm not sure this is the correct solution anyway.
Start the service in the onPause method of all activities and stop the service in the onResume method of all activities.
Problem - Based on the toasts I'm presenting on the screen showing the state of the service this works as expected. The problem is the user is presented with notifications while the service is off. Apparently my toasts are misleading.
Any help is greatly appreciated. Sample code is not necessary, but would be appreciated if the solution is any more complex than the concept described above.
Thank you.
Don't use a service, use the Google Cloud Messaging and in the receiver of the broadcast, check the state of the game and then decide whether or not to show the notification. Polling is generally bad, uses data and battery unnecessarily.
I have a question about Android application status. I want to know that am I able to check whether application is alive or dead, visible or on background. I need to make a decision according to application status in my broadcast receiver.
Thanks in advance..
You determine if your "application" is "alive" by seeing if the data you loaded in your "start up process" exists. If it does, use it. If it does not, run the "start up process".
Basically, when your receive broadcast your application is guaranteed to run. That's because broadcast can not be received without application process started first. And if there were no components active (like activities) when broadcast is sent, then application process is started for the sole purpose of processing this broadcast.
As for the other part, detecting if any Activity is currently active and/or visible - I haven't seen any API calls for this. There are might be some workaround (like manually keeping the counter in a singleton), but as far as I know there is no direct support for this. Though I might be wrong.
Within Android, it is standard practise to track 'changes' to the various states. You can read more about this here. Within the specific lifecycle related methods, you can perform specific actions as deemed appropriate.