I have a requirement to be able to monitor my application's state each minute even if the application is not on top.
SO I am using TIME_TICK broadcast for this. However, when the application is not on top, I am not receiving the broadcast. But, when my application is running on top I am getting it.
Any work around for this?
I assume you are registering the receiver at your manifest.xml file.
as the Android Documentation says:
Broadcast Action: The current time has changed. Sent every minute. You
cannot receive this through components declared in manifests, only by
explicitly registering for it with Context.registerReceiver().
I tried TIME_TICK in every way possible. The thing with TIME_TICK is that it is only active when the application concerned is up and running. Yes we do have to explicitly register for the broadcast from a Activity. But, even after that though I didn't unregister when exiting from the app, I was not getting the broadcast(Since Activity was dead so mostly the Broadcast registration was gone).
The solution which worked for me in this case is using AlarmManager, by setting a setRepeat alarm for each minute.
Related
I want to get broadcast for incoming calls in my android device. and for this I have used the broadcast receiver with action PHONE_STATE & register it statically in AndroidManifest.xml as per below added screenshot :
This broadcast is working fine till my app is in foreground or active in recent apps. But It's not working after my app gets killed from recent apps.
and this broadcast action has exempted from limitation of broadcast mentioned in this link: https://developer.android.com/guide/components/broadcast-exceptions.html
I have tried by registering this broadcast from my Activity & also by registering it statically in AndroidManifest.xml file But still I am not able to get any broadcast after my app killed from recent apps.
I want to get broadcast every time for all the incoming calls even after my is not active or got killed from receiver.
Please give some solution to achieve this. or
Please suggest me any other solution or any other broadcast through which I can achieve this.
in my app I use 3 broadcast receivers for the following broadcasts:
android.net.wifi.STATE_CHANGE
android.intent.action.ACTION_POWER_CONNECTED
android.intent.action.USER_PRESENT
Now, before Android O, everything was working fine. But since new limitations on background work, I'm having trouble with those broadcasts.
I constantly need to receive broadcast on events like change in WIFI state, or if the is device still or is in motion, even when the app isn't running.
I tried using JobScheduler to listen to wifi broadcasts, but it seems that the system still kills the service after certain time, moreover it stop working when I swipe the app out from recent-apps.
I was thinking, is using foreground service, to register the broadcast, is a good idea to solve this problem?
What would you suggest to solve this problem?
According to Android documentation usage of Manifest's implicit broadcast receivers is deprecated in Android Oreo and above
https://developer.android.com/about/versions/oreo/android-8.0-migration.html#rbr
I've registered the Intent.action_screen_off/on in my oncreate method of my application, and i can receive the events when my application is running. But when my application exits i get an broadcast intent leaked exception (off the top of my head i think thats what its called, either way its caused by not unregistering my receiver when my app exits)
How can i receive these events when my application is not running? i'd prefer not to use a service or something like that, i've seen other apps do it without services or background processes.
i've seen other apps do it without services or background processes.
That's not possible. The only way to register a BroadcastReceiver other than in running code is to declare it in the AndroidManifest.xml with the relevant <intent-filter>. As it's not possible to do that for either Intent.ACTION_SCREEN_OFF or Intent.ACTION_SCREEN_ON, the apps you've seen MUST have some running component(s) in order to receive the broadcasts.
In short, use a Service - I'm not quite sure why you say you'd prefer not to.
I want to know the difference between services and broadcast receivers, can anyone point out an example that can be observed on android mobile devices.
Thanks
Service: If you want to do something in background , this will be running always in background even if the application closed. You can create this in separate process and also you can give your service to other app if you want. Downloading any content or Music is good example
Broadcast Reciever: Usually system will send some info which can be recieved by your app if you would wish to ,by registering. And you can do something what you want when that thing happens by using onReceive method.
Example is the system will send BroadcastReceiver when new sms arrives or Booting done
Here is good article : Service and BroadcastReceiver
Service is used when you want to do something in background, any long running process can be done using Service in Background. For example, you want to play music when your application gets close. In that case service will be running in background with music.
Example of Service
BroadcastReceiver is used when you want to fire some stuff or code during some event. For example, event can be on Boot of Device. If you want to perform something when device Boots, date and time changed etc...
Example of BroadcastReceiver
I think of it possibly a different way. A Service receives intents that were sent specifically to your application, just like an Activity. A Broadcast Receiver receives intents that were broadcast system-wide to all apps installed on the device.
(The reason I say a Service is a bit like an Activity is that: You wouldn't broadcast a message saying "start Activity MyActivity" across all apps installed on the device. It is only for your specific app.)
Of course, as others mentioned, a Service can continue running in the background, whereas a Broadcast Receiver should finish quickly (e.g. if it is running for more than 5 seconds it may be killed by the OS). The Broadcast Receiver can still run in the background (when app is closed) under certain circumstances. For this, it's worth mentioning that there are actually two types of Broadcast Receivers - Manifest-declared, and Context-registered. They have different lifespans and restrictions - the former can receive broadcasts in the background with certain restrictions, while the latter cannot receive broadcasts in the background (app must be running and active) but has no restrictions on the types of intents that can be received.
Both services and broadcast receivers must be specifically invoked (via an intent), but for services this is usually a specific call (e.g. when your app is started or when the user clicks some button) whereas for broadcast receivers they don't need to be explicitly started as they will start anyway when a relevant broadcast is made.
Here's how I would think of it:
Type
Displays UI?
Can continue running for a long time when app is closed?
Can receive intents when app is closed?
Intents must specifically target your app?
Restricted list of intents that can be specified?
Activity
Yes
No
Yes
Yes
No
Service
No
Yes
Yes
Yes
No
Manifest-declared Broadcast Receiver
No
No
Yes
No
Yes1
Context-registered Broadcast Receiver
No
No
No
No
No
1: Only if you target Android 8.0 or above. The restrictions are not applied if the intent specifically targets your app. The restricted list of intents can be found here.
I have written android app which kills background processes. My app looks for running processes lets say if browser opens it will close and kill it. Now it will check again this after some delay.
The thing annoying me is that I have to refresh it again and again, I need to catch any app launched on phone or something else and see whether lets say 'is a browser' then close and kill it.
Any efficient method to solve this problem ??
You can use a broadcast receiver, this sits and waits for the system to send it a prompt. Standard actions at the moment are:
Standard Broadcast Actions
These are the current standard actions that Intent defines for receiving broadcasts (usually through registerReceiver(BroadcastReceiver, IntentFilter) or a tag in a manifest).
ACTION_TIME_TICK
ACTION_TIME_CHANGED
ACTION_TIMEZONE_CHANGED
ACTION_BOOT_COMPLETED
ACTION_PACKAGE_ADDED
ACTION_PACKAGE_CHANGED
ACTION_PACKAGE_REMOVED
ACTION_PACKAGE_RESTARTED
ACTION_PACKAGE_DATA_CLEARED
ACTION_UID_REMOVED
ACTION_BATTERY_CHANGED
ACTION_POWER_CONNECTED
ACTION_POWER_DISCONNECTED
ACTION_SHUTDOWN
There is also:
ACTION_PACKAGE_FIRST_LAUNCH
but I think this is only sent to the Package that start's the app. (and is API 12)
So yeah instead of polling us a Listener.
Take a look at ACTION_PACKAGE_RESTARTED
Broadcast Action: The user has restarted a package, and all of its processes have been killed. All runtime state associated with it (processes, alarms, notifications, etc) should be removed.
Example Implementation
Perhaps you can use this?
Another function may be useful to you, getRecentTasks.