We have found that our Android device (Samsung Galaxy Tab Active2) kills all apps with a warning message when the battery temperature exceeds about 55 deg. C. The device does not power-down however.
What we want to do is find a way to automatically restart our app when the temperature has come down to a safe level. We are going to try using the alarm manager to schedule a periodic temperature check (assuming the alarms have not been cleared), but is there an specific intent related to the over-temperature condition?
Related
I call startActivity in an implicit broadcast receiver's onReceive function under certain very limited circumstances.
Intent transactionIntent = new Intent(context, TransactionActivity.class);
transactionIntent.putExtra(Constants.Extras.ORDER_ID, orderId);
transactionIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);
context.startActivity(transactionIntent);
I have logs before this line and logs in the onCreate function of the activity. Some customers are reporting random instances of this activity not creating itself. I can see in the logs that startActivity is called and onCreate is not. One of them I know for sure is an Android 8.1 Oreo device. My target SDK is 19 (vast majority are old devices, this is not an app on the Play store). I can also tell the Background activity toggle in the system settings for the app is not switched off so that is not the problem.
What situations can this happen (extreme memory pressure?) and how can I capture it to verify what is going on?
EDIT:
The app is not crashing (no crashes logged for this version of the app, and it does nothing but setContentView before logging the activity creation). I don't think device sleep is an issue because I am targeting pre M, doze mode etc. doesn't come in to play. The user was also using the app a few seconds before this call to startActivity failed, and 30 seconds later they were using the app as well, so that window doesn't seem likely large enough to allow for any kind of sleep or wake lock issues. I also don't think the user could have managed to swipe the app out of memory between the app calling startActivity and onCreate, this is happening sporadically (for this one user is happened 1 out of 6 times).
The app is a for a busy, mains connected Point of Sale device.
We tried wake_lock, we tried to switch from Transition API to Activity Recognition API, we tried to get update via IntentService and BroadcastReceiver, but the problem remains when the phone goes offline(no wifi and no Mobile data) and the screen turns off. In this case our application stops receiving information from the API(onHandleIntent if we work with IntentService or onReceive if we work with BroadcastReceiver is never started).
We also test with Huawei Y6S EMUI 9.1 phone but the problem is the same again.
We noticed that when the phone goes offline and the screen turns off in logcat, this stops appearing:
12-03 13:57:16.965 1366 2098 W AlarmManager: mIsScreenOn is: true, WAKEUP alarm trigger action = com.google.android.location.ALARM_WAKEUP_ACTIVITY_DETECTION package name is: com.google.android.gms
12-03 13:57:16.988 1366 5998 V BroadcastQueue: Finished with ordered broadcast BroadcastRecord{855fb8a u0 com.google.android.location.ALARM_WAKEUP_ACTIVITY_DETECTION}
Is it possible that GooglePlayServices is stoped in this case?
As per Google doc for ActivityRecognitionAPI -
To conserve battery, activity reporting may stop when the device is 'STILL' for an extended
period of time. It will resume once the device moves again. This only happens on devices that support the Sensor.TYPE_SIGNIFICANT_MOTION hardware.
Beginning in API 21, activities may be received less frequently than the detectionIntervalMillis parameter if the device is in power save mode and the screen is off.
Please check your device. What other HUAWEI devices have been used for testing?
Also, this interface is deprecated, use ActivityRecognitionClient.
I am trying to run IntentService as such from AlarmManager setRepeating() for every half an hour. I want to send a to broadcast, from broad cast to intent service. In the service, some functionality will be done.
But, initially the AlarmManager in not triggering while the app is in closed state.
When my app is running or in background state the alarm is working fine and when I close the app the alarm is not working in some devices.
What should I do to run the alarm even if the app is closed?
From the documentation of setRepeating():
As of API 19, all repeating alarms are inexact.
Moreover, setRepeating() does not work with Doze.
You should use exact alarms (set by the appropriate AlarmManager method based on the API level of the device):
if (Build.VERSION.SDK_INT >= 23) {
alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP,
triggerTime, pendingIntent);
} else if (Build.VERSION.SDK_INT >= 19) {
alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent);
} else {
alarmManager.set(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent);
}
And reschedule them every time they fire.
For the rescheduling you could add the original trigger time to the Intent:
intent.putExtra(KEY_TRIGGER_TIME, triggerTime);
Then retrieve this extra in onReceive(), add your desired interval to it and reschedule the alarm using the new value:
#Override
public void onReceive(Context context, Intent intent) {
long triggerTime = intent
.getLongExtra(KEY_TRIGGER_TIME, System.currentTimeMillis());
// adding one day to the current trigger time
triggerTime += TimeUnit.DAYS.toMillis(1);
// set a new alarm using the new trigger time
// ...
}
NOTE: As #Opiatefuchs mentioned in the comment above, some manufacturers (such as Xiaomi or Huawei) may implement certain battery saver functions that can prevent alarms from being fired and cannot be bypassed programmatically.
Nowadays devices are coming with more security in context of Battery power consumption. By default devices keep almost all apps in power saving mode. It means in some devices your background work (Location, Alarm manager) won't work as soon as you come out from the app. In other devices background tasks won't work after a battery threshold limit (like 13%). So you need to keep out your app from this battery saving mode to run your app smoothly even in background. The way to achieve that behavior in these two manufacturers is:
Xiaomi
Go to the Battery => Power => App battery Saver => select your app and choose No restrictions (for Background settings), then Allow option for Background location.
To AutoStart your app after Boot: Go to the Security app => Permissions => Auto start and check your app.
Samsung
Samsung Smart Manager App used to stop all background work after 3 days if you don't come to your app. So the way to disable this feature is:
Go to Battery in the Settings => Unmonitored apps => Add your app to the whitelist. Some other Samsung versions may differ the place to disable it, like Battery => Detail => Select the app and "Don't optimize".
For other devices there should be same power options either in settings option directly or some app are given to handle it.
First, there is a bug with android studio. If you start the app from the android studio and then swipe it away from the recents, the alarms will be deleted. So after that, relaunch your app by clicking on the launcher Icon and then if you swipe it away, the alarm will be still there.
Second, on some devicrs with battery optimization stuff, you should start a foreground service and that works totally fine.
I could make it work using these two points and now it works like a charm.
The below behavior changed after a full charge. Previously, after disabling energy saving for this app, it displayed that there was no battery saving active etc, but only after a full charge (from very low battery state) did the device behave as it should. So change those settings for the app, then do a full recharge (maybe only after previously having low battery). This could fix it.
ZTE Blade L110
Even with the battery saver disabled (Settings -> Battery -> Options -> Battery Saver) and the app marked as important for messages (Settings -> Prompt & notification -> App notifications -> appname -> Priority) it seems like neither setExact nor setAlarmClock are triggering on time.
for Lenovo phone:-
you need to go in setting -> application->select app-> uncheck Restrict to launch
now it will be work in the background as killed state
I'm testing my application on Android P beta release 4. My app's targetSdkVersion is 27
It has been observed that alarm manager notifications are not working as expected. I'm using below code to set the notifications -
if (android.os.Build.VERSION.SDK_INT < Build.VERSION_CODES.KITKAT) {
alarmManager.set(AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmIntentBuilder.buildPendingIntent(context, uri));
} else if (android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT && Build.VERSION.SDK_INT < Build.VERSION_CODES.M) {
alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmIntentBuilder.buildPendingIntent(context, uri));
} else {
alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmIntentBuilder.buildPendingIntent(context, uri));
}
I tested the same logic on Android 8.0 but it's working fine. In Android 9.0, notifications are working but sometimes they did not work at all. Also, if they work they are not exact and takes too much time and this happens even if the application is in foreground.
The logic is, I've the repeating reminders which are set on specific time and those should repeat them-self on daily basis at the specified time. Also these are high priority reminders and should land at exact time so I'm using setExact and once the notification is received it's being display and new alarm for the next week of the same day is set.
I've checked the Android P API documents but could not find any link which has the impact on working of AlarmManager and Notifications. Only thing which I feel is causing the issue is Power management in Android P and the priority buckets. However notifications are not working properly even if application is in foreground.
Anything I'm missing here. Any help is much appreciated.
As you yourself mentioned the new App Standby Buckets feature of Power Management is likely to be the cause. The new documentation states:
If an app is in the frequent bucket [or below], the system imposes stronger restrictions on its ability to run jobs and trigger alarms
and
In particular, the bucket determines how frequently the app's jobs run, how often the app can trigger alarms
Additionally, if you view Power Details you can get a rough idea of the delay times.
Worth noting is that it appears your bucket is based on average usage (and machine learning) not on current usage - which means even if your app has just been in the foreground, the buckets play some role
This is happening because of Power management feature introduced in Android Pie.
In android P, strict restrictions are introduced on the apps running in background. These restrictions are explained here
As we can see in the above link, if we connect the device to charging there are no restrictions imposed on the device and notifications are working properly. However, if we remove the device then Android system adds the certain restrictions for the apps running in background.
We can turn off this restrictions by turning off battery optimization for our application from device settings. Search for battery optimization in settings and turn it off for our application.
Also, testing the notifications by changing the device date and time was a hack that worked fine till now but in Android P, we've to either test them in real time scenario or turn off battery optimization for our application to test them.
I hope this will clear our doubts.
I'm relatively new to android programming but I'm told most applications have a receiver that will cut down on battery expensive activities when android fires ACTION_BATTERY_LOW.
Android developing page says:
public static final String ACTION_BATTERY_LOW
Added in API level 1
Broadcast Action: Indicates low battery condition on the device. This broadcast corresponds to the "Low battery warning" system dialog.
This is a protected intent that can only be sent by the system.
Constant Value: "android.intent.action.BATTERY_LOW"
I was wondering if there was a way to send this intent manually, at any desired battery level. I have a rooted device if that makes a difference.
No. It's not possible. Check this post. Look into the answer given by Mark(commonsware).
Sure there is a way to change the level - just download the terabytes of complete source code and spend a week or two building your own custom ROM, and trying to flash it without bricking your phone. It will only work on your device.
But no, you cannot change it in an app, nor on anyone else's device, and you cannot fire it yourself - did you read the part you quoted, "This is a protected intent that can only be sent by the system."?