[Nook Touch General] Exameden:
Hi,

thanks to a short discussion with Renate and inspiration coming from her comments, I found something new that potentially can allow utilizing Deep Sleep (Doze) more on glowlight 4 third party apps and probably other ntx/android devices. You will see later why it probably has something to do not only with nooks.

So, Deep Sleep (DS) mode is a godsend for eInk devices, because the screen keeps the last image, everything else almost completly can be switched off. The minimum consumption while the information is still there on the screen. Basically the locked state of the device is this mode in all its beauty. What I found puzzling at first is that it looked like no apps really used this mode. Until with a little help of the mentioned discussion and BetterBatteryStats I found that the bn.ereader app actually goes to sleep between page flips. It wasn't stable, but the numbers spoke with curtainty.

The next step was to discover in logcat that when the DS is successfull, it goes with two coupled messsages

setDirectSuspend: true

setDirectSuspend: false

The logcat messages were from the bn.ereader package user so it was the reader hinting at some actions related. Between them the messages were obviously related to power-saving and going to sleep but came from 1000 user, so some unknown system app or service. The whole sequence looked like some messaging between processes.

After disassembling bn.ereader (thanks to ApkStudio) it looked like communication was with interface com.nook.lib.epdcommon.IStatusBarService using some well known IPC tecnique (writeInterfaceToken, transact are usual keywords here, but when googling they're not very well documented).

Further when searching in all apk as zip archives for the string "IStatusBarService", the partner app (com.nook.partner) was one of the three found. After disassembling it, there was found the implementation of this IStatusBarService (StatusBarService.java). And there in all its beauty the method setDirectSuspend.

The method looked a little complicated relating to saving and restoring the network state and some pending (I finally saw why bn.ereader never went to sleep right after new key press, but only after several seconds), but what it did was setting the global setting power_enhance_enable to 1 or 0 depending of the request.

Settings.System.putInt(StatusBarService.this.getContentResolver(), "power_enhance_enable", z ? 1 : 0);

The corresponding action is bascially the equivalent of the shell command

(if used from the host computer)

or

in the device shell (for example in termux)

Also for checking the current value

Great, but don't rush to set this settings on your Nook, the story still goes on :)

What I found interesting is that my lazy googling for this setting (power_enhance_enable), there's only a single instance at the web. This is an extract from the official API of MobiScribe devices (Wave for example). What we're interested is the section "2-Step-Suspend"

That was when I thought that probably the SDK for android/eInk based devices comes from the single supplier, Ntx (under some NDA). The keyword Ntx exists in many bundled apps package ids and and in this sdk file names, so it's easy to find why

and this means that if an eInk device is android-based and introduced after 2015, this setting might be applicable.

So the next tests was with this settings. Initially I thought that it works as a global mode of operations on the device so once it is enabled, the device will try to go in deep sleep as long as some hardware interruption like clicks and presses are finished. Seems like it's not the case. It looks more like a command (making some useful stuff when switched from 0 to 1). My first tests was using adb shell that had its shortcomings when used wired, because I was losing objective power stats because of charging. But at least the setting survived connecting/disonnecting, but didn't survive going to the launncher. With all these glitches adb tests didn't allow collecting consistent information.

So the next test went like this

A sh script was prepared for launching in the termux. Looked like the shell interpreter is a little strange and didn't understand breaks as command separators so the body was with semicolons sleep 10; settings put system power_enhance_enable 1

BetterBatteryStats was reset in Custom settings so after running the script and launching some application I was supposed to find DS time in it.

The tests assumed I run it and instantly went to the launcher then some other app in order for this setting to be set (thanks to the sleep command) after all the intermediate actors finished .

It actually worked. With several apps (including BetterBatteryStats) I found Deep Sleep time in the stats. What made me think that the setting is not a state but a command is that in KoReader one of the tests was to wait 30 seconds and flip pages several times. If this is a mode then the DS sleep time should include the wating and the following flips, but the test showed DS only 30 seconds.

So it looks like the setting can be used for power saving features, but its (probably) command nature makes it a little difficult system-wise. I'm thinking about

some regular script (i.e. ,MacroDroid) switching it to 0 and then back to 1 regularly

a special script that performs this switch only when detecting a subset of nook-specific hardware buttons pressed.

a custom version of open-source apps like KoReader for a specific settings for page flips. Maybe if this setting is confirmed on other devices like MobiScribe Wave then the logic of setting it to on/off between pages might be implemented natively if developers agree.

As for whether it is worth fighting for, I'd say that utilizing this feature will allow going from guessing the work time from a single charge in time (hours, days) to page flips. This used to be the case when early eInk devices were introduced, for example the specification listed 10000 page flips on a single charge. The time will be almost irrelevant (theoretically)

I appreciate any further thought and maybe tests results correcting my assumptions and logic.

Thanks.