If the user has left the app via the back button key and the app contains a broadcast receiver for wifi state changed will a change in the wifi state trigger the 'left' app receiver and resume the app? Or will the receiver only work while the app is visible?
If you have registered for the intent-filters in your AndroidManifest.xml, the receiver will be called regardless of whether or not your app is in the foreground or even running. The BroadcastReceiver will be garbage collected the moment onRecieve is done though, thus you are not allowed to do any threading in the BroadcastReceiver. You are limited to starting an activity or binding to a service.
Related
I want to check when a user Unlocks his device, and run a piece of code. How can I know If user unlocked?
I tried creating a broadcast receiver, registering it in the manifest with an intent filter for action USER_PRESENT. But from android Oreo restrictions were imposed on broadcasts.
I've tried an implicit broadcast receiver, but its life ends with the app getting killed.
"How to get unlock or USER_PRESENT event even after the app is killed"
can a background service be used here?
or any other broadcast?
I am working on internet calling app. In my app I am using to BroadcastReceiver to invoke call screen when app receives FCM data message with some specific keys. Normally is working fine, but if I swipe out my app from recent apps list it is not working. It seems like my BroadcastReceiver stops working after swiping app because all the FCM services are still and it receives FCM messages too and showing in logcat too.
I am registering my broadcast receiver in java code (not in manifest).
I used a service class to register broadcast receiver and also overrided onTaskRemoved() and used AlarmManager to keep service running but its not working too.
Why the BroadcastReceiver won't be fired and how to solve the problem?
I am registering my broadcast receiver in java code (not in manifest).
That's the cause of your problem. When user swipes away your app from recents list, the process of your app is being destroyed. Thus, your BroadcastReceiver is being destroyed too.
Register your BroadcastReceiver in AndroidManifest, then onReceive() will be called regardless your app has a running process or no.
I am a bit confused about this part of documentations:
A BroadcastReceiver object is only valid for the duration of the call to onReceive(Context, Intent).
Once your code returns from this function, the system considers the object to be finished and no longer active.
What does "no longer active" mean? It means our receiver won't receive any events with the specified type? Or it means the receiver is destroyed and a new one is created when the event occurs?
Is this any difference about this, between registering receiver in manifest file and in code dynamically?
"Is this any difference about this, between registering receiver in manifest file and in code dynamically?"
Yes, there is a difference. Receivers registered in the manifest file will receive all intent-filters it matches, anytime the OS sends them out. This differs from registering a broadcast receiver in code by the broadcast receiver in code will only listen to broadcast intents while you have set it to listen. The reason you would use this method sometimes, as opposed to just registering it in the manifest, is if you wanted to implement ordered broadcast. For example, (you can build your application in such a way that) a broadcast receiver in an activity would have higher priority than the manifest, that way, if you receive an intent that your application handles, you can present a message in the activity because you know that the user much currently be in your app. If the broadcast receiver is not listening in the activity, then you assume the user is not currently using your app so then you may just want to send a notification. I should mention that ordered broadcast have the ability to abort the propagation of a broadcast intent to the next receiver, which is what you would do if you caught the intent in your activity class ,therefore, the manifest file will only get the intent if the receiver in the activity class did not catch it.
The words "no longer active" mean that the broadcast receiver will just stop doing any work for that particular broadcast. It will still listen to any succeeding broadcast intents just fine.
It means that upon returning from onReceive() the system will consider its process to be empty and aggressively kill it so that resources are available for other more important processes.
You will often use a Service in conjunction with a BroadcastReceiver to keep the containing process active for the entire time of your operation.
How do I make a broadcast receiver which runs always, from the very start of the device? Is this possible without starting the application where it is declared?
If not I guess I would have to start my application when the device starts. But this probably adds to much overhead and it's unwanted.
I want this always runnning broadcast receiver in order to listen always for c2dm notifications. These should notify the user that there are new messages in the application.
If you add the BroadcastReceiver to your Manifest with an Intent Filter to listen for a specific intent, the Receiver will be active upon install.
what do you mean "run always" ?
if you need something to be alive for a long time , and from the OS bootup , you need to :
let the app to be installed only on the internal storage (otherwise it won't work).
set the broadcast receiver to listen to the boot intent .
upon receiving the boot intent, start a service and there listen to the intent you wish to listen to.
I am developing an application that is using bluetooth to automatically connect to nearby paired devices. For that reason I need to listen to bluetooth specific broadcasts like ACTION_FOUND, DISCOVERY_FINISHED etc. , I have to register a broadcast receiver which listens for those broadcasts and performs actions accordingly. Thing is that I need this broadcast receiver to work at any time in the background of my app. I tried to fit it into an intentservice but it turned out that it finishes to fast and onDestroy is called ending my receiver. To overcome this problem I inserted an infinite loop which breaks only when an attribute is turned from true to false. Somehow I feel this is a bad practice and so I am asking you if there is any better solution?
PS. Should I fit the receiver in the main activity? And when does it gets destroyed? Is onDestroy called only when I exit my application with back button, or kill the process with a task killer, or does it occur also when I enter another GUI window in my app?
Thanks, Mike
If you register your receiver dynamically (Context.registerReceiver) it is your job to unregister it (Context.unregisterReceiver) before your activity is paused. And as reading from the documentation:
You won't receive intents when paused, and this will cut down on unnecessary system overhead
onPause will be called when something hides your activity. And you can re register in onResume.
However, this is not what you need. If you want to receive broadcasts even while your application is dead, you need to declare it in the Android Manifest. I think this code will work:
<receiver android:name=".YourReceiverClassName">
<intent-filter>
<action android:name="android.bluetooth.adapter.action.ACTION_FOUND"/>
<action android:name="android.bluetooth.adapter.action.ACTION_DISCOVERY_FINISHED"/>
</intent-filter>
</receiver>