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
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.
How do I listen to incoming/outgoing calls particularly these 👇 implicit broadcast
android.intent.action.NEW_OUTGOING_CALL
android.intent.action.PHONE_STATE
In =>Oreo android system, these are not allowed to be consumed in the background even though both of them are allowed(i.e. not in exception broadcasts list)
I've tried:
Registering both of the broadcasts in manifest.xml and giving runtime permission then works only while the app is in the foreground
Had a foreground service that context registers these broadcasts, this solution works fine but shows a constant notification, I don't want that
Can anyone describe how TrueCaller or any such app is able to do so without notification?
Looking for solution which works even in if app is not being used
I am trying to make an app that shows some information when you connect your phone to a charger during a specific period of the day.
Before Android Oreo this was easy, just add an Broadcast receiver and add android.intent.action.ACTION_POWER_CONNECTED to the intentfilter in the manifest.
Now I am struggling to find a working solution to create the same functionality.
I thought about periodically checking the device charging state but this feels wrong and it won't trigger immediately on connecting the device to a charger.
Registering the broadcast receiver from my application did not work either, when the application is closed the broadcast isn't received anymore.
Is there a battery friendly way to trigger an action when an Android device is connected to a charger in Android Oreo?
There are broadcasts which are exempted from the background execution limitations and for which broadcast receivers can still be registered in the manifest.
You could use the ACTION_BOOT_COMPLETED broadcast to start a service which registers a receiver for your ACTION_POWER_CONNECTED broadcast at runtime. (The service must be a foreground service. Otherwise, it may be destroyed.)
A other solution would be to use JobScheduler to create a job which requires charging. Then you don't need the foreground service.
Now that the final API for Android O is released and none of the following broadcasts is whitelisted I have the following problem:
In my application (targets API 25) I currently have a BroadcastReceiver which listens for system events of ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED. Now I would like to update my app to target Android O but with this release comes a huge change in broadcast behaviors:
Apps that target Android O can no longer register broadcast receivers
for implicit broadcasts in their manifest. An implicit broadcast is a
broadcast that does not target that app specifically.
Since both broadcasts are implicit I can only register for them via the Context.registerReceiver() method but with this comes the problem: As soon as the process of my app is killed by the system or as soon as system clears my app's memory (as a result of low-memory of device) the broadcast registration will be lost.
To avoid this problem I can use the JobScheduler API with the setRequiresCharging method for ACTION_POWER_CONNECTED but for ACTION_POWER_DISCONNECTED I have to use the registerReceiver method.
Since my app controls the volume of the device (based on these events) it's really important that none of these events is missed. So how can I safely listen for disconnected power events in Android O?
Btw. I have the same problem with WIFI disconnect events.
EDIT: I would love to do this without a notification from a foreground service
Jobs can be delayed without any constraint by the system. The setOverrideDeadline method uses just a best-effort policy, so in this case you can keep your target SDK to 25 or use a foreground service. Foregournd services can be killed by the system but with really low probability.
This may be overkill, but you could register for those broadcasts in a foreground Service that is started by ACTION_BOOT_COMPLETED.
You can register a background job with the JobScheduler using the "requires charging" constraint. At least this is the official solution suggestion.
If a declare a BroadcastReceiver in AndroidManifest.xml, the reciever works, as it should, even on device boot when my application hasn't started yet, but if I force my app to stop from Settings the receiver seems to break down too.
Can it be that "Force stop" in Android 2.2 also makes some cleanup after the application (including BroadcastReceivers or maybe alarms set by the app in AlarmManager which should broadcast the intents I receive)?
By the way, how can I see in Eclipse all broadcasts being sent in the device?
Psycho,
Force Stop should not be used to attempt to test your app from a "non-running" state. I would say the behavior is "undefined" at best. It is not uncommon that after using Force Stop on an app, that you must manually restart it to get ANY of its usability back (including BroadcastReceiver). If your app is able to receive BroadcastReceiverevents including the BOOT_COMPLETE Broadcast than you shouldn't really need to test it further.
I believe the intended purpose of Force Stop was to completely stop an annoying app's functionality. If an app is running in the background often because its receiving a lot of broadcasts and restarting, wouldn't you think Force Stop should prevent that behavior until the app is manually restarted by the user?
Also, I don't believe there is a way to view Broadcast events from Eclipse.
In eclipse there is no way to see the "broadcast is sent"
Also If you have registered the Broadcast in manifest for which you want to receive the event then system will call onReceived method