I made this broadcast receiver
public class DateReceiver extends BroadcastReceiver {
#Override
public void onReceive(Context context, Intent intent) {
Log.i("DATE RECEIVER", "OK");
}
}
registered in manifest
<receiver
android:name=".DateReceiver"
android:enabled="true"
android:exported="false" >
<intent-filter>
<action android:name="android.intent.action.DATE_CHANGED" />
</intent-filter>
</receiver>
It works when device is on but if I turn it off and wait for midnight to pass, then I don't get any intent at reboot. How should I get it?
You won't get this broadcast because date has NOT changed (unless i.e. there's time update after the boot). It is different but has not changed in the way that justifies this broadcast. This may be confusing but in fact it does not matter what time stamp is when device starts. As device was started it does not know if that was because of restart or it was off for 5 weeks. Broadcast will be send if time is artificially changed i.e. due to network time sync, manual time change via preferences, timezone change. Normal ticking does not count. Initial time stamp does not matter.
If you need to know date on boot, you should listen to BOOT_COMPLETED.
You also need to remove android:exported="false" or set it to true as otherwise it is not reachable.
Related
Trying to monitor the offline state of the app by using a broadcast receiver on android.net.conn.CONNECTIVITY_CHANGE but I’m experiencing a huge delay in the connection change when switching on and off the airplane mode, 20 - 30 seconds, is there any faster way? (without polling the connection)
Manifest:
<receiver android:name=".service.NetworkStateReceiver">
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE"/>
</intent-filter>
</receiver>
Receiver:
public class NetworkStateReceiver extends BroadcastReceiver {
public void onReceive(Context context, Intent intent) {
Log.d(TAG, "\t\t\tCONNECTIVITY CHANGED");
}
}
EDIT: there is a D/NetworkChangeNotifierAutoDetect: Network connectivity changed, type is: 5 log in the logcat that is almost instant, is there a way to capture something that triggers that log?
EDIT: found that android.intent.action.SERVICE_STATE is actually way quicker for reconnection. Dropping connection change still 20 to 30s delay :(
In my app, the user can enable a service which does X when Y / X when Z. This needs to be on at all times, but of course Android kills this service when the app is updated. The problem now is that the checkboxes and layoutchanges I make (button-toggles, visibility etc) remain unchanged.
My app's layout depends on SharedPreferences and thus needs to be updated to make changes to the layout. When I update the app, SharedPreferences does not reset like the service making Checkbox1 (which enables services) to stay checked despite the service now being killed. How may I fix that? Would having the checked-state dependant on if the service is running be better than setChecked or SharedPreferences?
Also, how do I notify my user to re-enable the service upon an app-update?
You need to add
<receiver android:name="com.example.receivers.UpgradeReceiver">
<intent-filter>
<action android:name="android.intent.action.PACKAGE_REPLACED" />
<data
android:path="com.example"
android:scheme="package" />
</intent-filter>
</receiver>
Then implement this class UpgradeReceiver and restart you service
public UpgradeReceiver extends BroadcastReceiver {
#Override
public void onReceive(Context context, Intent intent) {
Intent serviceIntent = new Intent(context, YourService.class);
context.startService(serviceIntent);
}
}
User can create different alarms. So it's up to user when to keep alarm and he can keep multiple alarms and I maintain all the scheduled alarms in a database and show to the user for further reference. Below is my code.
if("CREATEONCE".equals(strparam1))
{
am.set(AlarmManager.RTC_WAKEUP, l2, pi);// l2 is time in millis
}else if("CREATEREPEAT".equals(strparam1))
{
am.setRepeating(AlarmManager.RTC_WAKEUP, l2, 86400000 , pi); //l2 is time in millis
}
So this is the code which sets the alarms. User can set multiple alarms. For example he keeps an alarm for 7.00 am for once, 8.00 am for once and 9.00 am dialy. So, for once alarms the code goes to if block and for repeat daily, the code goes to else if block in the code.
If the above 3 alarms are set by user at 6.00 am. If he reboots his device immediately after setting the alarms, the entire alarms don't trigger.
So I have read many posts regarding this like post1, post2. They all just gave to use broadcast receiver to know that device is rebooted. After the broadcast receiver receives a hint that device is rebooted, do I need to repeat above code again by getting the info from sqlite database to make all the alarms work? If so, can someone help me the way to do that from the broadcast receiver? Code snippets are appreciated
Suppose if the user sets 50 alarms, wouldn't it be a long process to get the info of all the 50 alarms and set them again?
I don't know how you are storing your alarms. But I suggest it would suffice to set up a system level alarm for the earliest coming alarm. Then once that is triggered, set up the alarm again for the next soonest triggering alarm.
I suggest putting your AlarmSetting call in a service and then call it from a broadcast receiver.
public class AlarmResetReceiver extends BroadcastReceiver {
public void onReceive(Context context, Intent intent) {
//your code to set up alarms
}
}
There are also other conditions upon which you want to set your alarms up again in your manifest
<receiver android:name=".receivers.AlarmResetReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.intent.action.TIME_SET" />
<action android:name="android.intent.action.TIMEZONE_CHANGED" />
<action android:name="android.intent.action.LOCALE_CHANGED" />
</intent-filter>
</receiver>
For Android devices, is there any way to find out at what time ( or timestamp ) the device turned off?
I dont think there's any predefined support for that. However, its easy to get this done with your custom logic. All, you need to do is to define a BroadcastReceiver which listens for intent android.intent.action.ACTION_SHUTDOWN. Once it receives the intent, simply save the current Date in SharedPreferences, SQLite or where ever you want. Later, the phone is booted, read the saved value to know the estimated time when the phone was shutdown. For example:
receiver code:
public class ShutdownReceiver extends BroadcastReceiver {
#Override
public void onReceive(Context context, Intent intent) {
//save the date here
}
}
and in AndroidManifest.xml
<receiver android:name=".ShutdownReceiver">
<intent-filter>
<action android:name="android.intent.action.ACTION_SHUTDOWN" />
</intent-filter>
</receiver>
I have a little confusion with broadcast receivers. I have a broadcast receiver which is triggered upon TIME_SET and TIMEZONE_CHANGED actions (the code is given below). What I was wondering is, can OnDateTimeChanged (see the code below) be triggered simultaneously (and its execution overlaps) when both TIME_SET and TIMEZONE_CHANGED actions are triggered or is one always going to be triggered after the other? Based on some simple experiments I did, I got the impression that the two executions of OnDateTimeChanged are triggered consecutively with no time overlap but I cannot be 100% sure of this. If anyone has an idea I'll be very happy.
<!-- Excerpt from manifest -->
<receiver android:name=".OnDateTimeChanged">
<intent-filter>
<action android:name="android.intent.action.TIME_SET"/>
<action android:name="android.intent.action.TIMEZONE_CHANGED"/>
</intent-filter>
</receiver>
// Broadcast receiver class
public class OnDateTimeChanged extends BroadcastReceiver
{
#Override
public void onReceive(Context context, Intent intent)
{
// Do some work here
}
}
BTW, both TIME_SET and TIMEZONE_CHANGED can be triggered when under Settings - Date&Time you switch to the Automatic mode and this changes both the time and the timezone.
-Ali
Logically, they would all execute simultaneously. Physically, only one can occupy a core at a time and might finish before another starts. Under identical conditions,the behavior might appear to be consistent. The documentation itself describes it as, "All receivers of the broadcast are run in an undefined order, often at the same time."
If you want to give other receivers a chance to run, you can call Thread.yield().