Nokia: DuraSpeed app killing system service #57

YoRyan · 2019-04-15T04:49:22Z

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.

The text was updated successfully, but these errors were encountered:

Artaud · 2019-04-15T10:41:05Z

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 · 2019-04-15T18:32:30Z

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 · 2019-04-15T23:11:54Z

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

Catfriend1 · 2019-04-15T23:28:02Z

I wish I could help you on this but obviously it's system stuff. If the service is killed it usually gets restarted by android itself (except when force closing was the reason for the kill). Your log shows this behavior, but then its force finished again and I guess it stays off after that line. Does Nokia publish any forms of Source Code or maybe pro's from XDA can offer some help here and analyse the ROMs framework?! I don't know where to look at, sorry. Syncthing-Fork, since 1.1.0.6+ can also use the job scheduler, but I expect this doesn't make a change to Android's kill behavior. If you'd like to try anyway, you'll find the "sync hourly" option under the run conditions. Would be at least interesting for me to know if that also gets killed.

YoRyan · 2019-04-16T05:53:32Z

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 · 2019-04-16T06:29:51Z

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

Catfriend1 · 2019-04-16T06:31:04Z

That's great news for the Syncthing'ers. :-)
Could you please do me a favour and get build.model and build.manufacturer strings for me from the phones where your fix is needed? I would love to add this to the tipsand tricks shown in the app for specific models.

YoRyan · 2019-04-16T07:05:11Z

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]

Catfriend1 · 2019-04-16T07:17:24Z

Thanks, that's exactly what I needed.

Artaud · 2019-04-16T08:51:40Z

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

jagotu · 2019-04-16T20:54:43Z

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 · 2019-04-16T21:19:03Z

@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 · 2019-04-16T22:04:57Z

@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 · 2019-04-17T00:21:43Z

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 · 2019-04-17T05:52:26Z

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 · 2019-04-17T06:23:46Z

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.

Catfriend1 · 2019-04-17T07:13:58Z

What's the command you're using in Tasker? Does it need root?

jagotu · 2019-04-17T08:08:12Z

@YoRyan i noticed any non-one value works to disable it too, so you can switch it from 0 to 2 and back, disabling it with the first change already. Still a huge hack, but can't think of anything better.

YoRyan · 2019-04-17T09:03:32Z

@jagotu Deleting the key would theoretically do this too, but AFAICT Tasker can't do that.

@Catfriend1 The "Custom Setting" command. Root not required (if we had it, we would nuke DuraSpeed!), but you do need to use adb to grant Tasker the WRITE_SECURE_SETTINGS permission.

adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS

YoRyan · 2019-04-18T20:03:42Z

@Artaud We should update the text of Nokia page to incorporate the automation app problem. I suggest this text.

On Android Pie builds for some Nokia models, including the Nokia 3.1 and Nokia 5.1, HMD Global inserted "DuraSpeed," a system service developed by MediaTek that terminates apps that run in the background. Unfortunately, HMD did not include any sort of Settings switch to control this task killer. DuraSpeed does listen for a hidden settings flag, setting.duraspeed.enabled, and will stop itself when the flag is set to any value that does not equal 1. However, this flag has to be cycled at every boot using an automation app like Tasker.

To suppress DuraSpeed with Tasker, first grant Tasker (or your choice of app) the ability to write to the settings store. This requires adb.

adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS

Then create a task that performs the following:

Custom Setting: type Global, name setting.duraspeed.enabled, value 2
Custom Setting: type Global, name setting.duraspeed.enabled, value 0

Run this task to disable DuraSpeed immediately (and to ensure that it runs without error), and then set it to run at device startup.

(markdown)

kyrasantae · 2019-04-19T10:46:56Z

I had been tearing my hair out over missing most of my IM notifications (on 5.1) and this is at last a solution that works. I'm automating it with Macrodroid (since it's free). Thank you!

foreteller22 · 2019-04-24T09:41:23Z

I had been tearing my hair out over missing most of my IM notifications (on 5.1) and this is at last a solution that works. I'm automating it with Macrodroid (since it's free). Thank you!

Could you please write here or PM method how to create this task in Macrodroid ?
Thank you in advance

kyrasantae · 2019-04-24T09:53:06Z

I had been tearing my hair out over missing most of my IM notifications (on 5.1) and this is at last a solution that works. I'm automating it with Macrodroid (since it's free). Thank you!

Could you please write here or PM method how to create this task in Macrodroid ?
Thank you in advance

Follow these instructions to enable the "write secure settings" permission (It's the only one you need for this task): https://www.tapatalk.com/groups/macrodroid/granting-write_secure_settings-permission-via-adb-t2923.html
Create the task like this (I put a notification at the end so that I can see that it has been run)

foreteller22 · 2019-04-24T10:47:57Z

Thank you very much

Frauschlau · 2019-09-07T21:28:16Z

Done all of this, checked with adb to make sure duraspeed is disabled, and still whatsapp, IFTTT, and a few others are killed.

I disabled the three evenwell packages that have been mentioned here, I disabled adaptive battery, I disabled battery optimization for whatsapp and IFTTT.

Still no luck.

Any ideas?

Also, is there a quick way (perhaps via adb) to disable all evenwell packages? Or does it have to be done one by one?

kyrasantae · 2019-09-07T22:22:53Z

Are you toggling the setting.duraspeed.enabled value to something and then to a value that is not 1? It's the change in value that disables duraspeed.

Frauschlau · 2019-09-07T22:33:13Z

Absolutely - using Macrodroid to switch to 2 (also tried -1 and 1) then back to zero at boot. I then ran the adb command I found in the comments somewhere to confirm duraspeed is disabled.

YoRyan · 2019-09-07T22:49:37Z

I would keep a logcat running and see if any messages appear when an app dies.

Frauschlau · 2019-09-08T11:25:39Z

@YoRyan - I am not a developer, so needed a bit of time to learn about logcat. I finally figured it out: I installed a Logcat app, gave it appropriate permissions via adb, figured out how to export entries, turned it loose on the Nokia, opened IFTTT & Whatsapp, then "swiped them up". Will report back in a few hours with the logs.

Thank you for your support!

Frauschlau · 2019-09-08T21:19:50Z

I would keep a logcat running and see if any messages appear when an app dies.

@YoRyan - I hope I did this right. I ran a search for "WhatsApp" and saved the results to the attached .txt file. Then repeated the exercise for "IFTTT".

WhatsApp needed over an hour to show a notification for an incoming message. The IFTTT time-based trigger shows in the IFTTT interface as executed at 6:45 p.m., but the pop-up notification never showed up on the phone screen.

Please have a look. I would greatly appreciate your help in interpreting the results.

WhatsApp logcat_09-08-2019_23-06-25.txt

IFTTT - logcat_09-08-2019_23-04-31.txt

YoRyan · 2019-09-08T23:52:11Z

Nice work! Unfortunately, I don't see any evidence of Duraspeed activity, so it's a real mystery what's killing your apps. Those messages would look like this:

    public String onReadyToStartComponent(String str, int i, String str2) {
        if (i == 1000 || i == 1001) {
            return "allowed";
        }
        int X = dt.X();
        if (X == 0) {
            return "allowed";
        }
        String str3 = "allowed";
        if (((dp.equals(str2) && (X & 32) != 0) || ((dq.equals(str2) && (X & 512) != 0) || (dr.equals(str2) && (X & 1024) != 0))) && dt.a(str, i)) {
            str3 = "skipped";
        }
        StringBuilder sb = new StringBuilder();
        sb.append("onReadyToStartComponent, packageName = ");
        sb.append(str);
        sb.append(", uid = ");
        sb.append(i);
        sb.append(", suppressReason = ");
        sb.append(str2);
        sb.append(", suppressPolicy = ");
        sb.append(Integer.toHexString(dt.X()));
        sb.append(", suppressMode = ");
        sb.append(str3);
        b.a(this, false, sb.toString());
        return str3;
    }

What Android security patch are you on?

Frauschlau · 2019-09-09T09:05:18Z

@YoRyan - thank you so much for taking the time to look, greatly appreciated!

The security patch is dated August 5, 2019.

A total guess here: I have enabled some accessibility options - mainly the increased font size, plus I have the accessibility shortcut icon in to the right of the three navigation keys (back, home, recent apps, then there is the accessibility icon to the right). Anything there that could be killing apps, thinking that someone who needs accessibility does not need anything other than the phone and texts to work?

Another guess: I have a brightness settings app. Could that be blocking anything? I installed it for - of course - ease of use, but will revert to using the brightness up/down buttons in the accessibility menu. I tried automatic brightness, but - at a certain, low level of brightness - the screen starts "flickering": apparently, it is a known bug.

I am going to do a factory reset later today. Then go with Macrodroid. Not sure what else to try.

Just to make sure: do the three evenwell packages have to be disabled via ADB or via user interface in the phone? Or does it not matter because Duraspeed is the culprit?

Thank you again for your time and help.

YoRyan · 2019-09-09T17:01:45Z

As far as I can tell - at least for the United States rom, also August patch - Duraspeed is the sole app killer. My 3.1 behaves perfectly with all of the Evenwell apps enabled.

It's possible you're maxing out the 2 GB of RAM by running those background services, in which case Android's builtin memory management would take over. But, to be honest, a factory reset is probably your best bet. Be sure to install Macrodroid and set up the Duraspeed fix right away, and hopefully you will be in good shape.

Which country are you in? I understand Nokia implemented different power-saving policies for Western and non-Western markets.

Frauschlau · 2019-09-09T17:51:32Z

As far as I can tell - at least for the United States rom, also August patch - Duraspeed is the sole app killer. My 3.1 behaves perfectly with all of the Evenwell apps enabled.

It's possible you're maxing out the 2 GB of RAM by running those background services, in which case Android's builtin memory management would take over. But, to be honest, a factory reset is probably your best bet. Be sure to install Macrodroid and set up the Duraspeed fix right away, and hopefully you will be in good shape.

Which country are you in? I understand Nokia implemented different power-saving policies for Western and non-Western markets.

Thank you for the detailed response.

It is a 2GB RAM phone - being used in Europe.

Did the factory reset, got a different version of Android, I think: the back/home/recent apps buttons are not there any more, just one rectangular one that has to be swiped up to reveal the recent apps.

Started by reinstalling Macrodroid and giving it the two permissions

adb shell pm grant com.arlosoft.macrodroid android.permission.WRITE_SECURE_SETTINGS
adb shell pm grant com.arlosoft.macrodroid android.permission.CHANGE_CONFIGURATION

per kyrasantae's instructions accompanying the screenshots of the Macrodroid setup. THEN added the few other apps. Interestingly enough, many of them kept crashing during the new setup, including Google's own apps - had to reboot a few times.

Ran adb shell settings get global setting.duraspeed.enabled - got "0".

I also checked the Evenwell apps - although DKMA site claims HMD stopped auto-enabling these as of August, I am not sure how/where that applies as I found the same long list of Evenwell apps, all of them enabled. I did disable the ones listed in the many discussion forums, but can easily re-enable, of course (I am trying to learn everything as fast as I can).

Re: RAM usage - under developer options, I found the claim that the average RAM usage has been 1.3GB out of the available 1.9GB. To be honest, I have a "collection" of older phones (I am too cheap to upgrade frequently), including Nexus 4 and 5, and those work better (albeit slower) than the Nokia...

Anyway, let's see what happens. I really appreciate your help!

Frauschlau · 2019-09-10T09:15:26Z

No luck. I am absolutely baffled, I must say: a message sent to WhatsApp is yet to pop up. It does not seem enough for the phone to be awake - not even an incoming text and a phone call forced WhatsApp to wake up.

I expect IFTTT is dead, too.

Macrodroid works.

Well, so much for a smartphone - looks like I ended up with what someone at one of the forums referred to as "dumbphone": calls & texts only.

Not sure what else to try - I may end up buying something else.

Anyway, if you can think of anything else - please share. And - again - thank you so much for your help, really appreciate it!

mll0 · 2019-09-23T19:24:07Z

No luck. I am absolutely baffled, I must say: a message sent to WhatsApp is yet to pop up. It does not seem enough for the phone to be awake - not even an incoming text and a phone call forced WhatsApp to wake up.

I expect IFTTT is dead, too.

Macrodroid works.

Well, so much for a smartphone - looks like I ended up with what someone at one of the forums referred to as "dumbphone": calls & texts only.

Not sure what else to try - I may end up buying something else.

Anyway, if you can think of anything else - please share. And - again - thank you so much for your help, really appreciate it!

If that's any comfort, I'm in the same case (IM apps notifications not coming up), and in Europe, too.

YoRyan · 2019-09-23T22:03:49Z

Okay, so that's another data point for Europe. Are we seeing a pattern here?

mll0 · 2019-09-24T14:19:06Z

Just a precision : https://dontkillmyapp.com/nokia seems to imply that the 3.1 Plus is not concerned by Duraspeed. However I tried the Duraspeed disabling commands this morning. Seems to be better. I'll keep you informed if this confirms in the coming days.

BTW: this page says that the web page description misses one step.

Frauschlau · 2020-02-14T21:40:22Z

A quick update: I bought a Google Pixel with Android 10. I checked DontKillMyApp, I noticed it mentions that there are no problems and I "just" need to disable battery optimization for the apps whose notifications I want to see in real time. That, however, does not work - I still get the same issues on the Google phone as I do on the Nokia 5.1: notifications for everything but texts stop arriving within minutes of the screen going blank.

The solution that works on both the Nokia and the Pixel phones: run adb shell dumpsys deviceidle disable after every boot - this disables the doze functionality that seems to trump everything. All notifications are now in real time, on both phones. I just wish there were a way to automate this, so I did not have to plug the phone into a PC every time I reboot it.

Allegedly, disabling doze permanently used to be available in developer option menus, but I do not see it in Android 7, 9, or 10.

If anyone knows a better way, if I am missing something, if the above command can be automated without the need to root the phone - please, by all means, share.

YoRyan · 2020-02-15T01:30:28Z

In response to the above, in addition to @Frauschlau's comment here:

Batching up notifications for several minutes at a time is normal. This is how Google intended Android and Doze to work together to save power, as indicated by the behavior of the ROM on your Pixel, which is the closest thing we have to a "reference version" of Android. We're concerned about the customizations that manufacturers stack on top of what Google already provides, like DuraSpeed, which break the behavior of even properly programmed apps.

Unfortunately, I'm not aware of any way to permanently disable Doze without root.

Frauschlau · 2020-02-15T16:09:31Z

Hi @YoRyan ,

Thank you so much for taking the time to reply and provide all these details - greatly appreciated.

I automated DuraSpeed with Macrodroid - thank you again for the detailed guide. It is the doze functionality that stops the real-time notifications.

So, if I want to get notifications from my security cameras (either directly from their app or via IFTTT) in real time, I gather I have these 3 choices:

keep the Pixel plugged in,
hold on to the Nexus 4 / Android 5 (all notifications arrive in real time, no issues there), or -
run the adb command from a PC every time I reboot the Pixel.

Otherwise, by design, all notifications - except for calls/texts - arrive with totally random delay (which makes especially those from the security cameras quite useless).

And there is no way to automate the doze disablement on a non-rooted device.

Did I get all of this right?

Thank you again for your help - I really appreciate it.

YoRyan · 2020-02-15T18:43:22Z

Yep, you got it. You should also try disabling adaptive battery if you haven't done so already.

I'm sorry there's no way to change this behavior; I understand how frustrating it can be. That's why I took the fight to DuraSpeed, after all.

Frauschlau · 2020-02-15T20:52:56Z

Adaptive battery was, indeed, the first thing I disabled. I also followed the misleading (at least in my opinion) instructions to disable battery optimizations for the apps in question in order to exclude them from doze. Seems that doze overrides everything...

Would you, by any chance, know whether the same happens with iPhones? I am not a fan (of remortgaging my house), but perhaps this is the way to go.

Thank you again for providing the insight.

YoRyan · 2020-02-15T22:26:54Z

No personal experience, but I would guess that modern iOS exhibits similar behavior. Both Apple and Google have poured substantial resources into increasing battery life.

If you deliver your notifications via IFTTT, isn't there a way to select a higher-priority channel?

Frauschlau · 2020-02-16T17:58:46Z

OK, so - I can keep the house, no need to trade it in for an iPhone.

Not sure how I would select a higher-priority channel. If you mean setting notifications to "priority" (rather than standard/normal) - I have not found that setting, so I wonder if Android 10 no longer offers that. With IFTTT, I cannot even get the VoIP calls to ring on the Pixel. Best-case scenario - I get a pop-up, but no sound. And even that with whatever delay Android decides upon.

So, for now, it is one of the three options for me. Maybe Android 11 will have something new/different. Or I find a way to automate doze disablement the same way I automated DuraSpeed with your help.

mll0 · 2020-05-19T10:04:31Z

Hi, I fortuitously relanded on the present page while looking for a solution.
My Nokia 3.5 Plus (TA-1105) was sent for a repair (the infamous usb charging port defect). Of course I did a factory reset before.
When it came back, I quickly went for disabling the infamous evenwell task killers using the script at https://forum.xda-developers.com/nokia-6-1-plus/how-to/root-nokia-debloater-t4005895. I also had to disable new ones, see my comment on the same XDA thread.
I could confirm that as of today (with the April 5 2020 system update) it's still not enough and that many apps still don't show up notifications because they were killed.
Tonight I let logcat run, and even though there is no mention at all of the string Duraspeed, there is still that service called ActivityManager that enjoys killing background apps:

05-18 23:05:28.869  1076  1110 I ActivityManager: Force stopping org.mozilla.fenix appid=10183 user=0: from pid 1076
05-19 00:30:10.716  1076  1110 I ActivityManager: Force stopping com.sand.airdroid appid=10195 user=0: from pid 1076
05-19 00:30:10.748  1076  1110 I ActivityManager:   Force stopping service ServiceRecord{25ffa1 u0 com.sand.airdroid/.services.AirDroidKeepLiveService}
05-19 00:30:10.748  1076  1110 I ActivityManager:   Force stopping service ServiceRecord{7f604df u0 com.sand.airdroid/.services.TransferReceiveService}
05-19 00:30:10.748  1076  1110 I ActivityManager:   Force stopping service ServiceRecord{d474451 u0 com.sand.airdroid/.servers.push.PushKeepLiveService}
05-19 00:30:10.748  1076  1110 I ActivityManager:   Force stopping service ServiceRecord{7c0d1fe u0 com.sand.airdroid/.services.NotificationService}
05-19 00:30:10.751  1076  1110 I ActivityManager: Force stopping com.whatsapp appid=10186 user=0: from pid 1076
05-19 00:30:10.763  1076  1110 I ActivityManager:   Force stopping service ServiceRecord{7bbdf51 u0 com.whatsapp/.messaging.MessageService}
05-19 03:45:11.885  1076  1099 I ActivityManager: Force stopping com.discord appid=10277 user=-1: installPackageLI
05-19 03:45:17.144  1076  1115 I ActivityManager: Force stopping com.discord appid=10277 user=0: pkg removed
05-19 03:45:17.157  1076  1115 I ActivityManager: Force stopping com.discord appid=10277 user=0: pkg removed
05-19 03:46:01.920  1076  1099 I ActivityManager: Force stopping com.google.android.ims appid=10091 user=-1: installPackageLI
05-19 03:46:01.928  1076  1099 I ActivityManager:   Force stopping service ServiceRecord{613ed7f u0 com.google.android.ims/.services.RcsService}
05-19 03:46:01.928  1076  1099 I ActivityManager:   Force stopping service ServiceRecord{29eea06 u0 com.google.android.ims/.services.CarrierServicesImsService}
05-19 03:46:04.909  1076  1115 I ActivityManager: Force stopping com.google.android.ims appid=10091 user=0: pkg removed

I just went for the setting.duraspeed.enabled trick. Seems to work so far since I never got so many LinkedIn notifications. :)

Sheesh... So much time lost on stuff that should not even exist. Really looking forward to being able to install LineageOS on this device...

…10755) # Why 1. Notification response handling doesn't work after recent changes as per #10708 (review). 2. Simplify implementation. 3. Single-threaded notifications handling # How Instead of relying on `NotificationResponseReceiver` which uses `NotificationsHelper` to dispatch events to `NotificationsService` we can handle them in `NotificationsService` in the first place. Basically I: - removed `*NotificationResponseReceiver` by using _action intent_ created by new companion object method in `NotificationsService` - changed `RECEIVE_RESPONSE` event from `(notificationResponse: NotificationResponse, opensAppToForegound: Boolean)` to `(action: NotificationAction, notification: Notification)`. This lets us create notification responses when we actually have them (previously we created text response, put it into the intent and after receiving text we modified the original response object). This also makes it easier to extend `NotificationAction` API by not adding more simple flags to intent data and depending on the actual action object itself. - moved opening app to foreground to service's handling delegate which makes it overridable - removed need for `CATEGORY_DEFAULT` from activities wanting to handle `expo.modules.notifications.OPEN_APP_ACTION` — previously we used `intent.resolveActivity` which adds `PackageManager.MATCH_DEFAULT_ONLY` flag to search, now we use `packageManager` without flags less important: - added information about `opensAppToForeground` defaulting to `true` - added `${Constants.manifest.id}:welcome` category creation to NCL for the test push notification to test the category # Test Plan Verified that tapping the notification and different actions is handled properly by the experience. I've spent much time debugging why notifications aren't properly scheduled when the device boots only to find out Nokia device I was using to test [has some DuraSpeed system](urbandroid-team/dont-kill-my-app#57) that force stops all apps at boot and forbids them receive scheduled broadcasts. On emulator everything works perfect.

Catfriend1 mentioned this issue Apr 16, 2019

Disable DuraSpeed on HMD Global phones Catfriend1/syncthing-android#404

Closed

Artaud added a commit that referenced this issue Apr 16, 2019

Add info from #57

c98492c

Artaud closed this as completed Apr 16, 2019

YoRyan changed the title ~~Nokia: Unknown app killer on P for the Nokia 3.1~~ Nokia: DuraSpeed app killing system service Apr 17, 2019

kyrasantae mentioned this issue Apr 24, 2019

Nokia 5.1 #60

Closed

gerhardol mentioned this issue May 8, 2019

Not recording since new android upgrade to pie jonasoreland/runnerup#760

Closed

degenkolb mentioned this issue Sep 5, 2019

Change user-defined system secure setting (on boot) renyuneyun/Easer#266

Open

YoRyan mentioned this issue Dec 30, 2019

Nokia: Add more information about disabling DuraSpeed #144

Merged

RaydenX93 mentioned this issue Aug 26, 2020

[Umidigi A7 Pro] Can't disable DuraSpeed #228

Closed

This was referenced Oct 21, 2020

[expo-notifications] Move notification response handling to delegate expo/expo#10755

Merged

expo-notifications scheduleNotification is not working as expected in devices expo/expo#10700

Closed

nonlin-lin-chaos-order-etc-etal mentioned this issue Oct 3, 2022

use the non-gui daemon as an external OS process PurpleI2P/i2pd-android#40

Closed

qumuq-til mentioned this issue Feb 13, 2024

Force stopping Phone in the Apps panel disables handling of incoming calls FossifyOrg/Phone#111

Closed

7 tasks

Nokia: DuraSpeed app killing system service #57

Nokia: DuraSpeed app killing system service #57

Comments

YoRyan commented Apr 15, 2019

Artaud commented Apr 15, 2019

YoRyan commented Apr 15, 2019

YoRyan commented Apr 15, 2019 • edited Loading

Catfriend1 commented Apr 15, 2019

YoRyan commented Apr 16, 2019

Artaud commented Apr 16, 2019

Catfriend1 commented Apr 16, 2019

YoRyan commented Apr 16, 2019

Catfriend1 commented Apr 16, 2019

Artaud commented Apr 16, 2019

jagotu commented Apr 16, 2019

YoRyan commented Apr 16, 2019

jagotu commented Apr 16, 2019 • edited Loading

YoRyan commented Apr 17, 2019

YoRyan commented Apr 17, 2019 • edited Loading

YoRyan commented Apr 17, 2019

Catfriend1 commented Apr 17, 2019

jagotu commented Apr 17, 2019

YoRyan commented Apr 17, 2019 • edited Loading

YoRyan commented Apr 18, 2019 • edited Loading

kyrasantae commented Apr 19, 2019

foreteller22 commented Apr 24, 2019

kyrasantae commented Apr 24, 2019 • edited Loading

foreteller22 commented Apr 24, 2019

Frauschlau commented Sep 7, 2019

kyrasantae commented Sep 7, 2019 • edited Loading

Frauschlau commented Sep 7, 2019

YoRyan commented Sep 7, 2019

Frauschlau commented Sep 8, 2019 • edited Loading

Frauschlau commented Sep 8, 2019

YoRyan commented Sep 8, 2019 • edited Loading

Frauschlau commented Sep 9, 2019 • edited Loading

YoRyan commented Sep 9, 2019

Frauschlau commented Sep 9, 2019 • edited Loading

Frauschlau commented Sep 10, 2019

mll0 commented Sep 23, 2019

YoRyan commented Sep 23, 2019

mll0 commented Sep 24, 2019

Frauschlau commented Feb 14, 2020

YoRyan commented Feb 15, 2020 • edited Loading

Frauschlau commented Feb 15, 2020

YoRyan commented Feb 15, 2020

Frauschlau commented Feb 15, 2020

YoRyan commented Feb 15, 2020

Frauschlau commented Feb 16, 2020

mll0 commented May 19, 2020 • edited Loading

YoRyan commented Apr 15, 2019 •

edited

Loading

jagotu commented Apr 16, 2019 •

edited

Loading

YoRyan commented Apr 17, 2019 •

edited

Loading

YoRyan commented Apr 17, 2019 •

edited

Loading

YoRyan commented Apr 18, 2019 •

edited

Loading

kyrasantae commented Apr 24, 2019 •

edited

Loading

kyrasantae commented Sep 7, 2019 •

edited

Loading

Frauschlau commented Sep 8, 2019 •

edited

Loading

YoRyan commented Sep 8, 2019 •

edited

Loading

Frauschlau commented Sep 9, 2019 •

edited

Loading

Frauschlau commented Sep 9, 2019 •

edited

Loading

YoRyan commented Feb 15, 2020 •

edited

Loading

mll0 commented May 19, 2020 •

edited

Loading