Nokia: DuraSpeed app killing system service about dont-kill-my-app HOT 47 CLOSED

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)

from dont-kill-my-app.

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

1. 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

2. Create the task like this (I put a notification at the end so that I can see that it has been run)
   

from dont-kill-my-app.

@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

from dont-kill-my-app.

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.

from dont-kill-my-app.

@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.

from dont-kill-my-app.

@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:

1. Custom Setting: type Global, name setting.duraspeed.enabled, value 2
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)

from dont-kill-my-app.

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!

from dont-kill-my-app.

Thanks, that's exactly what I needed.

from dont-kill-my-app.

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

from dont-kill-my-app.

Dear all

Thank you so much for your help.
On Nokia 3.1 (Pie) I have successfully solved this with MacroDroid as prescribed by kyrasantae.
I also have quoted this in the Kaspersky-Community as several user are suffering the same problem there.

from dont-kill-my-app.

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!

from dont-kill-my-app.

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...

from dont-kill-my-app.

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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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

from dont-kill-my-app.

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.

from dont-kill-my-app.

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

from dont-kill-my-app.

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.

from dont-kill-my-app.

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]

from dont-kill-my-app.

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?

from dont-kill-my-app.

@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.

from dont-kill-my-app.

@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.

from dont-kill-my-app.

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?

from dont-kill-my-app.

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.

from dont-kill-my-app.

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

from dont-kill-my-app.

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

from dont-kill-my-app.

Thank you very much

from dont-kill-my-app.

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?

from dont-kill-my-app.

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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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

from dont-kill-my-app.

@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!

from dont-kill-my-app.

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

from dont-kill-my-app.

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?

from dont-kill-my-app.

@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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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!

from dont-kill-my-app.

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.

from dont-kill-my-app.

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

from dont-kill-my-app.

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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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.

from dont-kill-my-app.

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?

from dont-kill-my-app.

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.

from dont-kill-my-app.