Your XA2Ultra has a way lower wakeup count than your X10iii. Even if we subtract the wakeups caused by voicecall-ui-prestart, it is significantly higher than your XA2ultra.
Yeah, I’ve noticed it. But the question is why. Both devices are actually mirrors - same data, same software installed, and the same (i.e. nothing) running while taking the measurement.
Maybe I’ll give it a reboot and try to take the reading once more on the 10 III.
OK, here’s a new one, taken right after reboot and without activating the SIM card (it wasn’t active on the XA2 Ultra, either). Slightly less wakeups, still more than XA2 but I guess comparable.
P.S. @direc85, your 10 III still has much less wakeups. What state was it in? WLAN, cellular radio enabled or disabled? Thank you.
OK, last one, after yet another reboot, everything (WLAN, cellular radio, GPS, Bluetooth, etc) disabled:
Wakeups dropped to 192/s.
Thank you so much! The
mcetool --set-low-power-mode=enabled
command makes such a difference. Wow!
I admire all who try to improve the battery consumption!
Out of curiosity, I’ve just installed White on Black ambience (which I further tweaked to be even more monochromatic). Sadly, there is no noticeable reduction in power consumption because only the main launcher screen is really black (pixels are really turned off). Both the Events screen and backgrounds of all applications are actually grey - it is clearly visible that those grey pixels are active and backlighted. This grey color is caused by the Silica UI automatically applying some kind of effect over the black background, which in this case makes it grey-ish. So, without a deeper modification (removing that effect) it is not possible to get any noticeable power saving by using a black theme.
Nice to hear. I checked with mcetool |grep power
, that after the update to 4.4.0.72 low power mode is still enabled
I’ve created myself a black background image at the resolution of the phone screen, and I also applied a script from x10ii-x10iii-color-banding-in-low-light-conditions which fools the system and gives me true black colour. Still tho many apps, especially the browser, have bright or white colours which does not help much.
In any case power consumption on the screen is not the main issue, the phone keeps consuming lots of power while idling, in my case it’s about 1% per hour if not more.
I think the OLED screen is not used in the way the Nokia N9 did it. It looks like the whole screen is always powered on and not only the pixel which are used and not black.
Regarding the general power consumption, maybe the open source drivers do not contain all the power saving mechanics than the Android ones.
I very much doubt it. Set the screen brightness to maximum and then slowly swipe from the home screen to the Events screen and notice how it switches from real black to gray. Same way, compare the background of the home screen (where the covers of minimized apps are shown) or the lock screen (which are the only screens where the blur effect isn’t applied to the background, so a black background stays really black and on OLED displays causes that pixels are really OFF) with backgrounds of applications which seem to have black background - if you have max brightness set, you will notice that their background is actually nowhere near as black as on the home screen and the pixels are all active and emitting some light.
Only the Lock screen and the home screen show real black color and allow the pixels to really switch off. Everywhere else, the blur effect automatically applied to the background by the Silica UI, causes that the background is no longer black (let’s say its color is no longer rgb #000000 but something like #010101 i,e, very dark grey) which causes that the whole screen remains powered on as only full black (#000000) powers off the pixel. So making SFOS OLED friendly would require disabling that blur effect.
How this blur gets automatically applied is clearly visible when one very slowly swipes between Home and Events screen - on colorful themes you can see how the background gets blurred in between, and on a black theme (if you set display brightness to max in a dark room) you can see how real blackness turns into grayish and pixels start emitting light.
we might get slightly off topic, but there is no colour banding issue with XZ3 (community port) which is using similar screen OLED technology.
This is not connected with the color banding issue of the 10 III display, it is about the blur filter that SFOS applies to all backgrounds of all screens and applications (except for home and lock/LPM screen), whose side effect is that black is no longer entirely black and thus on all screens (but home and lock/LPM screen) pixels remain powered on. In the last paragraph of my previous post I described how to check this.
The following screenshot is a Battery Buddy log from the XA2 Ultra. As you can see, it goes as low as 9 - 10 mA. Compare it with your 10 III… I’d understand a difference of say 50% but 300-500%…?
Wow… its in single digit too… In Xperia 10 III, for me it does not goes below 100, even without using android support, mine average is between 150-200mA
When it sleeps, it manages to go down to 36-50 mA, but it’s still 4 times more than the XA2 Ultra…
confirm, its not only ofono, it always drain much CPU, but when it charging - CPU not use so much resources… strange…
Linking to a possibly related observation in a different thread:
Also, I think I saw this behaviour when chasing the “phone drains battery when in flight mode” problem (this still happens occasionally in 4.4.0.58 on Xperia X).
I can confirm this behavior on my XA2.
Low power mode of mce
isn’t for lowering power consumption, but controlling the behavior of the display when it’s taken out of pocket:
About lower CPU usage while charging: my X10III sets performance
CPU governor, which locks the CPU clocks to max. The little load it has hence appears as lower percentage. I believe you can double check this by setting the governor while the device is not connecter to charger/computer/powerbank by running this:
echo -n performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo -n performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
and checking the graphs then. The default governor is schedutil
(but ondemand
works fine for me, too).
Is there a way to disable charging, so that you can directly measure the current drain in the USB cable?
Another interesting question is if Jolla have an instrumented phone for their testing. (i.e removed the back, put a current meter in the battery leads)
Yeah it’s possible. You can install Battery Buddy. This allows you to observe the current you are using, as well as setting bounds for charging.
That feature is on the list, but I have no ETA for it at the moment. It’s also even more device-dependent feature, and figuring out the support takes a fair amount of trial and error.