One-time permissions causing background scheduled jobs and alarms to be cancelled - android

We develop an Android SDK and, while testing the Android 11 Beta, we found a problem that does not seem to be reported yet.
In Android 11, new one-time permissions have been introduced for Location, Microphone and Camera permissions. With this option, as soon as the user leaves the application, the permission is revoked (more details can be found here).
The problem is that after a short amount of time when the app is no longer in the foreground (it is not necessary to kill the app, just minimizing is enough), all future scheduled alarms or jobs are removed, as if the app was force killed.
This only happens with this level of permission.
Denying or providing other levels keep the previously scheduled alarms or jobs, as expected.
We have reproduced this in the Beta 3 build, in a Pixel 2 emulator with the RPB3.200720.005 build number. In this repo you can find a sample app for reproducing the bug.
This single activity app schedules an alarm to ring in the next five minutes, as well as a job to trigger in between 5-6 minutes.
The screen has three buttons, each triggering the corresponding permission request.
The JobService and BroadcastReceiver classes only log that they have been triggered.
The situation can be reproduced after the following steps:
Whenever the app is started, it is possible to run both adb shell dumpsys alarm | grep com.example.permissions.app and adb shell dumpsys jobscheduler | grep com.example.permissions.app to see that both the alarm and the job are scheduled;
Click in any of the buttons and grant the one-time permission level;
Minimize the app (you can go to the home screen or open other app);
After around a minute, run both adb shell dumpsys alarm | grep com.example.permissions.app and adb shell dumpsys jobscheduler | grep com.example.permissions.app. The alarm and job will no longer appear;
Waiting the original scheduled times for both job and alarm (with lenience for system delays) will show that they won't be triggered.
Have any of you encountered a similar situation? Our hunch is that to revoke the one-time permissions, the app process is being killed in some way that is causing these side effects.
We also submitted an issue on Android Issue Tracker, and we will keep this post updated if Google answers it.

The issue was 'solved'. The problem was actually with Android Studio calling a force close when the permission was revoked after closing the app.
The actual Google's response:
Thank you very much for raising this issue, and providing sample code
to reproduce it. After investigating further, we discovered that this
is due to an interaction between Android Studio and apps launched via
the "Run" command.
Specifically, when Android revokes an app's permission, it kills that
app's process. We found that Android Studio sends a force-stop command
via adb when it observes the app it launched is no longer running.
If the app is started via the launcher (including in an emulator
that's connected to Android Studio), the app is not force-stopped, and
the alarm and job both run as expected.
So it won't cause additional issues except during development phase. For further information, please check out the Android issue tracker linked in the question.

I know that my problem is not exact with this one but I also encountered this issue in android 11 in google map when I click this one time permission. I noticed that if you left your app for 1 minute in background and go back, the app process was killed.
I have 2 SupportMapFragment inside the viewpager and connected in TabLayout and every time this happen, view will be recreated, however the fragment that was in the current position of the viewpager is not recreated properly.
For those people who encountered this as well, you have to change your flow and use only 1 SupportMapFragment instead of two. In that way, your map fragment will recreated properly. I just handle the map state and marker depending on the tab current position

Related

Android Pie - Overnight Service Killed Consistently

I have an app which runs a background service overnight. It's triggered to run by an alarm clock app.
The app spends the night uploading data off the phone's external SD card onto Dropbox. It worked seamlessly on previous versions of Android but is not working on Pie. The background service is killed after running for about two hours every night. Interestingly, however, I've noticed that if I make a tiny change to my code, e.g. editing a string, and then run a debug, the app runs perfectly the next night but then on subsequent nights, goes back to being killed after two hours.
I've tried the following:
Using a foreground service with a persistent notification
Opening and closing an Activity after the app is opened so it's in the recent apps list
Making the app a device administrator
Disabling battery optimisations for the app
CPU and Wifi wakelocks
Running a thread with an infinite loop that uses root privileges to adjust the app's minfree values every five seconds
Disabling Pie's adaptive battery manager feature during the night
Despite all of these mechanisms, the app still gets killed. My theory is that there's some kind of artificial intelligent battery manager/performance optimiser on the phone that picks up that the app runs all night and decides to kill it in the future but then gets reset when I re-install the app.
I've tried everything and I still can't seem to find a solution. Can someone please point me in the right direction? I'm sure there's some root/reflection thing that I can do to fix this but I just don't know what it is!
I found the problem! Turns out my phone had a service called G3 which was killing the app to "save power". Apparently, this service is useless so I uninstalled it and the problem was solved instantly!
I used the following command:
adb shell pm uninstall --user 0 com.evenwell.powersaving.g3
adb shell pm uninstall --user 0 com.evenwell.powersaving.g3.overlay.base.s600ww
Pretty annoyed that this service took to killing an app that had root, administrator privileges and permission to avoid battery optimisations - how obvious do I have to make it that I want the app to stay alive?!
try job schedular
https://developer.android.com/reference/android/app/job/JobScheduler.html
https://developer.android.com/topic/performance/scheduling.html
use Alarm manager
https://developer.android.com/reference/android/app/AlarmManager.html
As one of the changes that Android 8.0 (API level 26) introduces to improve battery life, when your app enters the cached state, with no active components, the system releases any wakelocks that the app holds.
In addition, to improve device performance, the system limits certain behaviors by apps that are not running in the foreground. Specifically:
Apps that are running in the background now have limits on how freely they can access background services.
Apps cannot use their manifests to register for most implicit broadcasts (that is, broadcasts that are not targeted specifically at the app).
By default, these restrictions only apply to apps that target O. However, users can enable these restrictions for any app from the Settings screen, even if the app has not targetted O.
Nothing will work like job schedular or Alarm manager
Your problem will be only resolved by using WorkManager

Not getting push notification when swipe from recent

I'm not getting notification when user swipe the app from recent. I've notice that behavior occurs in some specific device for instance I've tested it on nexus devices and HTC devices it's working fine but when user swipe the app from the recent in huawei and some samsung devices it doesn't show notification. I mean i don't get onMessageReceived() callback
After some research I found out that in these devices when user swipe it from recent it force stop the app (the process is completely killed) and I don't get any notification. In huawei they have protected and unprotected apps and if I add the app in protected list from the setting, I start getting notification because i this case it doesn't force stop the app. and I believe in samsung they have the same thing with blacklist and whitelist apps.
I've also tried some solutions like restart the service onTaskRemoved() callbacks or make your app START_STICKY. I've also tried WakefulBroadcastReceiver but nothing is working for me.
So my question is how can i get notification even if it gets forced stop, like it's happening when swiping app from recent.
An old question, but I think it’s important to know that HUAWEI has a feature called “power-intensive app monitor “. It kills every app that runs in the background for a long time unless user gives special permissions to it.
The path to do this:
Settings -> Security & privacy -> Location services -> recent location requests: YOUR APP NAME -> Battery -> uncheck Power-intensive prompt, App launch: Manage manually: check all three positions: Auto-launch, secondary launch, run in background.
I don’t know if there's a way to do this programmatically. I think the best way is to create a sort of help activity and explain the user what to do if application won’t work.

Android Lollipop - prevent task manager from ending my app

My goal is to make my app unkillable.
Application has admin permissions granted.
I have one activity and one service.
Applionation cannot be uninstalled while Admin permission is active (thats good).
Service is auto re-creating. That's also correct.
Unfortunately on Android 5 - Lollipop user can click on all apps button - then go to Task Manager and simply END my app without any problems. After that service is destroyed for good (activity too obviously...)
Is this a way to prevent that?
1) Xposed. At the cost of execution speed and dependency on the TaskManager that you will have to reverse-engineer a bit...
2) USER_PRESENT and friends. Your application can register a BroadcastReceiver and re-start on events. That is, it will be killable, but it will restart.
I think you are interested in something like a kiosk mode: displaying a single app and preventing to break out from it.
There are various tutorials out there. This one is quite good:
http://www.andreas-schrade.de/2015/02/16/android-tutorial-how-to-create-a-kiosk-mode-in-android/
Edit: if your main target are Android 5.0+ devices you can also make use of screen pinning. http://developer.android.com/about/versions/android-5.0.html#Enterprise

Automatically return to app after update

We have a security camera android application. That means it stays on while the user is not around. When we release a new version, if Google Play is configured to update automatically, the app closes. This is obviously a problem. Replicating it using adb install I saw that onDestroy isn't even called. How do I make it so the app will return after the update is complete? One idea I had in mind is using AlarmManager that tries to run the activity every 15 minutes or so until the user closes it properly, but it seems inefficient. Is there better way?
There is intent which fires after updating app: android.intent.action.MY_PACKAGE_REPLACED. So just add receiver and launch your service of whatever you need.
Prior 12 API level you can use ACTION_PACKAGE_REPLACED. But it fires each time when any app updates. Sample here: How to correctly filter Package replaced broadcast

Run service and activity in different processes in android

I have the following scheme in my application.
Broadcast receiver listen for an BOOT_COMPLETED action and sets repeating alarm.
Alarm starts a service via PendingIntent.
Service checks for some data by internet, and when new data are available, shows notification, which is runs an activity, when user select it.
All is working perfectly except one thing. When i close the app from Task Manager on my device, process is killed and my alarm no more works. So the process is stopped until next restart of device.
Setting android:process to different for the service and activity does not help. Debugger shows me that we have two different processes, but closing an app from the task manager kills both processes.
I have created two different applications, one just an activity, and the second one for broadcast receiver and service.
In that case all is working as i need. But now i have another issue. Two .apk files. I have tried to find a solution to merge two apk's in one for Market, but looks like its impossible. Ask user for installing two apk for one does not good idea i think.
So my question is how i can solve this?
When i close the app from Task Manager on my device, process is killed and my alarm no more works. So the process is stopped until next restart of device.
This is a good thing. The user, by killing or force-stopping your application, is saying "I do not want you to run again". Developers should respect their users wishes.
So my question is how i can solve this?
Treat your users with respect and allow them to force-stop your app if they choose. You can re-enable your alarms on the next manual run of your application.
You can also detect if they did this, by having your AlarmManager-triggered code keep track of when it runs -- if, the next time the user manually launches your activity, you determine that the alarm code has not run in far too long, that indicates the user force-stopped you. You might use this information to suggest that the user go to your PreferenceActivity and change how your alarms behave (e.g., run every 24 hours instead of every 10 minutes), so that the user does not feel the need to force-stop your application.

Categories

Resources