Develop Reference

Code in trying to reschedule previous alarm notifications in android after a reboot? and logs on my phone?

I am trying to follow this answer However, it is not working in simulator nor on my phone so I have questions on the simulator logs and phone and rebooting to simulate this and debug
I have very interesting notes at the bottom that are VERY confusing to me
I am using API 24 and pixel 3 simulator and real samsung 8 phone
I do the typical adds to manifest of
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
and
<receiver android:name=".biz.alarm.BootupReceiver" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
I however never see this log statement...
public class BootupReceiver extends BroadcastReceiver {
private final static String TAG = "BootupReceiver";
#Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
Log.d(TAG, "booted. action="+action);
}
}
For the simulate, I click the play button and watch my app come up. I then hold the power button and it only gives me a "power off" option when I really just want to restart...odd, so I power off. That seems to exit the simulate completely such that when I click play again on the simulator in Android Studio, it then logs
08/06 19:17:40: Launching 'app' on Pixel 3 API 24.
$ adb shell am start -n "app.mykeepintouch.kit/app.mykeepintouch.kit.MainActivity" -a android.intent.action.MAIN -c android.intent.category.LAUNCHER
...
D/MainActivity: onCreate: starting
There is no bootup log for me to reregister notifications. QUESTION 1: Can the simulator not simulate this correctly?
Next, my real phone- Well, the same thing I guess but perhaps there are some logs I can view on the phone itself at least? The post I ran into talked about dumping to sd card but I am plugged into android studio so I would think I could dump logs somehow to android studio?
EDIT: I am using the sample link in that post as well. I did a git clone imported the project, picked API 24 and added a single log in PollReceiver. It worked when I went to bed and did not work the 2nd run when I ran this morning. I will add more info as I debug random scenarios I think of.
WEIRD SCENARIO 1: If I have TWO android studio projects open and open my personal app and then open the sample link app AFTER my project, I see a Toast "Alarms scheduled". I however can find no logs on PollReceiver until that alarm goes off 5 seconds later. I was expecting to see a log from PollReceiver on start but never see that until 5 seconds. Another run of this later yielded no logs (except the toast message popped up so I know it ran that code...very weird). I added a log message then to ScheduledServiceDemoActivity and now I can't reproduce 0 logs like that one time.
WEIRD SCENARIO 2: I REBOOT the phone(or it keeps launching my app and scenario 1 keeps working). Then I ONLY boot the sample link app, nothing ever happens. I wait for 90 seconds and nothing.
This may be why it worked last night before I went to bed as I was in scenario 1.
FINAL GUESSES: I can never get PollReceiver to fire on startup. ScheduledServiceDemoActivity seems to be the true entry point and I never added a service to my above code as I didn't want one...just wanted to be notified of being booted up to reschedule alarms. This then leads me to the possible conclusion the ScheduledServiceDemoActivity is there to fire on certain devices on bootup and the PollReceiver is for other devices on bootup? If so, what simulators can simluate this other bootup scenario?
EDIT (I had another thought) On my samsung phone, I checked the permissions and there is only THREE even though I added these 4 lines in my manifest
<!-- So we can make a phone call out -->
<uses-permission android:name="android.permission.CALL_PHONE" />
<!-- so we can send a text -->
<uses-permission android:name="android.permission.SEND_SMS" />
<!-- So we can reschedule alarms that went off while powered off -->
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<!-- read contacts so they can easily choose their friends -->
<uses-permission android:name="android.permission.READ_CONTACTS" />
The receive boot is not in there. is this the issue? OR do phones not list the receive boot completed to users as it might be confusing?
thanks,
Dean

Try to add this to your intent-filter in your manifest:
<receiver android:name=".biz.alarm.BootupReceiver" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.intent.action.QUICKBOOT_POWERON"/>
</intent-filter>
</receiver>
It helped me when I got similar issue with some devices.

You should look into setExactAndAllowWhileIdle
From what I understand it will execute regardless of if the phone is in doze or not and exactly at the specified time.
You answered their own question here but because that answer utilizes the WorkManager API which "is intended for work that is deferrable—that is, not required to run immediately—and required to run reliably even if the app exits or the device restarts" (source) I feel that utilizing AlarmManager is the best way to handle what it seems that you are trying to do.
However, it should be noted that this will still require the alarms to be re-registered on every boot, which may seem difficult given OP's questions and concerns, but I have addressed those below. Though, you should be careful about what you do if you boot after an alarm was supposed to trigger. For example, suppose you are making an reminder app that you would like to be able to schedule notifications to go of and happen stance your phone powers off just before a reminder was supposed to be triggered and it powers on 5 minutes after it was supposed to be triggered. Do you still trigger the notification? Do you reschedule it with AlarmManager? Do you just ignore it all together? If you do trigger it, do you want it to be triggered before the user unlocks there device or is after they unlock the device acceptable?
The above questions are things that would change the exact implementation, however the basics are the same across the board.
Register an intent receiver with the system
<application>
<!-- ... -->
<receiver android:name="RECEIVER_NAME">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
<!--<action android:name="android.intent.action.LOCKED_BOOT_COMPLETED"/> this action is sent before the user unlocks their device-->
</intent-filter>
</receiver>
<!-- ... -->
</application>
Re-register alarms with the AlarmManager in the BroadcastReceiver
public class PollReceiver extends BroadcastReceiver {
#Override
public void onReceive(final Context context, Intent intent) {
if (intent.getAction() != null) {
if (intent.getAction().equals(Intent.ACTION_BOOT_COMPLETED)) {
AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
Intent i = new Intent(context, PollReceiver.class);//this will send the intent back to this class, you can make another broadcast receiver for handling the alarm going off though
i.setAction("ALARM_ACTION");
PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, i, 0);
long triggerTime = System.currentTimeMillis() + 60000; //replace this with when you want your alarm to go off (this will trigger 1 minute from now)
AlarmManagerCompat.setExactAndAllowWhileIdle(alarmManager, AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent);
} else if (intent.getAction().equals("ALARM_ACTION")) {
//Show notification or make noise, whatever you are supposed to do when the alarm goes off
}
}
}
}
Addressing the various questions/concerns throughout the question
QUESTION 1: Can the simulator not simulate [reboots] correctly?
It can, however, the issue is that you are running the project to start the emulator, which is not how a phone is powered on. Rather than pressing the run button in Android Studio to start the emulator, you should start the emulator by itself via Tools > AVD Manager > Play Button (under the actions column for the corresponding AVD) or see below for a way to restart the AVD while it is running.
I would think I could dump logs somehow to android studio?
Yes, you can, at the bottom of Android Studio there should be a tab named Logcat. This tab is where any connected virtual devices or physical devices will output logs (you will have to specify which device you would like to view if there are multiple connected). Also, there is the option to use the command line, via adb logcat, or it is also possible via the command line to trigger a reboot via adb reboot. You can also combine the two so that as soon as the phone is able to have adb connected you start listening to logcat, via adb reboot && adb wait-for-device logcat. This works for both physical devices as well as the emulator, the only issue is that this outputs the logs for everything, if you want to search for specific text you can use adb reboot && adb wait-for-device logcat | grep "string-to-search-for" (Windows can replace "grep" with "findstr")
WEIRD SCENARIO 1: If I have TWO android studio projects open and open my personal app and then open the sample link app AFTER my project, I see a Toast "Alarms scheduled". I however can find no logs on PollReceiver until that alarm goes off 5 seconds later. I was expecting to see a log from PollReceiver on start but never see that until 5 seconds. Another run of this later yielded no logs (except the toast message popped up so I know it ran that code...very weird). I added a log message then to ScheduledServiceDemoActivity and now I can't reproduce 0 logs like that one time.
The behavior you describe in the first part is correct and should happen regardless of how many Android Studio projects you have open and which app is run first. The application makes a repeating alarm that will go off in 5 seconds and then every 15 minutes after. If you added the log to the onReceive method, you won't see it until that method is called, which it isn't until the alarm goes off. As for the second part, where you didn't get any logs, you may not have let the application run for 5 seconds so no logs would be printed. It should be noted that when you run the application through Android Studio it is not exactly the same as if you run it from the phone by clicking on the icon. Which would also explain why you were unable to recreate it after adding the log into the activity.
WEIRD SCENARIO 2: I REBOOT the phone(or it keeps launching my app and scenario 1 keeps working). Then I ONLY boot the sample link app, nothing ever happens. I wait for 90 seconds and nothing.
The sample application should trigger a log approximately every 15 minutes, not 90 seconds (900,000ms not 90,000ms). However, the sample application should trigger a log 5 seconds (not exactly 5 seconds though because of the way Android works) after starting the app, or after a reboot.
I can never get PollReceiver to fire on startup. ScheduledServiceDemoActivity seems to be the true entry point and I never added a service to my above code as I didn't want one...just wanted to be notified of being booted up to reschedule alarms. This then leads me to the possible conclusion the ScheduledServiceDemoActivity is there to fire on certain devices on bootup and the PollReceiver is for other devices on bootup? If so, what simulators can simluate this other bootup scenario?
You should really familiarize yourself with the application lifecycle and activity lifecycle. ScheduledServiceDemoActivity is there to be what opens when you start the application via running in Android Studio or by pressing its icon on the launcher, but the BroadcastReceiver is also another entry point for the application. In this case, it is triggered when Android sends an Intent with the action ACTION_BOOT_COMPLETED. ScheduledServiceDemoActivity will never be started on boot. The bundled AVD can properly simulate the bootup scenario and it will trigger PollReceiver.
EDIT (I had another thought) On my samsung phone, I checked the permissions and there is only THREE even though I added these 4 lines in my manifest
<uses-permission android:name="android.permission.CALL_PHONE" />
<!-- so we can send a text -->
<uses-permission android:name="android.permission.SEND_SMS" />
<!-- So we can reschedule alarms that went off while powered off -->
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<!-- read contacts so they can easily choose their friends -->
<uses-permission android:name="android.permission.READ_CONTACTS" />
The receive boot is not in there. is this the issue? OR do phones not list the receive boot completed to users as it might be confusing?
Most variants of Android (if not all) that come on devices will not display the permissions that are considered "normal" by Google. Essentially the only permissions that will be displayed there are the ones that are not automatically granted at install time and are considered "dangerous" as they can impact the user's stored data or the behavior of other apps.

Well, I found the answer
Android 8/9 Notification scheduling
I had no idea you have to google for versions.

Device Owner "Kiosk" App boots before BOOT_COMPLETED and lock task replaces user lock screen for PIN password

I developed a Device Owner App (Full Kiosk) and in Lock Task Mode, that once installed on a provisioned device, it's instructed to set itself on the top of the screen.
Everything was fine until some day ago, when on some devices, after a firmware upgrade, an issue has come out.
Device: BlackView BV6000
Android: 8 Oreo (API l. 26)
At the device boot (or re-boot), the app get opened itself on the PIN screen, above it, and so It stops the device boot as I cannot insert my PIN any more and it occupy the screen as main (and only) activity.
Normally, the boot sequence would be:
LOCK_BOOT_COMPLETED
BOOT_COMPLETED
App start
but in this case the app would open itself in any case once the device has direct booted on the PIN lock screen.
The only receiver I have left in manifest.xml (I have removed all other receivers, but App still opens itself):
<receiver
android:name=".receivers.AlarmReceiver"
android:enabled="true"
android:exported="true">
<intent-filter>
<action android:name="AlarmReceiver" />
</intent-filter>
</receiver>
In my opinion, it would be caused by the fact that as an Alarm it's in the common case always awaiting to be delivered, once the device boots, my app receives the alarm intent, so it awakes the alarm receiver, and in doing so, it for sure awake the whole App, that it would be set-up as Device Owner and in lock taskmode so what I obtain is that my app gets in foreground over the PIN lock screen before I could actually do anything and force me to use it.
Additionaly, the app is set up to be the launcher by following lines:
IntentFilter intentFilter = new IntentFilter(Intent.ACTION_MAIN);
intentFilter.addCategory(Intent.CATEGORY_HOME);
intentFilter.addCategory(Intent.CATEGORY_DEFAULT);
devicePolicyManager.addPersistentPreferredActivity(
adminComponentName, intentFilter, new ComponentName(
context.getPackageName(), MyActivity.class.getName()));
Addirtionally, I make the keyguard disabled by:
devicePolicyManager.setKeyguardDisabled(adminComponentName, true);
My question is: how can I prevent the app to get in foreground over the PIN lock screen? I would like to make my app opening after the lock screen (on real BOOT_COMPLETE) but I don't have any clue about how to prevent the app to boot up once it gets the Alarm intent.

After a bit of investigations I found the origin of the issue.
The solutions is to do not open the app as the HOME app, so that it would override the PIN lock screen on some devices, instead it's important to bind it to be open on the desidered events (i.e. boot, reboot, default action, ...)
Solution's implementation follows:
I removed from my AdminController:
intentFilter.addCategory(Intent.CATEGORY_HOME);
related to devicePolicyManager.addPersistentPreferredActivity(•)
(and also add to be sure of proper reset)
devicePolicyManager.clearPackagePersistentPreferredActivities(
adminComponentName, context.getPackageName());
and also removed from my manifest:
<category android:name="android.intent.category.HOME" />
P.S. I found that the action BOOT_COMPLETED it's not always delivered correctly (even using it together with QUICKBOOT_POWERON), and so that's the reason I was using the CATEGORY_HOME intent.

I changed my previous solution.
As the fact of the BOOT_COMPLETED doesn't triggers so affordably in Android system, also due to Android security policies, even if the app is in Device Owner COSU mode (lock task), I had to revert back to the CATEGORY_HOME intent.
So to solve my previous problem, I found that was caused by calling startLockTask when the app was in background under the PIN lock screen, and usually it would stayed on an activity under the screen. I just needed to add a check as follow to ensure that the app would be locked only if the screen is unlocked.
KeyguardManager myKM = (KeyguardManager) this.getSystemService(Context.KEYGUARD_SERVICE);
if( !myKM.inKeyguardRestrictedInputMode() && MyApp.getInstance().isAppInForeground() ) {
adminController.lockApp(this);
}

onTaskRemoved() not getting called when Home press & kill the app

This question not duplicate of onTaskRemoved() not getting called in HUAWEI and XIOMI devices
Problem:
When I press home button & kill the app onTaskRemoved() (Service class override method) - not called.
If I press back button & kill the app --> onTaskRemoved() called perfectly
This issue happen in Android lollipop versions & oreo versions
MyService.class -> Manifest declaration
<service android:name=".MyService"
android:label="MyService"
android:stopWithTask="false"
android:enabled="true"
android:exported="true"
/>
I already used the return START_STICKY; in onStartCommand()
Tested devices
Lenovo, Samsung - lollipop version
Samsung - oreo version
Any suggestions or comments are welcome. Your small tips will help to fix this huge issue.

Based on your use case, you should be able to meet the criteria for the White listing on Android N and above. You can follow this link to Whitelist your app. By requesting this permission, you can relax some restrictions (like accessing network or holding partial lock) implied by Doze mode and Android O. These restrictions are imposed by OS on the app those are not white-listed.
For Lollipop: Certain manufacturers using cyanogenmod or other custom implementation, could have impact on the intended behavior of START_STICKY. Workaround in this case would be to rely on onDestroy() method of service to:
Restart the service.
Trigger an AlarmManager which will trigger after few seconds and start the service.
If you use approach 2:
On normal devices where the START_STICKY behaves as intended, you can use the AlarmManager to check if service is running by:
Maintain a static variable in service to check if service has been started
Cancel the AlarmManager onStartCommand() of the service.

Xiaomi does not receive notification when application is not running

I am working on an application where I am using Google Push Notification. Application receives notification when it is running in Xiaomi phone otherwise when it's killed it does not receive notification.
If we want to receive notification if application is killed then we need to allow auto restart app manually from security app of xiaomi. I want any trick to do this programmatically without asking user. Is there any way to do this ?
http://en.miui.com/thread-33826-1-1.html

There are five settings that needs to be done manually in case of xiaomi to properly run any application. I have done a lot of research on this and there's no way to fix these settings programmatically. These are the settings:
Auto Start -> ON (Toggle and restart your app)
MIUI Optimization under Developer Options -> OFF
Memory Optimization under Developer Options -> LOW/OFF
No restrictions on background activities under Battery & Performance Settings
Battery Saver -> OFF
There are many other devices in which the manual settings needs to be done in order for the app to work as expected e.g. Lenovo, some Micromax devices. Companies impose these kind on restrictions on background activities to improve the overall battery life. Some apps like facebook and whatsapp work correctly as these might have been included as system apps.

After MIUI 6 & 7:
MIUI power saving mode is default set to "Standard" (Background access to the location services and the network will be restricted)
Where to set:
Settings -> Additional settings -> Battery & performance -> Manage apps battery usage -> Power Saving Modes -> Set to Off (MIUI won't restrict background activities)

As for my understanding once you clear apps or clear memory in Recent Apps menu, xiaomi (or MIUI rom) will force close all the services and memory related to that app similar to user going to settings and force stopping app ,
This Link talks about the same issue, hence all the Broadcast receivers and Services will be ended unless started by the user again, so the notification wont be received,
However you can try just enabling auto-start for your app permissions in settings and If it still doesn't work try creating service that restarts by itself and enable auto-start in the settings,
AutoStart is very important in MIUI, untill its enabled all the notification or app activity will be force closed and will never start

I faced a similar issue and fixed it by adding a BOOT_COMPLETED receiver to my app.
Add following to manifest :
<receiver
android:name=".receivers.BootReceiver"
android:enabled="true">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
Then create your BootReceiver class
public class BootReceiver extends BroadcastReceiver {
#Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
Intent startServiceIntent = new Intent(context, FBTokenService.class);
context.startService(startServiceIntent);
Intent notificationServiceIntent = new Intent(context, FBNotificationService.class);
context.startService(notificationServiceIntent);
}
}
}
It should work with this.

How to start a Service when .apk is Installed for the first time

In my Application I am not having any UI part, so I need to start a Service as soon as the Applicaton gets installed on the Device. I saw many links from which the answer was that its not possible but I guess it is surely possible. Just have a look at PlanB Application on the Android Market that does fulfil my requirement. Below is my Manifest file how I tried, but the Service was not called at all. So, let me know what is the best possible way to start a Service when the Application gets Installed.
UPDATE
I also tried using android.intent.action.PACKAGE_ADDED it works fine for detecting the Package for the other Applications but not for itself.
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.auto.start"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk android:minSdkVersion="8" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
<application
android:icon="#drawable/ic_launcher" >
<service android:name=".MyService">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</service>
<receiver android:name=".BootUpReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
<category android:name="android.intent.category.DEFAULT"/>
<action android:name="android.intent.action.PACKAGE_INSTALL" />
<action android:name="android.intent.action.PACKAGE_ADDED" />
<data android:scheme="package"/>
</intent-filter>
</receiver>
</application>
</manifest>

Fortunately, Plan B does not work on Android 3.1+, as tested on a XOOM and a Galaxy Nexus.
What Plan B does is exploit a security hole that could be used by drive-by malware, which is specifically why Android prevents it from happening anymore.
UPDATE
To clarify: As inazaruk posted and I put into comments on other answers, all applications, upon installation, are placed in a "stopped" state. This is the same state that the application winds up in after the user force-stops the app from the Settings application. While in this "stopped" state, the application will not run for any reason, except by a manual launch of an activity. Notably, no BroadcastReceviers will be invoked, regardless of the event for which they have registered, until the user runs the app manually.
This block covers the Plan B scenario of remote-install-and-run, which they were taking advantage of previously. After all, with that, anyone with a hacked Google account would be at risk of having their device infected, hands-free as it were.
So, when the OP says:
I need to start a Service as soon as the Applicaton gets installed on the Device
the OP will be unsuccessful and will need to redesign the application to avoid this purported "need".

Applications installed on the /system partition are not subject to being placed into the "stopped" state after installation. If you have root, you can do,
$ adb root
$ adb remount
$ adb push your.apk /system/app
And it can immediately receive broadcast intents. This certainly doesn't provide a general purpose solution, but i wanted to mention it for completeness.
EDIT: Keep in mind that different versions of Android locate system APKs in different places. For example, Android 8 puts them under /system/app//.apk. Shell into your device and poke around and follow the same scheme used for other system APKs.

I agree with CommonsWare's answer to question: How to start android service on installation. In other words, you can't automatically start your service after you've just been installed.
One more thing about newer Android platforms: if you don't have UI at all, you'll have trouble starting your service even when using BOOT_COMPLETE intent on Android 3.1+.
That's because all installed applications are in stopped state. In this state applications will not receive ANY broadcast notifications.
In order to activate your application some other application (or user) needs to start your service or activity, or content provider. The usual workflow is when user clicks on your application's icon.
I've written a detailed explanations about this in my blog post.

Plan B does this launch by listening to the events which happen in the system. It uses a receiver which literally listenes to hundreds of events hoping that some of them will eventually fire up. So this is how you can do it. Otherwise, there are no built-in means to launch the application as soon as it gets installed.

I'm not sure what your constraints/purpose is, but if you can install another application that has an activity you can have it send an intent with the flag FLAG_INCLUDE_STOPPED_PACKAGES.
This will use your application for the intent resolution, even though it's in a stopped state. If the action of the intent matches one of your filters, it will also bring the package out of the stopped state.

I don't think so You can start service immediately after installed your application on device,
The application must first be invoked by the user through some sort of Activity.The only things you have to register some Broadcast Receiver with appropriate intents in manifest which invoke you service when something is happening on device but this remaing to Android 3.1 version.
EDIT:
After Android 3.1+ onwards you can not use any Broadcast for starting your application, because all application remains in inactive state after completion of device boot and to launch the application the user have to invoke it.(By touching the app icon).

As stated by CommonsWare in the answer to this question (which I suppose you have all ready seen, but chose to ignore) starting a Service on install is not possible - it is simply not a thing that is implemented into the platform.
Starting it automaticly at the next boot is however possible.
As stated in the Technical Details for PlanB:
Plan B will attempt to launch as soon as it downloads, but in some cases you will need to send an SMS to get it started.
My guess is that on a rooted phone you might be able to start the Service on install - but there's no guarantee that the phone is rooted, which is why PlanB will require recieving a text in some cases because that can be registered by the IntentFilter of the app and then used to start the Service.

there is an app on google play Android Lost which invoke the registration service for google push messages via an incoming sms without launching the app even once for version 3.0+.

Perhaps the best way to accomplish this (and now I'm speaking to the specific intent of the OP, a program that gets installed in order to retrieve a stolen phone, not the general question) is social engineering, not software engineering.
So, an icon with text like "Password List" or "My Bank Accounts" which suddenly appeared on the home screen would undoubtedly be clicked on. Look at the success of all sorts of other phishing, and here you would be targeting a thief, who's already motivated to continue nefarious activity. Let the thief start it for you. :)

HEY I think using a BroadcastRecivier to automatically start the app on restart of device hence it will automatically start on device start.Hope this will help