Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nokia: DuraSpeed app killing system service #57

Closed
YoRyan opened this issue Apr 15, 2019 · 46 comments
Closed

Nokia: DuraSpeed app killing system service #57

YoRyan opened this issue Apr 15, 2019 · 46 comments

Comments

@YoRyan
Copy link
Contributor

@YoRyan YoRyan commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Collaborator

@Artaud Artaud commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 15, 2019

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

This comment has been minimized.

Copy link

@Catfriend1 Catfriend1 commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 16, 2019

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

This comment has been minimized.

Copy link
Collaborator

@Artaud Artaud commented Apr 16, 2019

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

@Catfriend1

This comment has been minimized.

Copy link

@Catfriend1 Catfriend1 commented Apr 16, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 16, 2019

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

This comment has been minimized.

Copy link

@Catfriend1 Catfriend1 commented Apr 16, 2019

Thanks, that's exactly what I needed.

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

This comment has been minimized.

Copy link
Collaborator

@Artaud Artaud commented Apr 16, 2019

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

@Artaud Artaud closed this Apr 16, 2019
@jagotu

This comment has been minimized.

Copy link

@jagotu jagotu commented Apr 16, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 16, 2019

@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

This comment has been minimized.

Copy link

@jagotu jagotu commented Apr 16, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 17, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 17, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 17, 2019

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.

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

This comment has been minimized.

Copy link

@Catfriend1 Catfriend1 commented Apr 17, 2019

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

@jagotu

This comment has been minimized.

Copy link

@jagotu jagotu commented Apr 17, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 17, 2019

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

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Apr 18, 2019

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

@kyrasantae

This comment has been minimized.

Copy link

@kyrasantae kyrasantae commented Apr 19, 2019

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

This comment has been minimized.

Copy link

@foreteller22 foreteller22 commented Apr 24, 2019

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

This comment has been minimized.

Copy link

@kyrasantae kyrasantae commented Apr 24, 2019

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)
    Screenshot_20190424-124201

@foreteller22

This comment has been minimized.

Copy link

@foreteller22 foreteller22 commented Apr 24, 2019

Thank you very much

@Mikemyway

This comment has been minimized.

Copy link

@Mikemyway Mikemyway commented Aug 18, 2019

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.

@Frauschlau

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Sep 7, 2019

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

This comment has been minimized.

Copy link

@kyrasantae kyrasantae commented Sep 7, 2019

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Sep 7, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Sep 7, 2019

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

@Frauschlau

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Sep 8, 2019

@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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Sep 8, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Sep 8, 2019

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Sep 9, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Sep 9, 2019

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Sep 9, 2019

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Sep 10, 2019

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

This comment has been minimized.

Copy link

@mll0 mll0 commented Sep 23, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Sep 23, 2019

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

@mll0

This comment has been minimized.

Copy link

@mll0 mll0 commented Sep 24, 2019

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Feb 14, 2020

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Feb 15, 2020

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Feb 15, 2020

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Contributor Author

@YoRyan YoRyan commented Feb 15, 2020

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

This comment has been minimized.

Copy link

@Frauschlau Frauschlau commented Feb 16, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.