How to keep app running on Android 9?

AntonK4 months ago

I've been using the client on older versions of Android (up to 7.0) just fine - it works qute good.
However with the same settings on a more recent Android 9.0 (Oukitel Y4800) the system just kills the application (presumably together with the service) after some time when the app is in background. Changing battery optimization or adding the app to the "white list" just doesn't help - the "task manager" (a kind of built-in application) just frees the memory (the device has 6 GB of RAM!). The system does the same for other non-system apps, and the only workaround (I'm aware of) is to have an app's widget (which can update itself) on the home screen (so I have to add an app's widget on home screen just to keep this app running in the backgound).
Are there any other workarounds to keep the app running?
Probably a kind of live widget can be added in the future version? To make it useful the widget can show the service's state - running or not.
Any other ideas?

Anton Tananaev4 months ago

Are you using the latest version of Traccar Client? Make sure you follow all the recommendations for your device model.

Probably a kind of live widget can be added in the future version? To make it useful the widget can show the service's state - running or not.

Traccar Client should have a sticky notification indicating if it's running or not. If you don't see that, something is wrong.

AntonK4 months ago

Traccar Client should have a sticky notification indicating if it's running or not. If you don't see that, something is wrong.

The notification disappears after some time, when the system kills the application while it is running in the background. And that is the problem.

Anton Tananaev4 months ago

OK, but then I don't really understand how a widget would be different.

AntonK4 months ago

Probably newest versions of Android tuned for "battery optimization" handle notifications differently.
Based on my experiments with Oukitel Y4800 (Android 9) I tend to think that the app's widget makes the difference, but it should be "alive" (updatable by the app).
I have few applications which should keep running in the background, and unless I put their widgets on 'desktop' they stop working and their notifications disappear as well.
Here are some examples:

  1. App Usage (com.a0soft.gphone.uninstaller) (the widget shows usage statistics)
  2. Automatic Call Recorder (com.appstar.callrecorder) (I'm using an old version 5.43.11 from 4pda; the widget shows amount of calls)
  3. NetGuard (eu.faircode.netguard) (the widget displays the state of the service)

All mentioned application work continuously (in background) because of active widgets.

Following application aren't able to work in background:

  1. Automate (com.llamalab.automate) (I'm not sure whether the flow widget helps)
  2. Redirect Pro (com.tobino.redirectsfree) (an old app which isn't available in Play Store any more, I install it from APK; it provides a widget button to start all planned operations, but it doesn't help it to stay alive, though the widget is functional only in the paid version)
  3. Resilio Sync (com.resilio.sync) (it doesn't provide a widget)
  4. Traccar Client (the widget button to start/stop service doesn't help)

I also tried running the test with DontKillMyApp (com.urbandroid.dontkillmyapp) - for 1 hour it reported only 8% of activity, and the phone was used occasionally:
Report by DontKillMyApp

I guess, the approach implemented in NetGuard is a way to go - similar widget showing the state of the service could help to keep the app alive on smartphones where energy optimization is too aggressive (or buggy).

PS: I had to remove all links to Play Store for mentioned apps, because the forum engine didn't like them :( In this case the site just shows a kind of technical page with short text 'Forbidden' - not very user-friendly, but that's a different story :)

Anton Tananaev4 months ago

I guess it makes sense. Feel free to send a pull request if you manage to implement it.

AntonK4 months ago

I've added the feature request #429 so it won't get lost.
I'm not sure whether I will have enough time to master this feature implementation, and I don't mind if someone else will pick it up :)

AntonK4 months ago

Here is the log fragment from Oukitel Y4800 (filtered with traccar):

01-29 13:07:06.451  1060  4223 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.traccar.client/.Launcher bnds=[24,711][282,1020]} from uid 10033 pid 1833
01-29 13:07:06.497  1060  1079 I ActivityManager: Start proc 11133:org.traccar.client/u0a129 for activity org.traccar.client/.Launcher
...
01-29 13:17:41.802  1833  2142 W PackageManager: Failure retrieving resources for org.traccar.client: Resource ID #0x0
01-29 13:36:46.918  1060  1088 I ActivityManager: Force stopping org.traccar.client appid=10129 user=0: from pid 1060
01-29 13:36:46.918  1060  1088 I ActivityManager: Killing 11133:org.traccar.client/u0a129 (adj 200): stop org.traccar.client
01-29 13:36:46.920  1060  1088 W ActivityManager: Scheduling restart of crashed service org.traccar.client/.TrackingService in 1000ms
01-29 13:36:46.934  1060  1088 I ActivityManager:   Force finishing activity ActivityRecord{1b819fc u0 org.traccar.client/.Launcher t2010}
01-29 13:36:46.947  1060  1088 I ActivityManager:   Force finishing activity ActivityRecord{6c49931 u0 org.traccar.client/.StatusActivity t2010}
01-29 13:36:46.960  1060  1088 I ActivityManager:   Force stopping service ServiceRecord{570c92e u0 org.traccar.client/.TrackingService}
01-29 13:36:46.962  1060  1088 V ActivityManager: Broadcast: Intent { act=android.intent.action.PACKAGE_RESTARTED dat=package:org.traccar.client flg=0x10 (has extras) } ordered=false userid=0 callerApp=null
01-29 13:36:46.981  1060  1140 W InputDispatcher: channel '869dfa2 org.traccar.client/org.traccar.client.StatusActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
01-29 13:36:46.981  1060  1140 E InputDispatcher: channel '869dfa2 org.traccar.client/org.traccar.client.StatusActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
01-29 13:36:46.990  1060  1077 W InputDispatcher: Attempted to unregister already unregistered input channel '869dfa2 org.traccar.client/org.traccar.client.StatusActivity (server)'
01-29 13:36:47.028   434   469 W SurfaceFlinger: Attempting to destroy on removed layer: AppWindowToken{1a86597 token=Token{5485816 ActivityRecord{6c49931 u0 org.traccar.client/.StatusActivity t2010}}}#0

The application after start was in background.
Does it make sense to handle PACKAGE_RESTARTED and restart the service?

Anton Tananaev4 months ago

This is from the documentation:

Broadcast Action: The user has restarted a package, and all of its processes have been killed. All runtime state associated with it (processes, alarms, notifications, etc) should be removed. Note that the restarted package does not receive this broadcast. The data contains the name of the package.

First of all, doesn't it mean that you already restarted the app anyway? What do you want to handle? Also, it seems like the app doesn't actually receive this broadcast.

AntonK4 months ago

I haven't restarted the app manually - the phone wasn't used.
If the app was actually restarted (probably by the system), it went into a "dysfunctional state" - there was no notification in the notification area, and the service stopped running.

... the restarted package does not receive this broadcast

Well, and how the app is expected to resume its work in this case?
I see it handles both BOOT_COMPLETED, and MY_PACKAGE_REPLACED, but these broadcasts aren't relevant in this case.
Apparently an activty doesn't start either, since the app is in background.