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.
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.
OK, but then I don't really understand how a widget would be different.
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:
All mentioned application work continuously (in background) because of active widgets.
Following application aren't able to work in background:
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:
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 :)
I guess it makes sense. Feel free to send a pull request if you manage to implement it.
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 :)
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?
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.
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.
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?