Develop Reference

Android: How to update the UI from a static BroadcastReceiver?

after an extensive search I still can't find a solution to my problem:
I need a Broadcast that runs once a day, no matter if the App is running or not. However, IF the App is running, I also need to update the UI at the end of/after the Broadcast.
I can't use a programmatically registered Broadcast because it ends with the Apps lifecycle. But from a static manifest-registered Broadcast I can't access the UI (at-least I don't know HOW).
One option would be to have 2 different Broadcasts and cancel/start them in onPause and onResume, but I wonder if there is an easier solution?

The thing you need is not broadcast receiver along with AlarmManager or JobScheduler for api above 21 and greenrobot event bus.
AlarmManager Schedules the broadcast call once a day or at any time you want and every time if the broadcast is called you can trigger event from eventbus and receive that event in the place where you want it. The thing why to use event bus is we do not need to handle if the view is visible or not.iF the view is in re use state it triggers the event the view and one method is called by event bus and in that method you can do anything you want to do with view.
personally i don't prefer service because service execution is really expensive now a days.
Note: the package name where you put alarm manager and broadcast
receiver should be "alert" some samsung mobile are very optimized so
they will only let the package name with "alert to run fully". You
will also need on boot receiver to register receiver and schedule
alarmmanager in case if the phone is booted.

Scheduing an event in android

I have to schedule an event in Android. My event is starting a service and just doing the work in background even when the application is not running.
Can I do this even without Broadcast Receiver?
For starting the service, do I need Broadcast Receiver?
I saw some posts, only some of them used Broadcast Receiver :
How to start Service using Alarm Manager in Android?
Scheduling an event in Android
http://www.learn-android-easily.com/2013/05/android-alarm-manager_31.html
http://justcallmebrian.com/2010/04/27/using-alarmmanager-to-schedule-activities-on-android/
UPDATE:
From the posts that I read further, I realize that I have to use Broadcast Receiver if the app is not running at the time of event, but I don't need Broadcast Receiver if my application is running at the time of event. Please let me know if I have reached the right conclusion.

You can use JobScheduler to achieve your requirements .

Do broadcast receivers receive intents when the cpu is off?

I am trying to receive a date change event but suppose the cpu is off will the system send the broadcast and will i be able to receive the broadcast in WakefulBroadcastReceiver and do the work?

The CPU is never totally off. And WakefulBroadcastReciever will just ensure that when an intent is received, the device stays awake until the operation performed in the receiver is finished.
From the documentation of WakefulBroadcastReceiver:
Helper for the common pattern of implementing a BroadcastReceiver that
receives a device wakeup event and then passes the work off to a
Service, while ensuring that the device does not go back to sleep
during the transition.
So it receives a device wakeup event, but doesn't trigger it.
It is the responsibility of the sender to ensure that the broadcast is received properly. You can use AlarmManager for this purpose. Here is a tutorial.

Android CALL_STATE_OFFHOOK received after a very long time

I have a call recording app that reacts to call state changes from a dedicated BroadcastReceiver.
BroadcastReceiver is registered correctly in my manifest, along with the PROCESS_OUTGOING_CALLS and READ_PHONE_STATE permissions.
My issue is that for some reason, in some of the calls I get the CALL_STATE_OFFHOOK state broadcast several minutes after call has already ended.
It seems that the broadcasts are somehow stuck, and then triggered after a while. The 'CALL_STATE_IDLE' subsequent broadcast is received approximately after X time since CALL_STATE_OFFHOOK broadcast, where X is the time the actual call took.
My logs verify that previous onReceive calls are not hanging the process or the BroadcastReceiver.
What can be the cause for such behavior?
UPDATE:
I found that this occurs after I turn my Wi-Fi on or off and start a call relatively close to Wi-Fi change.
Is this the cause for the issue or a symptom of the actual issue?

In Android System, broadcast are processed internally.
Sometimes, due to system loading/ restart/ high runtime, the broadcast receiver gets time to receive some intent
Workaround is, to add Flag FLAG_RECEIVER_FOREGROUND to intent sending broadcast
intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
This will speed up the broadcast delivery much than before in problem scenario

It turned out to be a bug in the Broadcast sending by android (or alternatively some malfunctional receiver). Investigating log cat showed that some system receivers did get broadcasts on time while others (prior to mine) received it after a long time.
This happens frequently whenever Wi-Fi state changes during call start.
What I did was creating an ITelephony proxy (credit to End call in android programmatically) and monitor its state.
Thanks for the helpers :)

Clarification of AlarmManager behavior in Android

I see all the examples of AlarmManager being set by an Activity.
My question is this:
If my application sets a recurring AlarmManager, does that persist even after the application that started is is closed and removed from memory?
If not, how do I start an AlarmManager at a lower level that is started by Android at boot up and if it ever fails or dies or throws an exception is restarted without the user having to do anything?
Lastly, if the action I wish for the BroadcastReceiver to undertake has no visual components, do I still have to create a separate Activity for it? In my case I want there to be a background uploader that wakes up and looks into a folder and if it sees files in that folder, sends them off to the server. I don't need any feedback to the user.
So, my ideal would be to have a magical, OS based AlarmManager that calls an IntentService which just handles the uploading, but I'm unclear on how to get such an AlarmManager running in the first place.
TIA

Yes, AFAIK the alarms "survive" and keeps getting triggered, even after the activity that registered them ends. But they don't survive a phone reboot.
If I understands your problem correctly, I think you can achieve what your looking for by creating a project with a broadcast receiver that listens for android.intent.action.BOOT_COMPLETED intents and then (re-)register a repeating alarm, which in turns starts a (Intent)Service to do the uploading.
You don't need an activity, but you probably would want one anyway, to let the user temporarily disable the upload mechanism by checking off a checkbox, or something. It would probably also be nice to let the user choose the frequency of your alarm, i.e. how often the service should be started and look for new files to upload. This would also be a good place to register your alarm for the first time.

I agree with Nicolai that you'd have 2 broadcast receivers in your application :
one that re-register the alarm on boot
one that starts your service when triggered by the alarm
You could still have an activity but it shouldn't be started by the alarm receiver (hence the service) : instead, maybe launch a notification as you start your service, with the user having the possibility to launch the activity from the expanded message of the notification.
maybe also think about setInexactRepeating (instead of setRepeating) for your alarm, as well as using a worker thread to handle the long uploads (in case the user wants to use your activity in the main thread at the same time).