Nokia: DuraSpeed app killing system service

[YoRyan]

I have a US Nokia 3.1 that upgraded to Android 9 several weeks ago. HMD had reigned in their task killer on the 8.1 upgrade, but here we are on 9 and (sigh) it's back. Uninstalling com.evenwell.powersaving.g3 seemed to make no difference. Actually, I located all evenwell packages with pm list package -e | grep evenwell and disabled them with pm disable-user, and while my apps survive for a little longer now, they still get killed.

I'm thinking about rolling back to 8.1, but before I do, I was wondering what I can do to identify the task killer and how it works. (I'm thinking it may be a kernel or memory management tunable and not just a system app.) Obviously, the best-case scenario would be finding a workaround so I can stay on P.

[Artaud]

Hey,

we found the offeding app by examining adb logcat. We first observed that alarms on our alarm app wouldn't ring in the morning, so then we just took a full night logcat and tried to find out when our alarm app stopped rescheduling alarms, and roughly in that spot we looked for some hints.

I don't have a rigorous routine to finding an app killer, sorry.

Are you absolutely sure that there is something else killing your apps? As far as I know, HMD Global is currently trying to soften the app killer at least in the Western world, and with the Feb update it has been reported on at least Nokia 8 that the Power Saver does not kill apps aggressively.

[YoRyan]

If the vendors continue to insist on killing apps, it may be worth writing such a routine for interested users. Sort of a CTS for background behavior.

Yes, I'm certain; my Syncthing and Tasker foreground notifications disappear after some period of time, or after I've done something memory-intensive like browsing heavy pages or opening lots of new apps. HMD may be doing something different for their budget handsets. RAM is also a factor, since the 3.1 only has 2GB (but that should be plenty to handle normal usage with a few background services). Also, keep in mind that the 3.1 only received P in mid-March. It may take some time for changes from the higher-end handsets to percolate over.

[YoRyan]

Okay, I ran logcat until Syncthing got force-closed. I believe these are the relevant lines...

04-15 15:54:33.177  2132  2169 D DuraSpeed/PolicyImpl:   com.github.catfriend1.syncthingandroid, appType: 0x0001, adj: 200, memory: 73.1MB, launchCount: 11
04-15 15:54:49.198  2132  2169 D DuraSpeed/PolicyImpl:   com.github.catfriend1.syncthingandroid, appType: 0x0001, adj: 200, memory: 73.1MB, launchCount: 11
04-15 15:55:30.221  2132  2169 D DuraSpeed/PolicyImpl:   com.github.catfriend1.syncthingandroid, appType: 0x0001, adj: 200, memory: 73.1MB, launchCount: 11
04-15 15:55:31.439  2132  2169 D DuraSpeed/a: suppressPackages, packageList = [com.github.catfriend1.syncthingandroid, com.wunderground.android.weather, com.reddit.frontpage], userId = 0
04-15 15:55:31.471  2132  2169 I ActivityManager: Force stopping com.github.catfriend1.syncthingandroid appid=10006 user=0: from pid 2132
04-15 15:55:31.471  2132  2169 I ActivityManager: Killing 25499:com.github.catfriend1.syncthingandroid/u0a6 (adj 200): stop com.github.catfriend1.syncthingandroid
04-15 15:55:31.473  2132  2169 W ActivityManager: Scheduling restart of crashed service com.github.catfriend1.syncthingandroid/com.nutomic.syncthingandroid.service.SyncthingService in 1000ms
04-15 15:55:31.479  2132  2169 I ActivityManager:   Force finishing activity ActivityRecord{569b6d1 u0 com.github.catfriend1.syncthingandroid/com.nutomic.syncthingandroid.activities.MainActivity t5588}
04-15 15:55:31.490  2132  2169 I ActivityManager:   Force stopping service ServiceRecord{e2f1735 u0 com.github.catfriend1.syncthingandroid/com.nutomic.syncthingandroid.service.SyncthingService}
04-15 15:55:31.495  2365  2365 D NotificationListener: onNotificationRemoved: StatusBarNotification(pkg=com.github.catfriend1.syncthingandroid user=UserHandle{0} id=1 tag=null key=0|com.github.catfriend1.syncthingandroid|1|null|10006: Notification(channel=01_syncthing_persistent pri=-2 contentView=null vibrate=null sound=null smartAlertCount=0x0 defaults=0x0 flags=0x6a color=0x00000000 vis=PRIVATE))
04-15 15:55:31.531   415   415 I BufferQueueConsumer: [f5bb217 com.github.catfriend1.syncthingandroid/com.nutomic.syncthingandroid.activities.MainActivity#0](this:0x700afe6800,id:7965,api:0,p:-1,c:-1) disconnect(C)
04-15 15:55:31.533   415   457 W SurfaceFlinger: Attempting to destroy on removed layer: AppWindowToken{673cc37 token=Token{a5cb536 ActivityRecord{569b6d1 u0 com.github.catfriend1.syncthingandroid/com.nutomic.syncthingandroid.activities.MainActivity t5588}}}#0
04-15 15:55:31.549   415   415 I BufferQueueConsumer: [AppWindowToken{673cc37 token=Token{a5cb536 ActivityRecord{569b6d1 u0 com.github.catfriend1.syncthingandroid/com.nutomic.syncthingandroid.activities.MainActivity t5588}}}#0](this:0x700fed9000,id:7960,api:0,p:-1,c:-1) disconnect(C)
04-15 15:55:31.554  2365  2365 D StatusBar: removeNotification key=0|com.github.catfriend1.syncthingandroid|1|null|10006 old=StatusBarNotification(pkg=com.github.catfriend1.syncthingandroid user=UserHandle{0} id=1 tag=null key=0|com.github.catfriend1.syncthingandroid|1|null|10006: Notification(channel=01_syncthing_persistent pri=-2 contentView=null vibrate=null sound=null smartAlertCount=0x0 defaults=0x0 flags=0x6a color=0x00000000 vis=PRIVATE))
04-15 15:55:31.776  2132  2169 D DuraSpeed/PolicyImpl:   Release com.github.catfriend1.syncthingandroid, type: suppress, PSS: 73.1MB

PID 2132 appears to be a system service.

USER           PID  PPID     VSZ    RSS WCHAN            ADDR S NAME                       
system        2132  1846 5204064 176508 SyS_epoll+          0 S system_server

cc @Catfriend1

[YoRyan]

Happy to report I have a fully functioning workaround!

The DuraSpeed lines prompted me to decompile HMD's odex files, and sure enough, it appears they've included Mediatek's "DuraSpeed" task killer as a system service. Since DuraSpeed is not packaged as an app, it cannot simply be uninstalled, but it does have a secret settings switch that will enable or disable the service.

The flag is not exposed in the Settings app; it can only be manipulated through adb.

adb shell settings put global setting.duraspeed.enabled 0

Toggling it will produce immediate logcat feedback.

04-15 21:13:57.544  1063  1089 D DuraSpeed/DuraSpeedService: onChange, checked: false

My background apps and notifications are now running without any restrictions. In fact, I performed a factory reset and enabled all of HMD's evenwell apps (including com.evenwell.powersaving.g3), and my background apps are still working. Thus, on my phone, DuraSpeed is the one-and-only task killer.

HMD's phones are a doozy. There are now confirmed reports of three different app killing mechanisms:

• com.evenwell.emm on Android Go (Oreo?) for Nokia 1
• com.evenwell.powersaving.g3 on Android Pie for most other Nokia phones
• DuraSpeed on Android Pie (build 00WW_3_180) for the US Nokia 3.1 (TA-1049)

[Artaud]

Oh my. This surely needs a presence on the Nokia entry, I'm adding the information there. Big up for your endeavor!!!

[YoRyan]

Sure thing, right here. At the rate things are going with Nokia, it looks like Don't Kill My App will have to start collecting this information, too.

ES2_sprout:/ $ getprop | grep ro\.product                                                                              
[ro.product.board]: [fih_mt6750_64]
[ro.product.brand]: [Nokia]
[ro.product.cpu.abi]: [arm64-v8a]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.product.device]: [ES2_sprout]
[ro.product.first_api_level]: [26]
[ro.product.locale]: [en-GB]
[ro.product.manufacturer]: [HMD Global]
[ro.product.model]: [Nokia 3.1]
[ro.product.model.display]: [TA-1049]
[ro.product.model.num]: [00WW]
[ro.product.name]: [Essential2_00WW]
[ro.product.nickname]: [Nokia 3.1]
[ro.product.vendor.brand]: [Nokia]
[ro.product.vendor.device]: [ES2_sprout]
[ro.product.vendor.manufacturer]: [HMD Global]
[ro.product.vendor.model]: [Nokia 3.1]
[ro.product.vendor.name]: [Essential2_00WW]

[Artaud]

Closing issue with commit c98492c, if you don't mind. Thanks a lot!

[jagotu]

This works for me on Nokia 5.1, which has similar logcats about DuraSpeed killing apps. However, the setting doesn't persist during reboot. Does it for you, @YoRyan?

[YoRyan]

@jagotu Yes, it persists on my device. The settings syntax has a "default" flag, perhaps try that?

  put [--user <USER_ID> | current] NAMESPACE KEY VALUE [TAG] [default]
      Change the contents of KEY to VALUE.
      TAG to associate with the setting.
      {default} to set as the default, case-insensitive only for global/secure namespace

adb shell settings put global setting.duraspeed.enabled 0 default

Also, what happens when you run adb shell settings get global setting.duraspeed.enabled on boot? Is the flag initialized to 1? On my 3.1, it's not initialized, so I would get null.

[jagotu]

@YoRyan
adb shell settings get global setting.duraspeed.enabled after boot returns 0. To me it seems as if the duraspeed didn't read the flag at start, only registered a change reciever.

Setting the value to 1 and then 0 properly kills DuraSpeed and it doesn't log any more messages.

What does getprop persist.vendor.duraspeed.app.on return for you? For me it's 1. I noticed that this value is also somehow used by the service (by deodexing).

The source kinda supports this theory, listing all references to 'bk' here:

public class DuraSpeedService [...] {

private static final String bk = "setting.duraspeed.enabled";

public void onChange(boolean z, Uri uri) {
[...]
if (Global.getInt(DuraSpeedService.this.mContext.getContentResolver(), DuraSpeedService.bk, 0) == 1) {
[...]
}

public void onSystemReady() {
[...]
this.mContext.getContentResolver().registerContentObserver(Global.getUriFor(bk), false, new a(this.bp));
[...]
}

public void onUserSwitched(int i) {
[...]
if (System.getIntForUser(this.mContext.getContentResolver(), bk, bl, i) != 1) {
[...]
}

So yeah, only checked applied when changed or userswitched. Makes me sad.

The only solution I can think of is writing a simple app that resets it (and granting it WRITE_SECURE_SETTINGS through adb), so that you can cycle it without a computer.

[YoRyan]

Shrug. For me, DuraSpeed definitely stays dead after rebooting. And getprop persist.vendor.duraspeed.app.on returns 1, too.

My classfile (attached) has the same three references as yours. Maybe my 3.1 is calling onUserSwitched on boot?

[YoRyan]

Okay, I was mistaken - I'm actually seeing the same symptoms as @jagotu. DuraSpeed is still active on boot because it only listens for changes to the "enabled" flag. I didn't notice because it hadn't yet flagged any of my apps to kill after the factory reset.

[YoRyan]

My fix is to create a Tasker task that runs on bootup and toggles the flag. This actually introduces a potential catch-22... you'd better hope DuraSpeed doesn't kill the app responsible for disabling DuraSpeed!

So not only do you need to be familiar with adb, you also need to use an automation app to keep the setting persistent. Disgusting.