NOTE: NOW THIS ANSWER IS ONLY VALID FOR ANDROID 7 AND BELOW. SINCE ANDROID 8 GOOGLE HAS CHANGED HOW BACKGROUND TASKS ARE HANDLED Since I posted this question, I have implemented two different approaches to this solution into multiple apps. APPROACH 1 This extract is from an app where I use push notifications, which need … Read more
requestCode is used to retrieve the same pending intent instance later on (for cancelling, etc). Yes, my guess is the alarms will override each other. I would keep the request codes unique.
When canceling the AlarmManager do not use a PendingIntent with a flag of FLAG_CANCEL_CURRENT. Instead, cancel the PendingIntent explicitly after canceling the alarm: am = (AlarmManager) getSystemService(getApplicationContext().ALARM_SERVICE); Intent i = new Intent(getApplicationContext(),AlarmReceiver.class); PendingIntent p = PendingIntent.getBroadcast(getApplicationContext(), 0, i, 0); am.cancel(p); p.cancel();
For Marshmallow era(?), we need some ugly codes like below… 🙁 And “delayInMillis” param should be more than 15 minutes on the API 23. If not, system ignore the minutes less than 15 minutes. private void registerExactAlarm(PendingIntent sender, long delayInMillis) { final int SDK_INT = Build.VERSION.SDK_INT; AlarmManager am = (AlarmManager) mContext.getSystemService(Context.ALARM_SERVICE); long timeInMillis = (System.currentTimeMillis() … Read more
How about this? Intent startIntent = new Intent(“WhatEverYouWant”); PendingIntent startPIntent = PendingIntent.getBroadcast(context, 0, startIntent, 0); AlarmManager alarm = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE); alarm.set(AlarmManager.RTC_WAKEUP, triggerTime, startPIntent); And then in your Manifest.xml file: <receiver android:name=”com.package.YourOnReceiver”> <intent-filter> <action android:name=”WhatEverYouWant” /> </intent-filter> </receiver> So as far as I know you still have to declare the receiver in the Manifest. I’m not … Read more
I had the same problem and after struggling for hours to solve it, I finally found the issue causing it. In your AndroidManifest you probably have something like that: <receiver android:name=”AlarmReceiver” android:process=”:remote” /> The last attribute (process:remote) cause the receiver to run on a different/new process when it is called. But SharedPreferences is NOT supported … Read more
You would not be able to run background services long running in Oreo as there are behaviour changes, now Oreo to optimise system memory, battery etc, it kills background service, to solve your issue you should use foreground service. Have a look at Background execution limits https://developer.android.com/about/versions/oreo/android-8.0-changes A suggestion from me, if you can use … Read more
You do not want to use a TimerTask since this depends on your application running continuously. An AlarmManager implementation makes it safe for your application to be killed between executions. Stating that you tried to use AlarmManager but did not get the desired result is not a helpful statement, in that it tells no one … Read more
The issue seems to occur only on Samsung devices (e.g. Galaxy Grand, S4, S5, S6, Note 3, Note 4) with Lollipop (5.0, 5.1, 5.1.1). It seems that alarms are scheduled inexact when device is on battery with screen off. If device is charging or has screen on during scheduling alarm the issue will not occur. … Read more
have your application broadcast a message as its being killed, and when this message is broadcast, then have a listener check if the service is still running.. if its not run it. This will insure that your service is running even if the application is killed. Update I’ll try to create a flow diagram for … Read more