I have been making an Android app lately..
In it I have used Pending Intent, with Alarm Manager.
I need to have multiple pending intents, and so I am using FLAG_ONE_SHOT. Alarm Manager will send broadcast at mentioned interval. And also, along with that I am using intent's setAction() method and passing currentTimeMillis() as Argument. And I have corresponding Broadcast Receiver. The problem is that once the app is closed, or deleted from the recents tray, the Broadcast receiver is not running.
The code is as follow:
setAlarm:
private void setupAlarm(int seconds) {
AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE);
Intent intent = new Intent(getBaseContext(), OnAlarmReceive.class);
//PendingIntent pendingIntent = PendingIntent.getBroadcast(MainActivity.this,0,intent,PendingIntent.FLAG_UPDATE_CURRENT);
intent.setAction(Long.toString(System.currentTimeMillis()));
intent.putExtra("id", ID);
PendingIntent pendingIntent = PendingIntent.getBroadcast(ChatActivity.this, 0, intent, PendingIntent.FLAG_ONE_SHOT);
Log.e(TAG, "Setup the Alarm");
Calendar calendar = Calendar.getInstance();
calendar.add(Calendar.SECOND, seconds);
alarmManager.set(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(), pendingIntent);}
Broadcast Receiver
public void onReceive(Context context, Intent intent) {
String id = intent.getStringExtra("id");
Log.e(TAG,"On the verge of deleting the message with id: "+id);
SQLiteDatabase database = context.openOrCreateDatabase("/sdcard/userlists.db", SQLiteDatabase.CREATE_IF_NECESSARY, null);
database.execSQL("DELETE FROM " + "MESSAGE" + " WHERE " + "id" + "= '" + id + "'");
broadcaster = LocalBroadcastManager.getInstance(context);
intent = new Intent(COPA_RESULT);
broadcaster.sendBroadcast(intent);}
Manifest.xml
<receiver android:name=".OnAlarmReceive" android:enabled="true" android:exported="true"/>
Please help me. I need the Broadcaster to do the job, even if the app is closed.
It's process life-cycle bug in which system may kill process when app goes in background to reclaim memory
You need to schedule JobService for receiving job whether application is active or not
from official document of Processes and Application Life Cycle
A common example of a process life-cycle bug is a BroadcastReceiver
that starts a thread when it receives an Intent in its
BroadcastReceiver.onReceive() method, and then returns from the
function. Once it returns, the system considers the BroadcastReceiver
to be no longer active, and thus, its hosting process no longer needed
(unless other application components are active in it). So, the system
may kill the process at any time to reclaim memory, and in doing so,
it terminates the spawned thread running in the process. The solution
to this problem is typically to schedule a JobService from the
BroadcastReceiver, so the system knows that there is still active work
being done in the process.
Here is example you can follow to complete your requirement
Related
I have critical reminders that are set via the Alarm Manager (It should function the same way as an alarm clock application).
Previously I had the following in my Android Manifest:
<receiver android:name="com.example.app.AlarmReceiver" >
<intent-filter>
<action android:name="${packageName}.alarm.action.trigger"/>
</intent-filter>
</receiver>
The broadcast receiver:
public class AlarmReceiver extends BroadcastReceiver {
#Override public void onReceive(
final Context context,
final Intent intent) {
// WAKE LOCK
// BUILD NOTIFICATION etc...
}
}
How the alarm is set:
final PendingIntent operation = PendingIntent.getBroadcast(
mContext,
requestCode,
intent,
PendingIntent.FLAG_CANCEL_CURRENT);
if (PlatformUtils.hasMarshmallow()) {
alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerAtMillis, operation);
} else {
alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerAtMillis, operation);
}
}
With Android 8.0 I can no longer use an implicit broadcast as defined in the Manifest. That's fine, the alternative given is to register it manually like so:
final BroadcastReceiver receiver = new AlarmReceiver();
final IntentFilter intentFilter = new IntentFilter(ALARM_RECEIVER_INTENT_TRIGGER);
context.registerReceiver(receiver, intentFilter);
This does not seem logical to me.
The alarm receiver will be tied to the lifetime of the context. This causes an issue when say the application is killed due to memory pressure or when the device is restarted. I need my alarms to fire every time as they are critical for the health of the user.
Even if I listen to "android.intent.action.BOOT_COMPLETED" and register my alarm receiver the app is killed shortly after and no alarm is fired. I also don't see my alarm via
adb shell dumpsys alarm
How do I create a custom broadcast receiver that receives an implicit broadcast to fire an alarm while targeting Android O (8.0)? Can someone enlighten me with a code example or link to documentation. How does Timely or any other alarm clock app function while targeting O?
Revise your code slightly to make the broadcast explicit rather than implicit and you'll be fine (assuming this is an Activity reference or some other Context):
Intent intent = new Intent(ALARM_RECEIVER_INTENT_TRIGGER);
intent.setClass(this, AlarmReceiver.class);
The restriction in Oreo is on implicit broadcast Intent registration, which is to say it you are sending it broadcasts will only action, category, or data specified. You make it an explicit broadcast by specifying the class which is to receive the broadcast.
If you guys are used to check if the alarm has already been registered don't forget to do the same on this verification:
public boolean isAlarmBroadcastRegistered(Context context, String action, Class clazz) {
Intent intent = new Intent(action);
intent.setClass(context, clazz);
return PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_NO_CREATE) != null;
}
I have a problem on my app and I want to report this bug.
I develope the app which can crawls notifications using NotificationListenerService.
It works well.
But NotificationListenerService class has the problem I think.
Because, If the app is crashed, app can't crawl the notification at all,
UNTIL the phone reboots.
Is anyone who can solve this problem??
Please help me.
The bug is very clear!! But It is not easy to find the solution ....
If do you have already permissions then:
In your service class or another service/activity you can switch the "component hability" to listen notifications:
public void tryReconnectService() {
toggleNotificationListenerService();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
ComponentName componentName =
new ComponentName(getApplicationContext(), NotificationReaderV2Service.class);
//It say to Notification Manager RE-BIND your service to listen notifications again inmediatelly!
requestRebind(componentName);
}
}
/**
* Try deactivate/activate your component service
*/
private void toggleNotificationListenerService() {
PackageManager pm = getPackageManager();
pm.setComponentEnabledSetting(new ComponentName(this, NotificationReaderV2Service.class),
PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP);
pm.setComponentEnabledSetting(new ComponentName(this, NotificationReaderV2Service.class),
PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP);
}
Your notification listener, is a SERVICE, it can be killed by System, you can do your service as FOREGROUND to drastically decrease the probability that the system will kill your service.
#Override
public void onListenerConnected() {
super.onListenerConnected();
Log.d(TAG, "Service Reader Connected");
Notification not = createNotification();
NotificationManager mNotificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
if (mNotificationManager != null) {
mNotificationManager.notify(NOTIFICATION_ID, not);
}
startForeground(NOTIFICATION_ID, not);
//Alarm to auto - send Intents to Service to reconnect, you can ommit next line.
alarmIt();
}
If do you like so more "safe", you can to programming not-friendly battery alarms, try to use inexact alarms please, the user's battery will be happy:
private void alarmIt() {
Log.d(TAG, "ALARM PROGRAMMATED at"+HotUtils.formatDate(new Date()));
Calendar now = Calendar.getInstance();
now.setTimeInMillis(System.currentTimeMillis());
now.set(Calendar.MINUTE, now.get(Calendar.MINUTE) + 1);
Intent intent = new Intent(this, NotificationReaderV2Service.class);
intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
intent.setAction(REBIND_ACTION);
PendingIntent pendingIntent = PendingIntent.getService(this, 0,
intent, 0);
AlarmManager manager = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
//The alarms that are repeated are inaccurate by default, use RTC_WAKE_UP at your convenience.
//Alarm will fire every minute, CHANGE THIS iF DO YOU CAN, you can't use less than 1 minute to repeating alarms.
manager.setRepeating(AlarmManager.RTC_WAKEUP, now.getTimeInMillis(), 1000 * 60 * 1, pendingIntent);
}
and next read the Intent to reconnect service binding:
#Override
public int onStartCommand(Intent intent, int flags, int startId) {
Log.d(TAG, "Notification service onStartCommandCalled");
if (intent!=null && !HotUtils.isNullOrEmpty(intent.getAction()) && intent.getAction().equals(REBIND_ACTION)){
Log.d(TAG, "TRYING REBIND SERVICE at "+HotUtils.formatDate(new Date()));
tryReconnectService();//switch on/off component and rebind
}
//START_STICKY to order the system to restart your service as soon as possible when it was killed.
return START_STICKY;
}
Keep in mind that doing all these steps you can sure that your service will be killed anyway by the system but this code will restart the service and make it harder to kill it.
Maybe, you should consider using PARTIAL_WAKE_LOCK with your service and execute it in a process independently (:remote) if you want even more certainty (Maybe this is useless)
I would like to add a common error that is often followed, NEVER override the onBind and onUnbind method or overwrite the INTENT ACTION.
This will cause your service to not be connected and never run onListenerConnected
Keep the Intent as it is, in most cases you do not need to edit it.
I see exactly the same on this. The only "solution" I've found was to have the notification listener running in a separate process. Then if the rest of the app crashes it doesn't stop the listener. So it's only then specifically notification listener service crashes that require the reboot.
Seems a terrible and over complicated solution though.
I had the same problem. Here are few things that I did and now it works wonderfully for me.
Override onStartCommand, call super and return START_STICKY;
Override onNotificationRemoved, call super and add a toast so that you know in android itself that you service has not died yet whenever you swipe a notification.
Exclude your app from Battery saving list (Settings-> Battery-> Power Saving Exclusion)
Post this the service never dies even after the main app's crash. I dont need to reboot now to restart it.
I have a problem with running a service from Alarm manager.
I am building an app that notifies the owner on the namedays of his facebook friends. It all works nicely, but the notification won't show up.
I've set up an AlarmTask that creates the PendingIntent and sets the AlarmManager, like this:
public void run() {
// Request to start are service when the alarm date is upon us
Intent intent = new Intent(context, NotifyService.class);
intent.putExtra(NotifyService.INTENT_NOTIFY, true);
intent.putExtra("notifyID", ID);
PendingIntent pendingIntent = PendingIntent.getService(context, ID, intent, 0);
// Sets an alarm - note this alarm will be lost if the phone is turned off and on again
am.set(AlarmManager.RTC_WAKEUP, date.getTimeInMillis(), pendingIntent);
}
The ID is specific for every nameday.
Now in my NotifyService, I have set up these:
#Override
public void onCreate() {
super.onCreate();
System.out.println("NOTIFICATION SERVICE onCreate()");
mNM = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
}
#Override
public int onStartCommand(Intent intent, int flags, int startId) {
super.onStartCommand(intent, flags, startId);
System.out.println("INTENT RECIEVED: " + intent + " " + flags + " " + startId);
// If this service was started by out AlarmTask intent then we want to show our notification
if(intent.getBooleanExtra(INTENT_NOTIFY, false)){
int ID = intent.getIntExtra("notifyID", -1);
showNotification(ID);
}
// We don't care if this service is stopped as we have already delivered our notification
return START_STICKY;
}
Both the methods are executed once when I start the app, but when the notification should come up, nothing happens.
Is there a way to test if the AlarmManager really executes the PendingIntent?
Should I rather use IntentService? Why/how?
Thanks a lot.
I tried to change it to BroadcastReciever, looking like this:
public class NotificationBroadcastReciever extends BroadcastReceiver{
#Override
public void onReceive(Context context, Intent intent) {
System.out.println("BROADCAST RECIEVED");
}
}
The AlarmTask bit is changed to this:
Intent intent = new Intent("NotificationBroadcast");
intent.putExtra(NotifyService.INTENT_NOTIFY, true);
intent.putExtra("notifyID", ID);
PendingIntent pendingIntent = PendingIntent.getBroadcast(context.getApplicationContext(), ID, intent, 0);
System.out.println("date for notification: " + date.get(Calendar.DAY_OF_MONTH) + "." + date.get(Calendar.MONTH) + "." + date.get(Calendar.YEAR));
System.out.println("epoch time in milils: " + date.getTimeInMillis());
// Sets an alarm - note this alarm will be lost if the phone is turned off and on again
am.set(AlarmManager.RTC_WAKEUP, date.getTimeInMillis(), pendingIntent);
and relevant manifest part looks like this:
<receiver
android:name="cz.cvut.kubispe2.jmeniny.NotificationBroadcastReciever"
android:exported="false">
<intent-filter>
<action android:name="NotificationBroadcast" />
</intent-filter>
</receiver>
I checked if the date that is to be set is equal to the epoch time and it is, but still, the onRecieve method is never called.
Both the methods are executed once when I start the app, but when the notification should come up, nothing happens.
_WAKEUP alarms are only guaranteed to wake up the device if they route to a BroadcastReceiver, not a Service. So long as what you are doing is very short (1-2 milliseconds), you can safely do that work in onReceive() of a BroadcastReceiver. The work you are presently doing in your Service would qualify.
Beyond that, use adb shell dumpsys alarm to confirm that your alarm is scheduled for when you think it is.
Should I rather use IntentService?
It would certainly be a better option than a regular Service, which you are leaking in your current implementation. However, the _WAKEUP limitation still holds, which is why I wrote WakefulIntentService, to help bridge the gap. Again, though, with the current limited work you are doing, just using a BroadcastReceiver should suffice.
try using application context.
PendingIntent pendingIntent = PendingIntent.getService(context.getApplicationContext(), ID, intent, 0);
And work with android logs. Then you will see if it's running in your console
Seems like I finally resolved it, I used the broadcast reciever, and found out where the error was - Calendar takes the month argument from 0 to 11, instead of 1-12, which I thought, since all the other arguments are dealt with normally. So I was just putting up a notification for the end of May, instead of today, when testing.
Anyway, thank you all for help, it was very appreciated.
In mainactivity
I have Broadcast Receiver, pending intent, and alarm manager. It triggers as per selected time (System.currentTimeMillis() + smstimeinmilliseconds).
Intent intent = new Intent(this, DBBroadcastReceiver.class);
intent.putExtra("message", message);
PendingIntent pendingIntent = PendingIntent.getBroadcast(this, id, intent, 0);
AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE);
alarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + smstimeinmilliseconds, pendingIntent);
On selected time, this pending intent triggers broadcast receiver.
public class DBBroadcastReceiver extends BroadcastReceiver
#Override
public void onReceive(Context context, Intent intent)
{
message = intent.getStringExtra("message");
}
I can set message in activity and set time in alarm manager.
Every thing works flawless. I can activate and deactivate this. But if i set few alarm mangers in future time and reboot my mobile. all alarm manager destroy .....
Kindly tell me in steps and sequence what to do with activity , broadcast receiver and do i need service , if yes then how can i use it.
You need a BoradcastReceiver to be called on boot up.
Then you need in your manifest :
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<receiver
android:name=".broadcasts.YourBroadcastReceiverName">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
And this broadcast receiver needs to schedule again all the alarms.
Something like :
public class YourBroadcastReceiverName extends BroadcastReceiver {
private AlarmManagerFacade alarmManager;
#Override
public void onReceive(Context context, Intent intent) {
// Retreive data related to alarms
Cursor cursor = context.getContentResolver().query(Alarm.CONTENT_URI, null,
Alarm.COLUMN_ACTIVE + " = ? ",
new String[] { String.valueOf(1) }, "");
if (cursor.moveToFirst()) {
// Schedule all the active alarms.
alarmManager = new AlarmManagerFacade(context);
do {
// TODO : Schedule alarm according to data in cursor.
} while (cursor.moveToNext());
}
cursor.close();
}
}
(This code is coming from one of my app, some of the objects are not available in the Android SDK)
In order to be able to re schedule all the alarms, you need to have them stored somewhere.
You can write your own ContentProvider for example.
It works well with other android components thanks to the CursorAdapter widget.
It is not the easiest solution but it's the way to go if you want to follow android guidelines.
There may be other simpler alternative to store your alarms, like SharedPreferences.
It's easy to use.
But you will need to hack around to store multiple alarms in a friendly manner.
One last alternative is that you can create an object containing the information, serialize it and store it as a file on the SD Card.
It's ugly and not flexible.
But it not that hard to implement ...
If you want to have a closer look to each storage options, you can read about it in the docs here : http://developer.android.com/guide/topics/data/data-storage.html
I hope all this help you. :)
I have scheduled multiple alarm managers to send intents at different times.
I took care to pass unique ID, context and extras to both the pending intents.
below func handles the alarm calls.
.
public void handle(int duration, int id){
Intent intent = new Intent("package.SET");
intent.putExtra ("package.id", Id);
AlarmManager amg = (AlarmManager)Context.getSystemService(Context.ALARM_SERVICE);
PendingIntent pis = PendingIntent.getBroadcast(Context,Id, intent, FLAG_ONE_SHOT);
amg.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + time, pis); }
there are 2 functions calling the alarm
public void callalarm(int time){
handle(time, UNIQUE_ID1);}
and
public void callalarm2(int time){
handle(time, UNIQUE_ID2);}
I took care that unique ID1 and Unique_ID2 are different.
The broadcast receiver handles the alarm and executes another code.
Is there a possibility that Callalarm1 and callalarm2 interfere with eachother .
I have registered the receiver using registerReceiver function and not in android manifest file.
IntentFilter ARFilter = new IntentFilter();
ARFilter.addAction("package.SET");
context.registerReceiver(AR, ARFilter);
In the AR that extends broadcast receiver, i use the id to define the action.
public BroadcastReceiver AR= new BroadcastReceiver()
{ public void onReceive(Context context, Intent intent)
{ // i do some stuff here which is confidential
}}
The problem is that, I get a delay in the alarms. Is there a reason why there is a delay ?
As of What I know, The Alarm MAnager cannot fire at right times when the task burden on the processor is heavy.
In other words, the broadcast receiver does not receive intent on time since the alarm manager adds the broadcast to the queue which is sent with some delay..
Precise information is helpful.