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.

Android DeviceAdminReceiver: onNetworkLogsAvailable intent never received

UPDATE
I'm noticing that I actually am receiving the NETWORK_LOGS_AVAILABLE intent! The problem is, it's taking a very long time (over an hour?) to receive it.
Is there any known way to increase the frequency of receiving these events?
Original Question
I am trying to process DNS events that can now be read after receiving the onNetworkLogsAvailable intent in a DeviceAdminReceiver application. This functionality was made available as of Android 8.0.
For some reason, I am never receiving this intent, even though I am successfully calling the setNetworkLoggingEnabled method. Upon admin being enabled, I am receiving the ACTION_DEVICE_ADMIN_ENABLED event, but nothing else after that.
Here's where I enable network logging:
public class NetworkAdminReceiver extends DeviceAdminReceiver {
#Override
public void onEnabled(Context context, Intent intent) {
DevicePolicyManager manager =
(DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE);
if ( manager == null )
{
throw new IllegalStateException("Unable to get DevicePolicyManager");
}
if (manager.isDeviceOwnerApp(context.getPackageName())) {
manager.setNetworkLoggingEnabled(getWho(context), true);
}
else
{
Toast.makeText(context, "This application is not device owner. DNS logging only works" +
" when this application is setup as the Device Owner", Toast.LENGTH_LONG).show();
}
}
// *snip* rest of class
}
Although I am not sure whether it's required (cannot find in documentation), I've also added the NETWORK_LOGS_AVAILABLE intent action to the receiver's filter:
<receiver android:name=".admin.NetworkAdminReceiver"
android:label="#string/device_admin"
android:description="#string/device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<meta-data android:name="android.app.device_admin"
android:resource="#xml/device_admin" />
<intent-filter>
<action android:name="android.app.action.DEVICE_ADMIN_ENABLED"/>
<action android:name="android.app.action.NETWORK_LOGS_AVAILABLE"/>
</intent-filter>
</receiver>
The application is marked as the device owner, network logging is enabled, and yet I never receive the intent. The only explanation I could think of is that network logs do not become available very frequently, but I could find no documentation supporting this theory.
I am also currently only testing this in the emulator. I am unsure if that would have an effect on this, though I cannot see how it would.
Is there anything that I am missing in order to properly receive the network logs via the DeviceAdminReceiver?

I'm afraid there's no elegant solution.
This limitation looks like it was made intentionally. As you can see in the sources, the event is triggered when hard-coded thresholds are reached. It's either 1200 events or 1.5H timeout, whichever comes first. I did not manage to find any usable hooks in the NetworkLogger. They definitely did not want users to meddle with it.
The only option I see is to use reflection to get access to the hidden API.
The most straightforward, IMHO, is to get a handle to the IIpConnectivityMetrics service and use it to subscribe to the network events. I did not test this solution myself, though.

It seems like you can now force retrieve log for debugging purposes as described here: https://developer.android.com/work/dpc/logging#development_and_testing
Quote from the documentation:
While you’re developing and testing, you might want to receive onNetworkLogsAvailable() callbacks without having to browse hundreds of web pages. In Android 9.0 (API level 28) or higher, you can make a few sample network requests and force the system to send a logs-available callback. Run the following Android Debug Bridge (adb) command in your terminal:
adb shell dpm force-network-logs
The system limits how frequently you can use the tool and reports any intentional slowing in the terminal output. If there aren’t any logs to retrieve, your DPC doesn’t receive a callback.

Android/Google Play - Can an App Update While it Is Running

I am building an app that is designed to run continuously. Furthermore, the user is locked into the app (via the pinning feature) when it is being used. When the app has not detected user interaction for a while, it unpins itself, calls the Android dream service, and displays a screensaver of sorts. When the user taps the device, it 'wakes up', goes to the main screen, and repins itself.
I need my app to auto-update. However, given the circumstances, I have had difficulty in doing so. It simply does not seem to update, or according to one of my colleagues, updated but closed the app.
Is there a way for the app to detect, download, and install an update while running, and then, if necessary, relaunch itself? What would be the best approach?
Thanks much.

Is there a way for the app to detect, download, and install an update while running
This is handled for you by google play store. An app is killed when it is going to be upgraded to a new version so the installation of the new version is smooth and data is not corrupted.
if necessary, relaunch itself?
If you want to keep running (or rather, restart the app) after an upgrade, yes you have to do some additional stuff.
A way that I use is this:
Put in manifest:
<receiver android:name=".receivers.AppUpgraded">
<intent-filter>
<action android:name="android.intent.action.MY_PACKAGE_REPLACED" />
</intent-filter>
</receiver>
public class AppUpgraded extends BroadcastReceiver {
#Override
public void onReceive(final Context context, Intent intent) {
// your app was just upgraded, restart stuff etc.
}
}
Note there is also a action.PACKAGE_REPLACED which will trigger for ANY app that is upgraded. You're likely only interested in the upgrade of your own app, so use action.MY_PACKAGE_REPLACED.

Android background process - from application start till shutdown

I'm developing an app that calculates an algorithm at the background. Since the application starts, till it ends.
This is a tracking algorithm (with now further explanation about the algorithm operation principles).
So the background task need to be calculated at all screens on the app regardless of user actions on app, clicks, wifi communication messages (already done on app) , everything needs to be done while the algorithm is running at the background.
Is it an AsyncTask ?
If not what else?
The application is running and the algorithm is being calculated at a specific screen now, i want to make it a background process with no respect to current application screen.
An example will be appreciated
P.S- Further developing , do not need to be discussed if not needed right now:
1. The next stage is to insert an indication (virtual bulb) that change between to states depends on algorithm result each time.
2. The algorithm is getting data from USB device attached to the phone as the phone is the host using FTDI chip.

It's clearly a Service that you need - that's exactly their main purpose - to do long-running operations in the background, no matter what Activity the user is playing with in the foreground. You can read more about Services HERE.

Use broadcast reveicer
You need to define a receiver in manifest with action name android.intent.action.BOOT_COMPLETED.
<!-- Start the Service if applicable on boot -->
<receiver android:name="com.prac.test.ServiceStarter">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>
Make sure also to include the completed boot permission
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
Use Service for this to make anything persist. And use receivers to receive Boot Up events to restart the service again if system boots..
Code for Starting Service on boot up. Make Service do your work of checking sms or whatever you want. You need to do your work in MyPersistingService define it your self.
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.util.Log;
public class ServiceStarter extends BroadcastReceiver {
#Override
public void onReceive(Context context, Intent intent) {
Intent i = new Intent("com.prac.test.MyPersistingService");
i.setClass(context, MyPersistingService.class);
context.startService(i);
}
}

It's clear that you need execute your algorithm in a independient thread. You must choose how you want do this.
My recommendation is a Service or a IntentService.
https://developer.android.com/training/run-background-service/index.html
You can get a fantastic example here, with a Service which is running in the background and a TimerTask executed each a period of time.
App to monitor other apps on android

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