I am having problems while doing work in the background in Android. I need to do a http request every 5s in a app of my own use (won't publish the app). I've seem that since version O Android had put limitations on the operational system and I'm doing what is recomended, that is, I'm creating a foreground service with a persistent notification to run this task. It works fine with the screen on, and even with the app closed, but after a while if the phone is locked it enters the Doze mode and lock my requests until I turn the screen on again. I've tried to mess with the power savings configurations of my phone with no luck.
Anyone have faced that issue?
Preferably without FCM (Firebase Cloud Messaging).
I am doing it on Xamarin.Forms, but if you have some example in Java that's ok, I'll get the idea.
You have to set REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission in your manifest.
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
Also you have to ask the user to put your app on the Battery_Optimization whitelist at runtime, like descriped here:
//check for ignoring battery optimization
PowerManager mPowerManager = (PowerManager) your_context.getSystemService(Context.POWER_SERVICE)
if (!mPowerManager.isIgnoringBatteryOptimization(your_context.getPackageName())) {
//ask for permission
Intent intent = new Intent(android.provider.Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
intent.setData(Uri.parse("package:" + your_context.getApplicationContext().getPackageName()));
startActivity(intent);
}
BUT your app is most likely not going to get approved by Google Play, when you try to release it to the PlayStore!
You should use FCM high-priority messages instead.
There aren't too many ways to do it on Android in nowadays.
Try to look at this Google tutorial and choose the right one.
Regarding the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission, your app should fit these conditions.
You'll find more details here android-doze-standby.
Honestly if you need do a task every X seconds use an alarm broadcast:
https://developer.android.com/reference/android/app/AlarmManager
You just implement a receiver and you can perform the task. If you need it in a specific class implement the receiver as in inner class running on a new thread re-registering the alarm every time.
Related
I have an Android app on Play store for 8 years. Recently Google release Android S or 12 introduce some limit with Foreground service launch restrictions
https://developer.android.com/about/versions/12/behavior-changes-12#foreground-service-launch-restrictions
and
Exact alarm permission
https://developer.android.com/about/versions/12/behavior-changes-12#exact-alarm-permission
In the app I use foreground service and alarm clock to schedule update weather data from the cloud and device sensor and send notification to user, update the widget.
But they said: Exact alarms should only be used for user-facing features so if I continue use those API, it is safe (with Google Play policy)?
I ask this because other solution like sticky notification with foreground service and workmanager not work as my requirements.
if you are testing android 12 then don't forget to add this line to Manifest
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
Yes, the android.permission.SCHEDULE_EXACT_ALARM it's safe to use, on Android 12 this permission is automatically granted by the Android system but on Android 13 you need to check if the user has granted this permission.
So you need to add the permission to the manifest
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
And then you need to check if the permission was granted, if not granted then you need to redirect the user to the Alarms & Reminders page
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
val alarmManager = ContextCompat.getSystemService(context, AlarmManager::class.java)
if (alarmManager?.canScheduleExactAlarms() == false) {
Intent().also { intent ->
intent.action = Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM
context.startActivity(intent)
}
}
}
Google also suggests that you need to check any changes on this permission by registering a Broadcast Receiver and check the changes on ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED
Google states: "(when your app) requires precisely-timed actions". Your use case is "to schedule update weather data (…) send notification to user". While this might be user-facing, it doesn't seem to require to be precisely on a certain time. I would guess your app doesn't qualify.
The methods requiring the additional permission are currently: setExact(), setExactAndAllowWhileIdle() and setAlarmClock(). Repeating alarms will always be inexact. Seems like getting processing weather data and device sensors is something repetitive anyway.
From what you've mentioned, you're talking about user-facing features.
A hypothetical example of the opposite would be Facebook forcing synchronization of user data at some specific time. That would be bad because it's preferable not to force a schedule on those types of things as it doesn't matter whether it happens at a specific time or a minute later when system resources are not used by some other service.
Also, "should" means it's a recommendation. Facebook can do the above, but it would be a less optimal solution. It's best to leave control over those kinds of services to Android as it would likely do a better job at distributing resources and preventing lag. So in other words, you not listening to their recommendation won't get your app removed from the app store or something like that.
Also, the paragraph you quoted from the second link, has a link to examples of acceptable use cases, and it mentions alarm apps. This is likely why your question was downvoted.
effective solution
you need to add the permission to the manifest before <application
Hi:
I'm curiously about how to show this dialog. When I press allow, the battery optimize is disabled for this app. Is it an new android api
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
String packageName = context.getPackageName();
PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
if (!pm.isIgnoringBatteryOptimizations(packageName)) {
Intent intent = new Intent();
intent.setAction(android.provider.Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
intent.setFlags(FLAG_ACTIVITY_NEW_TASK);
intent.setData(Uri.parse("package:" + packageName));
context.startActivity(intent);
}
}
Also, you need to add the following permission in manifest
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
This is part of the new App Standby feature introduced with API 23 (Marshmallow) alongside Doze Battery Optimization aimed to optimize power and resource usage while the app is in background (App Standby) or when the device has long been in sleep (Doze).
Following is the explanation from the Android Developer's site page:
Specifically, in the App Standby mode, the system determines that an app is idle when the user is not actively using it. The system makes this determination when the user does not touch the app for a certain period of time and none of the following conditions applies:
The user explicitly launches the app.
The app has a process currently in the foreground (either as an activity or foreground service, or in use by another activity or foreground service).
The app generates a notification that users see on the lock screen or in the notification tray.
The app is an active device admin app (for example, a device policy controller). Although they generally run in the background, device admin apps never enter App Standby because they must remain available to receive policy from a server at any time.
When the user plugs the device into a power supply, the system releases apps from the standby state, allowing them to freely access the network and to execute any pending jobs and syncs. If the device is idle for long periods of time, the system allows idle apps network access around once a day.
So, this means that starting from API 23 (Marshmallow), the device may actively put your app on standby, preventing network access (say for task like sync) and limiting (or disabling) background executions. Now, for most of the apps this behavior is fine or you could easily optimize for such behavior, but for some apps out there this may cause some unexpected behavior, especially for apps that have been poorly optimized or use non-standard sync strategies or some other means of background sync/execution.
So to circumvent that, the user can explicitly mark the app as non-optimized and the system will fallback and not put the app to standby, although this leads to a poorer user experience and you should not be doing this for regular apps that could be optimized.
My app main usage is overlay, the overlay is running from a service.
Android Security add the nice "Screen Overlay Detected"
I want to avoid "Screen Overlay Detected" when user tries to change permissions. so... I've add an AccessiblityService that detects:
if ( event.getPackageName().equals("com.google.android.packageinstaller") ){
stopService(myServiceIntent);
}
However, even now I see this message popping. (when my service is stopped...).
I saw Twilight does it without problem.
What am I missing?
p.s. - I've also tried building a signed apk but saw exact same behavior.
It seems I've been able to resolve this.
a) stopService isn't assured your service will be stopped.
as described here :
It will not be destroyed until all of these bindings are removed. See > the Service documentation for more details on a service's lifecycle.
b) I was able to kill my service by sending intent that called stopSelf().
However process killing/starting can be slow.
c) Best resolution: so it seems Android checks for view visibility. no need to kill services or do anything more complicated.
Current way I'm doing it:
- AccessibilityService (already used by my app) monitor "com.google.android.packageinstaller" though it can be refined to class: "com.android.packageinstaller.permission.ui.ManagePermissionsActivity"
Once detected in this class, we send Intent to "duck", and when we're out, we send another intent that we're back on.
The service handles those calls by:
[ourView].setVisibility(View.INVISIBLE); // when permission settings shown
[ourView].setVisibility(View.VISIBLE); // when normal flow
As long as Android 6.x is buggy on some devices where this "overlay alert" is displayed without any reason (on 2 to 5% of the devices according to my analytics data), the best solution is to avoid the whole permission process by defining the targetSdk to 22. Take care that you can't downgrade the target sdk for a new version or this will induce a INSTALL_FAILED_PERMISSION_DOWNGRADE error when the user updates requiring an unisntall/install of the app.
i want to know that is there any way i can prevent my android app from killing from task manager. Whether it's any third party app, clears from ram manager or user clicks force stop. i just don't want kill my app from background, It should be running.
How to disable the "Force Stop" button
Short answer: Use the Device Administration API.
How do I demonstrate that it works?
Yes, back to your job. Use the API link provided above and the Api Demos included in Google's sample collection to figure out how to integrate this into your app.
Build the demo and run it on your device.
Choose API Demos->App->Device Admin->General->Enable admin.
Choose Activate once the Device Administration API prompts you with its enabling screen.
Exit the app and attempt to manage the app via your device's settings menu (specifics for this step varies by device).
When viewing the Api Demo's "app info" screen, you should see both Force Stop and Uninstall are disabled.
How do I do this in my own app?
Review DeviceAdminSample.java in the Api Demos app for inspiration. You will need the following:
The following code is what brings up the activation screen:
// Launch the activity to have the user enable our admin.
Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample);
intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
mActivity.getString(R.string.add_admin_extra_app_text));
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
However, there are a few other pieces you will need to get this to work:
A broadcast receiver that derives from DeviceAdminReceiver.
Entries in your manifest file that refer to the above broadcast receiver.
Permissions in your manifest for using the Device Administrator API.
An xml file stating what policies your app can access.
All of this can be found in the above links. Good luck with your client!
This might be a dirty way to do this. But it worked for me.
Just override onDestroy() method in service and start that service again.
#Override
public void onDestroy() {
Intent intent = new Intent(this,YourService.class);
startService(intent);
}
I have an App that listens to android.location.PROVIDERS_CHANGED broadcast to stay aware of the phone's current location capabilities.
With Android M and the new App-runtime permissions, it works normally when the location is changed from the system/general panel. But if a user disables the location permission specifically for the App, the same broadcast is not fired.
So far I can test for location access with a regular AlarmManager, but it's quite odd and not very responsive.
Is there any other specific method, ideally a kind of BroadcastReceiver to register that keeps us informed of this location app-permission-change with Android M?
Sorry, but you are not directly notified about permission changes, for locations or other permissions, unless there's some undocumented hack that I'm not aware of.
If the user revokes a permission, your app's process will be terminated. The idea is that you will find out about the revoked permission when your app runs again and you call checkSelfPermission(). That flow is optimized for more conventional cases, where the permission checks are being conducted in an activity opened by the user. It doesn't handle your case very well (though, IMHO, location permissions shouldn't affect the broadcast as you describe).
In the N Developer Preview, you can now set up JobScheduler to monitor a Uri for changes and trigger your job as needed. This is a bit like registering a ContentObserver, except that you don't need the process running all the time — JobScheduler registers the observer and just invokes your JobService as needed. I think that the roster of enabled location sources is found in the Settings provider somewhere; if so, for Android 6.1/7.0/Turbo System 5000/whatever N turns into, you might be able to use JobScheduler to find out about the location source changes, instead of relying on the broadcast.
That doesn't help you for Android 6.0, though. You can use JobScheduler or AlarmManager or something to see if you lost the permission (via checkSelfPermission()), but that's kinda wasteful of battery life (and, as a result, will not work well given Doze mode and possibly app standby).