Control LineageOS LiveDisplay with Tasker - Tasker Tips & Tricks

Hi,
here some commands to control the LineageOS LiveDisplay with Tasker/shell run.
To change Display Mode:
settings --lineage put system display_temperature_mode x
x = Off=0, Night=1, Auto=2, Outdoor=3, Day=4
To change color temperature:
settings --lineage put system display_temperature_day xxxx
settings --lineage put system display_temperature_night xxxx
xxxx = color temperature, eg 6600 for Day Mode & 4200 for Night Mode.
To change color calibration values, default is 1.0 1.0 1.0 (rgb):
settings --lineage put system display_color_adjustment "0.8991 0.8689 1.0"
I'm using it in conjunction with the great Twighlight Plug-in for Tasker. It gives better control for sunrise/sunset timings/locations and many more!
If you are still using CyanogenMod use --cm as parameter.
If something goes wrong i'm not here anymore!
But please report and include the solution.
Also report if there are more useful commands.
@ktmom
Thanks, but transformed the question to a solution by my self before i saw your hint! :cyclops:

Your link is a patch that is used when building the ROM.
I don't use LineageOS but maybe this will help: https://forum.joaoapps.com/index.php?resources/livedisplay-control.341/

This tasks from joaoapps works only with pre v15 versions! It's using --cm as parameter. Newer ones needs --lineage parameter. Updated my op.

n0j0e said:
Hi,
here some commands to control the LineageOS LiveDisplay with Tasker/shell run.
To change Display Mode:
settings --lineage put system display_temperature_mode x
x = Off=0, Night=1, Auto=2, Outdoor=3, Day=4
To change color temperature:
settings --lineage put system display_temperature_day xxxx
settings --lineage put system display_temperature_night xxxx
xxxx = color temperature, eg 6600 for Day Mode & 4200 for Night Mode.
To change color calibration values, default is 1.0 1.0 1.0 (rgb):
settings --lineage put system display_color_adjustment "0.8991 0.8689 1.0"
I'm using it in conjunction with the great Twighlight Plug-in for Tasker. It gives better control for sunrise/sunset timings/locations and many more!
If you are still using CyanogenMod use --cm as parameter.
If something goes wrong i'm not here anymore!
But please report and include the solution.
Also report if there are more useful commands.
@ktmom
Thanks, but transformed the question to a solution by my self before i saw your hint! :cyclops:
Click to expand...
Click to collapse
Thank you for this, it helped me out a lot. So did the other user that posted to João's autoapps forum
Using LOS 17.1 rooted 1+7tpro5g

Related

[APP] LUMOS v1.0 *FINAL* (Complete HTC Auto-Backlight replacement) [UPD.:08-02-2011]

. . . .
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
. . . . (current version 1.0 FINAL)
More control. More battery. More comfort.
Lumos is fully customizable automatic backlight level changer developed as a complete replacement for stock HTC auto-backlight service. A wide range of HTC branded devices is supported starting from HTC Diamond/Touch Pro up to the current WM flagship HD2.
Lumos focuses on minimal CPU usage, maximum battery saving, low memory footprint while maintaining maximum backlight change smoothness and responsiveness. Lumos combines the best from all available auto-backlight solutions and adds many extras for your tweaking needs
Features:
- simple and clean installation and uninstalation
- extremely low CPU usage when working, 0.05-0.3% on polling
- NO battery and CPU overhead (drainage) unless you actively use your device's display
- low memory profile considering all the options
- simple and reliable configuration GUI with easy step-by-step calibration process
- many options that let you change every aspect of how your backlight works
- program exceptions to set different backlight for any application
- relative excaptions allow you to amplify/attenuate the automatic backlight for specific applications
- ability to force display ALWAYS ON for certain application
- integrated tool to detect all active application names, leave it running in the background and it will log all application names you use
- configuration failsafe. No matter what you do, Lumos won't crash, just tell you what is wrong and use defaults.
- supports vast majority of HTC branded devices since HTC Diamond
- many supported languages
Just install the CAB, start LumosWizard from programs or soft reset and you're all set!
- Lumos always installs to the device (no matter what you chose)
- Installer will create auto-start entry (Lumos will start after a soft-reset)
- Installer will create a shortcut to LumosWizard in your programs
- should any problem arise after first installation, try to soft-reset your device before consulting our FAQ below
Program installs to \Program Files\Lumos\
Lumos.exe = starts/stops auto backlight service, accepts commandline switches
LumosWizard.exe = graphical tool to configure all aspects of Lumos
settings.txt = configuration file is not included in the package, it will be automatically generated by LumosWizard after successful calibration, you can edit it manually in your PC or by using LumosWizard, text edits in device are probably no longer possible because of unicode encoding.
LumosStarter.exe = (re)starts Lumos service without any visual feedback (used for startup after soft-reset and for special issues)
TROUBLESHOOTING:
You can take these simple steps to troubleshoot any problem, perform both steps and if your device reacts differently than described try fixes marked ">" one by one starting from the top. Please restart your device before you start, your problem might fix itself.
1) Run LumosWizard, start Calibration and proceed to second step (max sensor), Lumos should report positive values as you move the device near to light source.
> move the damn finger! xD
> another application exclusively locked the sensor, try to disable other apps using light sensor
> sensor drivers or sensor SDK is missing, try if different application like G-Light works, report the problem if it does, update your ROM if it doesn't
> your sensor may be defective, try some 100% compatible ROM like Energy just in case and consider RMA if unsuccessful
2) Run LumosWizard, start Calibration and proceed to third step (minimum and maximum backlight setting). The backlight should actually change as a preview when you move the slider.
> check if windows built-in auto backlight is disabled in power settings
> another application may be forcing the backlight level, try to soft reset and disable other apps that can change backlight level or manage backlight in user profiles
> original HTC backlight utility DLLs may be missing in certain early WM6.5 ROMs, try to install BacklightHotfix.CAB attached to this post and reboot. If it just won't work, try another program like G-light, if you're still out of luck, try to contact your ROM chef about this.
Click to expand...
Click to collapse
You can send a symbolic DONATION if you with to reward me for my efforts.
Show that you care
There have been over 22500 downloads for RC2 version - just from XDA.
Donations will be used solely to buy muffins and pizza for late-night coding sessions... mmm
READ THE FAQ IN POST #2 BEFORE ASKING QUESTIONS
New files in additional languages pack:
none
DOWNLOAD:
FAQ:
What exactly is the calibration for, backlight is still the same after calibration?
The calibration ensures Lumos can detect the detection range of your light sensor properly and lets you set minimum and maximum possible backlight easily.
It has 4 steps:
1) Minimum value the sensor can read (probably 0 on all devices)
2) Maximum value the sensor can read (expect this to be something around 1400), you need to use a light bulb tor this step.
3) Minimum brightness you want. Lumos will calculate everything with minimum value reported by your device, but it will not let the backlight go below this value. (like if you want to have backlight 2 in shade because 1 is too dark for you)
4) Maximum brightness you want. Lumos will calculate everything with maximum value reported by your device, but it will not let the backlight go above this value. (You may notice that backlight level 7 and 10 is a little difference and can be both read in direct light, however if you limit the maximum to only 7 here, you will save a lot of battery)
5) After you are done with the calibration, you can review your setting on the settings tab and click 'Apply+Save' to exit LumosWizard and actually start Lumos service. There is no auto-backlight while the configuration Wizard is open, it defaults at level 6!
How program exceptions work?
- Switch to the Windows tab and start for example TomTom, leave TT and click it's name in the window list, then specify the backlight you want for this app and tap Add.
- If you disable "Exc. for active window only" on settings tab, you need to specify exact window name and exception will be triggered even for inactive application (minimized for example).
- If you activate "Exc. for active window only" on settings tab, you only need to specify part of the window name in exception settings (useful in case part of the window name changes). If the window name is "AdobeReader - document.pdf", only add exception "AdobeReader -". Be aware enabling this option increases CPU requirements of Lumos by about 20% (means roughly 0.06% total for slow diamonds).
Note that you will probably need to enable "Exc. for active window only" on settings tab for exceptions to work on WM6.5.
How to set a program exception step by step?
1. run lumos wizard
2. switch to the tab "windows" (the last one) and let the wizard run in background
3. run your program(s) you want to add
4. close the program(s)
5. switch back to lumos wizard -- voila, all the window names you visited are there!
6. tap the program name you want in the window list, it will switch you to the "exceptions" tab and fill the form for you
7. set the backlight level you want (1-10) and tap add to exceptions
What is a Relative Exception?
- relative exception does not force one specific level but rather amplifies and attenuates normal auto-backlight behaviour for the application in question.
Consider this scenario:
Code:
- my allowed backlight ranges in levels 2-7
- I want to use a navigation app in car and it is kind of difficult to see on sunlight, shades in car would read for level 3 or 4 and that is not bright enough
- I can either create an exception and force backlight all the way to 7, but that might not be optimal on battery
- therefore I create a Relative Exception of +2
- for the navigation application if the backlight would normally be set to 3 by Lumos, it will be amplified by two to 5. What would normally be level 6 will get amplified to 7, since that is my maximum level.
- You can also use negative values in Relative Exception to decrease the backlight for certain app by certain amount to save battery for example.
How backlight modes work?
- Backlight modes are individual equations used to determine proper backlight level from current sensor value.
- Linear - this mode is equally sensitive in dark and light environment.
- Root - this mode is more sensitive in dark environment and is best suitable for human eye and therefore default.
- Quadratic - this mode is more sensitive in light environment.
- Custom - this mode features customizable graph, you can draw a graph yourself with stylus or click on the blue area under each level number to input border sensor value manually.
Levels outside your min-max boundaries are hidden.
- Note that using custom mode do not affect CPU requirements in any way.
Commandline switches?
- There are 4 switches that can be used
"+" will increase backlight by one
"-" will decrease backlight by one
"s" will run normal Lumos operation without restart prompt after +/- tasks are completed
"q" will quit Lumos after +/- tasks are completed
Example to increase backlight by 3 and disable automatic:
Code:
"...iles/Lumos.exe" +++q
My *insert a game using G-sensor* is lagging strangely, can I fix it?
- guys from HTC thought it would be a cool idea to tie all sensors together in a framework, unfortunatelly it appears that when one program locks a sensor for read, other sensors may get locked as well on some devices. There is only one solution that will de-lag such game - not to use the sensor while it runs.
- Create a non-relative exception for the game in question and your lag should go away.
Backlight is not changing at all, it's the same all the time?
1) go to Start - Settings - System tab - Power - Backlight tab and DISABLE the 'Auto adjust backlight' feature.
2) close the configuration Wizard with "Save+Apply" button, auto-backlight service is disabled when you are configuring Lumos or when there is no configuration specified.
Program won't start at all?
You NEED .NET 3.5 Compact Framework Redistributable. It is faster and more stable and offers more stuff for developers than the 2.0 you probably have. It is rumored it may even make your device work faster (or at least .NET based apps).
Download it HERE (only about 3MB on device, don't be scared by the installer size as it contains support for more processors)
LUMOS CHANGES TRACKER:
(changes prior to RC1 version dropped)
! non linear backlight in the GLight style for people all over the net who are demanding this
! exceptions now need only part of the window name in "detect only active windows" mode
! recalibrated sensor readings for more sensitivity
! fixed bug in custom graph mode
! faster loading
! dropped DIM_TO_MINIMUM_PLUS_ONE_BELOW option
(below only in RC2 version)
! fixed custom mode alignment
(below in 1.0 Final)
! add support for relative level in exceptions
! add support to keep alive only as exception
! add command line support (change level & quit, +, -)
(below ideas for future development)
- add support for alternative backlight handling (WM default without HTC drivers)
WIZARD CHANGES TRACKER:
(changes prior to RC1 version dropped)
! support for setting linear, quadratic and root/logaritmic backlight
! support for custom backlight mode with interactive graph
! support for changing keyboard backlight delay on RAPH
! improved max/min detection in wizard
! forcing consistency between settings and graph plotting
! switching language in flight
! faster loading times
! support for language packs
! smaller text to allow better translations
! bigger tabs for better finger friendliness
! dropped DIM_TO_MINIMUM_PLUS_ONE_BELOW option
! fixed minor flaws from beta2 connected with translations
! improved settings tab scrolling redraw speed
! settings tab will back off from deploying soft keyboard
! added new languages: Bulgarian, Czech, Francais, Japanese, Nederlands
(below only in RC2 version)
! fixed Window detector taking you to the Mode tab instead of Exceptions
! fixed settings tab layout width
! added another failsafe mechanism against saving invalid min/max backlight and polling interval
! added warning message for options with potentially negative effect on battery
! added new languages - currently Bulgarian, Czech, French, German, Greek, Japanese, Dutch, Polish, Russian, Sim./Trad. Chinese
(below in 1.0 Final)
! set "BL=1 below" option to be relative to the sensor minimum
! set calibration to disregard sensor minimum 0 until the driver is initialized
! add support to release sensors on active exception
! add wizard warning if built-in auto backlight currently overrides Lumos control
! ability to recognize missing sensor drivers and the need for Backlight Hotfix package
! add support for relative level in exceptions
! add support to keep alive only as exception
(below ideas for future development)
- support for forced "on wakeup" backlight level
- = bug / missing part
? = possible bug/not able to reproduce/not verified/idea
* = in development
+ = fixed bug / completed part
! = fix/feature included in released version
NOTES:
Please disregard the hacks from previous versions and always set your sensor minimum and maximum to real values (0-xxxx)! Some sensors might have different minimum than 0 - this is a hardware defect and you need to use the defected value for Lumos to work correctly.
To admit it, I haven't installed it yet, but I'm tempted. Just one question which might also be of interest for others:
What's the advantage of your app compared with G-Light?
And not to forget:
Thank you for your work! I still find it amazing that many xda-devs are building programs for free just for a "thank you" by the community.
Well I tried G-Light and LevelSight but will only compare it to G-Light as LevelSight does things a bit differently IMO. I set G light to 3s polling interval to make the comparsion accurate. I don't like to put dirt on someone elses app, G-Light is a fine piece of software and I encourage the developer to implement some of my ideas to match mine and make it even better
- G-Light can behave competely unpredictably, it pumps up the backlight when you're in shade (this is because of the luminosity spikes)
- Lumos eliminates any spikes by the 4-read interpolation keeping your backlight more comfortable and smooth
- Lumos uses a tolerance which further prevents the backlight to unexpectedly changing (and causing a CPU spike)
-G-light rarely reaches below 1% of CPU usage (1-7%usage is common) which can drain your battery as a side effect
- Lumos rarely crosses above 0.5% CPU usage on default settings (0.05-3% usage is common) (NOTE: this will even improve in future versions)
- in G-Light You cannot change how fast the luminance values are read from sensors, they are read on change = further battery drain. You can only change how often to set backlight
- In Lumos you can set sensor read interval and backlight change in its multiplies to save CPU and power while retaining smoothness.
- Memory usage: GLightRunner 595.43KB , Lumos 311.53KB (but this will get a bit more later)
- No noticable memory leak in either applicaiton
- G-Light has a frontend app to set up
- Lumos has none yet but you can change the configuration file
- Neither Lumos nor GLightRunner can be completely shut down without using task manager (Lumos will once it has frontend GUI).
- G-Light can exclude applications
- Lumos can't yet
-G-Light settings is pretty much still limited compared to Lumos
To sum up it's definitely worth trying
nik3r said:
To sum up it's definitely worth trying
Click to expand...
Click to collapse
Thank you for your long and precise answer, You definitely convinced me!
I'll try it right away!
Lumos v02
Lumos Version 02 has been released, all the changes are logged as (!) in the bug tracker above.
Default settings response time is shorten to 2s, while CPU usage is pretty much the same as v01 with 3s refresh.
Memory usage: 339.53KB
CPU usage: 0.05-0.25% on scan, 3.15% on backlight change
Power consumption is 2mA better than v01
If you want to achieve more sensitivity of backlight transition without CPU overhead, set tolerance to 0 (CPU usage bug is fixed now).
Configuration file is now idiot-proof, program will tell you what is wrong on syntax/logical error
EDIT: 02b contains one more bugfix, the auto backlight range cap finally works 100%
Enjoy
nik3r
Quick question; does you app let the backlight go to 0% in full darkness, like LevelSight?
Yes it in fact goes to 1 (backlight disable) as lowest on default. You may want to increase it to 2 in the config file if it's too dark for you.
The point of this app is YOU set how it should behave, there are virtually no limitations unless you enter a complete nonsense to the config. And even then the program should just notify you about the incorrect settings and not crash, so don't worry and edit!
The program needs to be restarted in order to apply new settings. Either kill it via process/task manager or soft reset if you don't have one. Note that this acts like a program, it won't start again automatically if you kill it or soft reset. And also it won't store anything in your registry or enywhere else on the device, so it's perfectly safe to "just try". I will make a manager app later that will let you setup and control this underlying process.
But FIRST we need to make sure the service is bug free and does everything we need before I even start building the front-end app
Also you may share your custom settings you find best with me and if it's performing well I can select that one as default for future.
Thank you Niker! V2 is working great for me. Only one thing:
The lightlevel changes linear as you've explained and that's basically working fine (and much more smoothly than G-Light for example). But it tends to get to dark. I've now changed the minimum setting to "3" to get the average backlight-level I prefer. BUT: I like to read late at night in bed and it would than be nice to have the backlight at level "1". So would it be possible to exclude light level 1 & 2 from the linear alignment and to only use those levels if it's "really dark"?
PS
Just to give you a bit more information about my personal preferences and what I want to achieve:
I actually like the default HTC auto-backlight. It more tends to bright than to dark backlight and it's making the level changes very smoothly so you almost don't notice them.
The only thing i don't like about it is that the minimum level is hardcoded to level 3 which is too bright for me when I read in bed with no additional light in the room.
Of course those are my personal preferences and that of course doesn't necessarily mean that your app is meant to handle that way!
Well I have an idea, I wonder if .NET CF 3.5 supports external scripting as the PC version does. Basically that might allow you to replace the backlight algoritm without compiling the program yourself. You could quite easily make exceptions binded to really low lumen values or time of day with just 2-3 lines of code.
EDIT: I fear this is not possible, System.CodeDom.Compiler is awfully stripped down, I would have to make up my own scripting language for this to work and that would be very difficult.
But I think I can add this as a setting to the configuration file.
DIM_TO_MINIMUM_BELOW = 0
- disabled (default)
DIM_TO_MINIMUM_BELOW = 25
- below 25/750 lumens
very simple and I think this would do about what you want
Expect this in the new version.
nik3r said:
I'll report back whether this is possible in mobile version...
Click to expand...
Click to collapse
Thank you mate, I really appreciate it!
Thanks for your suggestions.
Lumos v02c is out, it contains your 2 desired options (for backlight 1 and 2 separately). You will however be disappointed by the sensitivity of raphael sensor, it reports 0 like all the time.
This change theoretically lets you set lumen values for the 2 lowest values manually and once the sensor reads larger values, the MIN/MAX_BACKLIGHT kicks in. It's possible to have 4-8 auto and dim to 1 or 2 on low light, so you can kinda simulate the behaviour of LevelSight if you want to.
Oh and as the cherry on top I disabled tolerance by default, for more smoothness, the impact on CPU and battery should be minimal < 0.05%
The next version should include a tool to easily restart Lumos to apply settings, it will be needed for the graphical user interface later.
Enjoy
Major version released:
Lumos v03
- all bugs connected with dynamic backlight should be fixed now
- changing settings.txt is even safer (program should never crash, just tell you where is problem and use defaults)
- includes LumosKiller.exe that can start/restart/shutdown Lumos easily
In case no bugs are found until friday, I will start building GUI.
Could you integrate special brightness normally only used when starting the camera? You'd probably need to debug the camera application to find out about the special ICOTLs for that. I did that with my Magician back in the days.
Program-specific exceptions will be added after the GUI is done, I still need to figure out how to list running windows by name. If you have any experience with this using C# or C++ I'd be happy if you PM me, but I guess uncle google knows how to do this, just refuses to share it with me right now
Uz to testujem, zatial to vali krasne a v pohode ;-)
I just wrote that I'm currently testing it, no problems so far.
Thank you and please keep up the good work ;-)
Great application Nik3r!!
i like so much, because don´t touch my registry, It´s light,and also have minimal resources consumption
But, i need your help with the configuration file,
i have htc diamond, and the battery of this device drain fast
how can set the settings to obtain best battery duration?
Thanks a lot!!
You can increase the polling interval, enable some tolerance and lower the maximum brightness.
Try to make these changes:
MIN_BACKLIGHT = 1
MAX_BACKLIGHT = 6
POLLING_INTERVAL = 1500
EXTRA_POLLS_BEFORE_SET = 1
BACKLIGHT_TOLERANCE = 1
set minimum backlight to whatever is reasonably visible in shade
.. this will set your polling interval to 1,5s and make your brightness change every 3s instead of 2. The tolerance prevents brightness changess less than 2 units. It's the brightness change that eats most CPU (up to 3% spike) and thus battery and the tolerance makes sure it's not changing until a larger change is required.
And make sure you killed the old v01/02x version or soft reset before using 03 because older versions can't be killed by LumosKiller and two of them running may ruin your battery.
... hmm by the way I wonder why I didn't call it "Nox" instead of LumosKiller (any similarity with HP books is completely unintentional )
Good luck
Thanks for your quick and detailed reply!! i did those changes you suggest,
I´m really fan of your app!!

[APP][2.2+][11 Dec. 2022 - V3.1] BetterBatteryStats

I started BetterBatteryStats because I was missing the great battery history that Spare Parts allowed to call on Froyo. It has been a long journey since the first version. BetterBatteryStats provides an insight in following categories:
- General "other stats "overview: Awake, Deep Sleep, Screen On, Phone On, Wifi On, Wifi Running ratios
- Kernel Wakelocks
- Partial wakelocks
- Alarms/Wakeups
- CPU States
- Network stats
- Process stats with User and System CPU time
Use so called references BetterBatteryStats shows data for different samples over time:
- since boot
- since unplugged
- since charged
- since screen off
- custom references
- any combination of the above (e.g. from screen off to screen on)
BetterBatteryStats is calling the "batteryinfo" service of Android to retrieve data already lying there without generating overhead. Since Kitkat Google has revoked the permission for normal apps to access these stats (without valid reasons IMHO). You can read more about that here.
Fortunately and thanks to @Looki75 there is a way to work around the restrictions intruduced by google in Kitkat and run BBS on non-rooted devices. Please see here for more details.
BetterBatteryStats has been tested on Froyo, Gingerbread, Honeycomb (3.1, thanks to daveid), ICS, JB, Kitkat and Lollipop on different ROMs and Kernels.
What are wakelocks and why should you care about them?
When it comes to Android the most discussed and commented topic that I know is battery drain / battery life. I'm a quite heavy user because I spend a lot of time on the train every day reading my mails, surfing and listening to music but still my phone is off for a long time during the day and while I accept the battery being drained while I use the phone I care about it draining slowly while "doing nothing".
Wakelocks or to be more precise partial wakelocks is a pattern than helps devs to make sure that important pieces of their code do not get interrupted. Wakelocks are not bad per se, they are a tool. There are many poor implementations that make use of wakelocks and BBS helps making that transparent.
Caution: do not use and wakelock supressor tools. They will cause an erratic behavior of your phone, causing more harm than good.
Basically the phone has (simplified, kernel devs don't shoot) three states:
1. awake with screen on
2. awake
3. sleeping (that's you phone favorite state)
The transitions are from (1) to (2) and finally from (2) to (3). Now as long as you use your phone it's in (1) and does not leave that state as long as you keep using it interactively. If you stop using it the phone is aiming to go to (3) as fast as possible.
And here's where wakelocks are important: as our phones as smartphones they tend to do background processing. Some of this processing is important like e.g. making a phone call, listening to music or synchronizing your contacts.
As the phone wants to go from (2) to (3) and on the other hand you don't want to hang up while you are in a call the app keeps hold of a wakelock to prevent that transisiton. When you hang up the partial wakelock gets release and here we go (the phone goes to sleep).
So partial wakelocks is a tool and it's not something that we should forbid for obvious reasons. Now there are cases when the design on an app is not real life proven (conditions of poor of no converage) and the wakelocks have negative effects because they are held unnecessarily or for too long.
BetterBatteryStats identifies these wakelocks and using your expertise or the once from our users here you can understand what happens and find a strategy to change that for the better.
And what about wakeups?
Wakeups (alarms) is a pattern to be used when an application should to something after a certain period of time (or at a certain time). Again, an alarm is a tool and is nothing.
On the other hand there are a lot of poor implementations that BBS can help you discover:
- alarms waking up the device when all the app should do is refresh the screen: in such cases the app uses the wrong type of alarm, there are alarms that are specifically to be used only when the screen is on
- to frequent alarms: in case of e.g. poor network conditions some apps may use alarms to repeat failed network operations. Doing this too often will cause too many wakeups (and wakelocks for doing the handling)
- apps that wake up your device when you did not expect any activity while screen is off: you can use the info provided by BBS to contact the dev about such issues
Try it yourself
If you need help
Always add the whole context when asking for help. Most of the times a dumpfile is helpful, sometimes screenshots showing your observations may help as well.
Before posting a dump please make sure that the references for kernel wakelocks and alarms were processed correctly. Reading a dump takes a few minutes and it would be great if you could not waste the time of whomever studies it, aiming at helping you.
Generally a dump "since unplugged" is better than "since charged". When you start your analysis make sure to follow following procedure:
- enable watchdog processing in BBS settings
- verify from/to references is checked under custom views
- full charge device then let it run down to ~95%
- put device to sleep for at least 6 hours (no touchy!)
- wake device and launch BBS
- adjust from/to references to 'screen off' and 'screen on'
- save dumpfile from share menu
- post resulting log to this thread (or provide cloud link)
I will not reply to posts with incomplete dumps
Reporting bugs
If you want to report a bug please make sure:
- that you can reproduce the problem
- explain what the problem is, how you could reproduce it and what is going wrong (a sentence lke "xxxx does not work for me" is a waste of your time and wil be ignored)
- enable debug in advanced prefernces
- post a logcat
A good read about reporting bugs
Translations
Starting with 2.0 BBS is getting multi-language. Currently following languages are included:
- en: main language, maintained by me
- ru: translation thanks to @gaich
- cz: translation thanks to @mag01
- es translation thanks to @vldesco
- it translation thanks to @code010101
- hr translation thanks to @seky2205
- fr translation thanks to @xavihernandez
- de translation thanks to @Minty123
- tr translation and other language improvement by @Eleo
If you want to contribute with a new language please feel free to offer you service and contribute to BBS, by submitting a pull request to the github project with the translated strings.xml. But please be aware of the fact that translation is a continuous work: even if the initial effort is higher there will be unavoidable changes to the english master XMLs that will require regular updates of your translations.
If you have a recommendation for a free croud-translation service that you would prefer I am open for suggestions.
Thanks
To nobnut for donating me a Nexus S for testing
To nobnut and brandall for their support, encouragements, testing and constructive feedback in the early stages of the development.
To @Javinotfound or the new icons / logo
To suku_patel_22, jeremysherriff, Karpfenhai, Tungstwenty, It_ler, Perseus71 and mag01 for their help in this thread and their systematic testing my betas and RCs
To Entropy512 for providing support and insights about kernel wakelocks and helping making BBS a better tool
Release
Edit 2021-06-13: Google has pulled BBS from GPlay. The given reason is that I use a library (HockeyApp) that allows installations by other means than the GPlay; that is correct except that library is a) deprecated and does not have backend anymore and b) the GPlay edition does not use that library, only the xda-edition does. Anyhow, I am working on a fix
BetterBatteryStats is available on Google Play (https://play.google.com/store/apps/details?id=com.asksven.betterbatterystats) for what I believe is a fair price. If you like my work and want to support me please fell free to show your gratitude by buying the app.
Google play users can register to be part of the public beta programme. Selected Release Candidates will be released to google play as part of the beta programm. You can enroll to the beta programme here: https://play.google.com/apps/testing/com.asksven.betterbatterystats
Follow me on Mastodon to be notified of updates and get insights in new features/developments.
xda edition: for xda-dev members I provide an always free and fully featured version of BBS (please play fair and do not redistribute the app without my consent).
Current test-release:
I have moved to an automated build system (older releases are still attached here) and do the distribution using AppCenter.
Privacy note
Access to the downloads does not require you to register to AppCenter (you still can to benefit from neat features like notifications when new releases are available)
Get release candidates here
Changelog
2.3
- Full android O support
- Unrooted devices now fully supported (with perms added using ADB)
- UI improvements and I18N
- Better support for substratum theming
- Fixes based on crash-reports
- Added application analytics
2.2.2.0
Fixed #791: bugs preventing sensor stats to show properly on pre-lolipop devices
2.2.1.0
Fixed #787, #788: bugs preventing some stats to show properly on pre-lolipop devices
2.2.0.0
Merged translations
same as RC3
Older Changelogs
2.2.0.0RC3
Fixed sensor report
Prep for release
2.2.0.0RC2
#780: Added proper Sensor Stats
2.2.0.0RC1
#659: Renamed "Other" stat to "Summary"
#398: possibility to add a note when saving a dumpfile
#682: Alarms details view is now scrollable
#772: use bolder fonts to comply with design guidelines and make reading on smaller devices easier
#677: added GPS time (sensors) to Summary
#777: folded both Text and JSON representations of the dumpfile into one file
2.2.0.0B6
#675: watchdog sometimes shows awake > 100%
#756: added LG G2 Kernel Wakelocks support and more agressive detection of LG G2, G3, G4
#759: Watchdog toast sometimes get sticky
#760: Kernel Wakelocks do not substract properly on non-root devices (or with API-mode on)
#762: alarm do not show icon on non-root devices (or wirh API-mode)
2.2.0.0B5
#733: Kernel wakelocks parser for LG G4
#753: Added option to select the destination directory for dumpfile/locat/etc. (Requires OI FileManager)
2.2.0.0B4
#715: introduced snackbars instead of many of the toasts
#731: fixed layout issues for "old" widgets with RTL languages
#749: fixed another non-root issue
2.2.0.0B3
#211: add sensor data to "other" stats
#741: improvements on non-root experience (network stats, fixes)
#748: fixed doze mode counters
Added sync time to other stats
2.2.0.0B2
#734: added doze mode stats (Marshmallow)#744, #747: more fixes for non-rooted usage
#745: fixed/more accurate Bluetooth stats for Marshmallow
2.2.0.0B1
#716: experimental: grant required permissions without having to install system app (requires root)
#735: fixed parsing of native alarms and API call for Marshmallow
#736, #737, #738: various FC from gplay crash reports
#741: improve functionality for non rooted devices (having system app installed)
2.1.0.0
No changes from RC6
2.1.0.0_RC6
Some more widget tuning
Merged transations
2.1.0.0_RC5
Some widget tuning
Merged and compacted changelog
2.1.0.0_RC4
#720, #721: "Awake" is now consistently "Awake when screen off"
2.1.0.0_RC3
I18N
More work on widget
2.1.0.0_RC2
#712: Fixed widget real estate
2.1.0.0_RC1
#708: reverted AppOps call back to older working version
#711: fixed process view sort
#713: fixed graph series
See also in-app changelog
2.1.0.0_B5
#673: permissions list scroll issue
Experimental M-preview support
Transition animations
2.1.0.0_B4
#612: kernel wakelocks for LG G3 5.0
#694: added awake ratio to dashclock
#699: merged system app changes
#702: moved to new appcompat
New Icons by Javi
2.1.0.0_B3
#693, 695: fixed crash on 2.3.x devices
#693: reverted back to "old" (small) system app apk to work around CM/LP 5.1.1 installation isuues
#696: fixed behavior of the "back" icon on older Android devices
2.1.0.0_B2
#671: revert to old AppOps calling method
#681: fixed rate dialog
#683: limit widget font size
#686: string mssing leading to @number being displayed
#687: widget opacity can be adjusted
I18N
2.1.0.0_B1
New responsive widget
#510: New System App (no need to update)
#658: Fixed various crash reports from gplay
#679: Fixed graphs being off on 5.1
#405: Fixed widget sometimes not refreshing at screen on
2.0.0.0
No functional changes from RC6
Merged I18Nalized changelogs
2.0.0.0RC6
This is the golden release: release notes have been updated for the upcoming 2.0
#650: semi transparent grey touch feedback for pre-lolipop devices
- Sorry, no fix for the unthemed dialogs: there is a bug in appcompat to that and I could not find a way around that except rewriting all dialogs and that is too much change at this point in time.
2.0.0.0RC5
#632, #633, #634, #635: Fixed package info dialog (colors, label width)
#639: added arabic (testwise)
#626: fix (again) for FC on long press using german language
2.0.0.0RC4
#626: fixes crash when long-pressing a list item
#630: added credits for I18N
#631: hotfix for issue with RC3 on pre-lolipop devices
2.0.0.0RC3
#616: no battery graph when all values are 100%
#617: no changelog showing in RC2
#618: add info to dumpfile is alarms/kernel wakelocks are from API
#621, #624: I18N
#622: material design touch feedback
#625: FC opening dashclock settings
2.0.0.0RC2
#552: fixed wrong style for overflow menu in dark theme
#609: fixed oblique lines in graphs
2.0.0.0RC1
#546: option to force EN-en locale
#569, #582, #588, #595: more translations
#583: move *api* out of the title
#585: optimized load time of graphs
#586: use white icon for watchdog notifications
#597: battery graph always shows same data
#599: FC opening credits screen
#600: clean up debug info from normal logcat
#602: fixed watchdog reporting of awake
2.0.0.0B7
#491: added frature to import/export preferences
#540: System App Dialog now includes link to the recovery ZIP as a workaround is in-app install does not work (links to XDA or gplay, depending on version)
#551: fixed "pinned" battery graph
#553: lighter cicle gauge and font
#554: settings screen and white text on the light background that appears after clean start
#558: make from-to ref spinners suppressable
#563: more I18N (thanks to gaich and mag01 fpr their hard work keeping up with me changing the strings)
#564: alarm details dialog title is too dark for dark theme
#566: add notification bar color for lolipop
#572: pass the su --context for accessing dumpsys alarm (may cause slowdown, please report on that with supersu version you are using)
#574: better performance in graphics
2.0.0.0B6
#521: make icon size and font size adjustable
#522: kernel wakelock using API fail on lolipop
#550: missing strings
#556: fixed native kernal wakelocks on lolipop
#557: no translation of array, mote stuff to strings
2.0.0.0B5
#360, #529, #534, #539: more externalized strings for I18N
#387: use of wakelocks with timeouts, because I can
#511: Themed dialogs
#517: redesigned graphs
#527: add SELinux policy to dumpfile
#532: fixed theme switching issues
#535: added Czeck, thanks to mag01
#536, #537, #538: added russian, thanks to gaich
#531: fixed alarms dialog showing infinite / Hr.
#545: merged new constants that were causing the wrong stats to be processed
2.0.0.0B4
First shot at I18N: implemented german
#495: cleanup ununsed libs
#502: cleanup assets
#518: fixed infinite wakeups per hour in alarms
#519: re-add battery from/to % to screen (optional)
#520: alignment of labele/icons
#523: theme switch only complete after restart
#524: switched back from cards layout as it takes too much real estate
#525: notification area invisible by default
#526: FC after theme switch
#528: Partial wakelocks show wrong values (thank google for changing the constants again)!
2.0.0.0B3
#484, #508: surface information about errors / failures to the UI
#493: avoid retrieving the battery level from battery info API to reduce load (and avoid service unavailable)
#497: added dark theme
#509: added % from/to back to dumpfile
#512: theme preference slider controls
#513: fixed empty release notes
#515: automatically detect SELinux preventing access to dumpsys alarm and fall back to API mode
#516: fixed alarms showing infinity in gauges
2.0.0.0B2
#496: fixed gauges in RAW stats always being 100%
#499: "since" and white header missing in raw stats
#504: failed remot to ro after system app install does not report an error anymore since the app was installed correctly
#505: advanced pref to enable alternate (API) mode for retrieving alarms (and avoid the need for permissive kernel)
#506: alarm details missing in dumpfile
Bigger changes under the hood: externalized all preferences to prepare for I18N
2.0.0.0B1
It's all new and shiny
#487: ability to save JSON format from tasker plugin
New calculation approach to avoid rounding differences
Simplified / removed unused options from settings
Removed google analytics
1.16.1.0B2
#486: watchdog does not warn
1.16.1.0B1
#446, #483: watchdog warns about 100% awake even if reading shows it's not the case
#481, #482: FC conditions from crash reports
#485: addedf more comprehensive info about BATTERY_STATS perm and Xposed setting to dumpfile
1.16.0.0
no changes from RC6 1.16.0.0_RC6
#479: attempt to fix failing system app install process on certain devices
#480: fixed Dashclock settings not opening in xdaedition
1.16.0.0_RC5
#475: more speaking text for XPosed module settings
#476: fixed dashclock API 2 manifest (kudos to DvTonder)
#477: fixed exception in method to obtain other stats from dumpsys (compat mode)
#478: fixed alarm parsing error on pre 4.2 versions
1.16.0.0_RC4
#469: Fixed network stats parsing error
#472: Fixed alarm parsing for L preview
#473: fixed wakelock being expressed in ms on L preview
#474: fixed sorting of CPU states
1.16.0.0_RC3
#470: fixed non null extra passed by certain launchers
#471: fixed batterystats service name on L preview
1.16.0.0_RC2
#464: fixed icon height in list
#466: if xposed modue is checked in advanced prefs do as if all perms were there (use at your own risk)
#467: fixed missing icons in network view
#468: fixed FC condition when creating a logcat
1.16.0.0_RC1
#463: added copy to clipboard on long-press
Merged to master1.16.0.0_B7
#462: fixed antialiasing of pie gauge to avoid pixelation
1.16.0.0_B6
#457: fixed FC on calling permissions
#458: fixed value of "other" stats gauge being off
#459: pie gauge brush too large on low density devices
#460: add setting to disable system app presence (for XPosed module users)
#461: added setting (display section) to use "old" bar gauge instead of "new" pie
1.16.0.0_B5
#452: update to Dashclock API 2.0
#453: fixed "current" reference not getting updated when BBS is called from tasker
#454: fixed network stats "lo" not matched to "Mobile"
#455: merged a few UI changes from the upcoming 2.0 branch
#456: fixed: when only one reference spinner is shown avoid Toast message
1.16.0.0_B4
#426: added occurences per minute/hours in alarms on screen and dumpfile
#450: fix for memory leak
#451: revert from JSON the Java serialization of references for better performance (references will be deleted after installation)
1.16.0.0_B3
#448: if root is available offer full featured alarms using dumpsys
#449 avoid flushing cache, imporving performance
1.16.0.0_B2
#447: system app has wrong signature
1.16.0.0_B1
#427: optimize the root calls for dumpsys if system app installed
#429: replace java serialization of references with a more flexible JSON serialization
#435: avoid crashing when appops not available (4.4.2+)
#437: better resetting of screen counters for non rooted 4.4+ devices
#439: dumpfile chapters comments reflect need for root
#440: better support for root (does not require to be enabled in advanced prefs anymore)
#441: offer to install as system app on 4.4+ is root available
#443: alarm does not require root anymore
#446: watchdog notification should never report more than 100%
1.15.0.0
Same as RC8 except the release notes
1.15.0.0_RC8
#432: make sure to ask for su rights right after enabling root features
#433: hint that the system app should be uninstalled before uninstalling BBS
1.15.0.0_RC7
#430: better fix for blocking root access
#431: fix for install as system app when package comes from gplay
A few changes in the popup for kitkat user at first run
Bump in version number causes references to be deleted at first run
1.15.0.0_RC6
#430: fixed blocking call if trying to install as system app without having root features enabled
1.15.0.0_RC5
#428: force mediascanner after saving files
Recreated icons in all densities
1.15.0.0_RC4
#421: Another attempt to fix the xxxhdpi icon
#426: fied missing process stats on kitkat
Fixed other stats not refreshing properly on kitkat
1.15.0.0_RC3
Fixed the way we manage system apps
1.15.0.0_RC2
Sharpened xxxhdpi icon
Added the ability to install BBS as system app (requires root, usefull only for kitkat right now)
1.15.0.0_RC1
#424: add proper (error) messages to notify about features not available without root on kitkat.
Add timing of screen on time when no stats can be retrieved
1.15.0.0_B6
#421: added xxhdpi assets
#423: fixed alarms parsing on 4.3+
1.15.0.0_B5
#422: fixed account info obfuscation for new account format coming with kitkat
1.15.0.0_B4
#418: re-add process stats to kitkat
Fix for potentially missed partial wakelocks where uid could not be found
1.15.0.0_B3
#419: Package info and icons re-added to kitkat partial wakelocks
#420: fixe from gplay creashreports
Added hires icon
1.15.0.0_B2
#416: readded missing other stats (kitkat)
#417: fix for duplicate partial wakelocks
1.15.0.0_B1
#414: Fixed error at launch (service not available for kitkat)
#415: re-added partial wakelocks and very basic other stats (deep sleep only) to kitkat (requires root)
1.14.0.0
Updated libs
1.14.0.0RC1
#404: Fixed text padding for short time strings
#407: added app ops for 4.3+ users
1.14.0.0B2
#401: added ACCESS_SUPERUSER to manifest permissions
#402: wrong values in wakelocks with hashed account info caused by hash being applied multiple times
1.14.0.0B1
#355: implement a permanent su shell to execute all commands
Various fixes from gplay crash reports
1.13.4.0
Same as B2, no changes
1.13.4.0B2
#391 support all implementations of sqlite
1.13.4.0B1
Refactoring of database access to avoid locking
1.13.3.0
Fix for users having FCs due to database lock problem
1.13.2.0
Fix for users having FCs at start
1.13.0.0
Unchanged from RC2
1.13.0.0RC2
#384: salted the account name before hashing
Fix for stats not reflecting the combo boxes anymore for some users after a reference refresh
1.13.0.0RC1
Fix to make sure spinners do not get out of sync
#383: Fixed battery / voltage level in dumpfile
A few typos
Added timestamp to logcat
1.13.0.0B5
#191, #334: Added "share" option for saving/sharing dumpfiles, dmesg and logcat
#381: fixed database exception occuring sometimes and potentially responsible for the blank stats happening from time to time for some users
#382: dmesg requires root for newer kernels
1.13.0.0B4
Added some logging to debug percentage problem: adb logcat | grep StatsAdapter
#377: refactored KB handling
#379: refactored "raw" stats
Stats row shows interactive areas (glow)
1.13.0.0B3
#236: mask account info
#378: fixed fallback stat in DashClock widget
1.13.0.0B2
#376: no icon in process view
#377: missing KB icon
1.13.0.0B1
#367: added dashclock support
#375: added JSON dumpfile format support
1.12.4.0
#372: Widgets do not update on a fresh install
#373: change default widget fallbacl to "boot"
#374: refresh spinners and user refresh causes the cache of refs to get flushed/reloaded from data
1.12.3.0
#369: small widget uses wrong prefs
#370: Other stat times/total time incorrect
1.12.2.0
#366: fixed FC when creating a dumpfiel from tasker
Improved logging
Fixed concurrency problems potentially leading to weird display
Fixed a caching issue
1.12.1.0
Fix migration issues from 1.11 leading to inconsistent stats
#359: make sure BatteryInfoUnavailableException does not other stats to be shown
#361: a better fix for battery/voltage using current instead of "to" stat
#363, #364, #365: fixed different error conditions from crash reports
1.12.0.2
Skipped 1.12.0.1
#356: bug when migrating from 1.11
#357: to battery % always shows current value
1.12
Same as RC12, no changes
1.12RC12
#356: fixed empty stats after screen being rotated
1.12RC11
#223: active monitoring
#346: save 'unplugged' ref at first use to avoid empty refs
#347: pref to diable widgets to be refreshed at screen on
#344: better fix for errors in parsing network/alarms causing the whole reference to be saved empty
1.12RC10
#302: added credits for used libs in app besides git (under help)
#342, #345: remove log verbosity when debug advanced pref is not enabled for cleaner logcats
#343: fixed alarms parsing of details for flg= and cmp= (both pre- and post 4.2.2)
#344: error in parsing network stats causes the reference to be saved empty (potentially a cause of reference shown as not having been created)
1.12RC9
#323: pref for saving dumpfile to private storage
#337: implement 48dp rhythm
#338: optimize list real estate
#339 (partially): fixed tiny font for widget being same as small
1.12RC8
#341: fixed alarms for android 4.2.2
1.12RC7
#327: spinner refresh issues
#331: sometimes the stats shown do not reflect the spinner selection
#333: charged and unplugged should not be in the "to" spinner as that makes no sense
1.12RC6
#307, #328; widget stops updating and stays blank
#327: spinner refresh issues
#329: fallback ref in 1x1 widget is never loaded
#330: an attempt to fix wakelock issue when su commands are blocked
1.12RC5
#326: fixed rate dialog showing at each start
Some profining
Less intrusive logging if dedug is disabled in prefs
1.12RC4
New readme and rate dialogs
#325: times in wakeup_sources are a factory 1000 to small
1.12RC3
#321: fixed spinner heights
#322: filter "0" cpu states
#324: add marker to dumfile if using wakeup_sources
1.12RC2
#320: added experimental support for wakeup_sources (newer kernels deprecate /proc/wakelocks)
1.12RC1
#318: automatically refresh current when entering the main screen (can be changed in adv. prefs)
#319: "to ref" is shown by default (can be changed in adv. prefs)
1.12B9
#316: FC when calling BBS from watchdog notification
#317: 2x2 widget showing 0 KWL/PWL
1.12B8
#312: Fixed negative CPU percentages
#313: refresh after events creating new references show inconsistent references (from/to)
#314: proper migration of default stat type prefs coming from 1.11
#315: fixed cause of "unknown error"
1.12B7
#310: fixed partial and kernel wakelocks always being the same and icons missing
#311: fixed kb reader thread not retriieving online content
1.12B6
Changed the way su operations are processed
Some fixes regarding the refresh of the spinners
Make sure all root operations are running in an own thread
1.12B5
#308: since boot can not be selected
Fixed callstack when updating a reference
Widget now have a lightweight method for obtaining the current data without causing the cache to be updated
Spinners show references sorted in ascending order
Fixed spinner not showing all existing references
1.12B4
#306: fixed broken dumpfile
Added pref to show/hide the "reference to" spinner
Added screen on reference (saved when watchdog is active)
References are now stored in a database
From/To references are chronogical
1.12B3
#303: invalidate "current" when other refs are saved
#305: dissapearing refs
1.12B2
Some tuning
#298: Fixed FC on raw alarms
#299: Watchdog does not report when awake > threshold
#300: fixed spinner height
1.12B1
#187: freeze current time
#193: add screen brightness states to "other" stats
#274: copy wakelock to clipboard
#279: add option to save dmesg
#286: add mV/h to dumpfile
#290, 292: typo, wording
#296: kbreader is now asynchronous and doesn't block UI thread when github is slow
1.11
no change from RC8
1.11RC8
#289: FC on package info screen for pre-ICS devices
1.11RC7
#288: usability issue in permission view fixed
1.11RC6
#276: another attempt at fixing scheduled dumpfile creation from tasker
#287: fixed ratio calculation for battery drain in %/h
1.11RC5
#280: added legend to permissions tab
#283: unticking watchdog option "Screen off" stops the EventHandler service
#284: added drain per hour to battery drain text on screen and dumpfile
1.11RC4
#281: Fixed bad reference on unplug when 100% charged
#276: fixed dumpfile creation from tasker
removed delimiter till a configurable version can be provided
1.11RC3
A better fix for widgets being updated
Nicer implementation of package info using a tabbed pager (using ActionBarSherlock)
Changed in-app help and messages to make the conect of references clearer
More speaking "missing ref" texts
1.11RC2
#277: more prominent delimiter in listview
fixed calculation of since value
1.11RC1
#229: show autorun and other package info like permissions and services, click on the icons
#279: reverted the time reference for since and calculations back to 1.9.x
#275: widgets do not always refresh: hack to make sure the widget always get the broadcasts from the launcher, even if the lancher is not complying with standards (see http://stackoverflow.com/questions/7390449/widget-notification-when-homescreen-app-is-restarted)
yet another attempt to fix since screen off dump incomplete when created at wakeup from taker plugin
big refactoring (only relevant for the ones reading the code)
1.10.5
No changes from RC1
1.10.5RC1
Make sure app is not installed to SD (watchdog, widgets, detecting boot and unplug won't work properly)
Writing references respect "root features" settings
Fixed error condition in widget (potentially not showing data)
Refactored broadcast handlers
Another attempt to fix dumpfile creation in tasker plugin
1.10.4
Fixed logcat permission
1.10.3
Some changes in widget code
#270: added option to save logcat from app
1.10.2
#263: adv prefs to turn on stats while plugged
#264: error happening when reading other stats should not skip the whole stats
#265: reference summary shows data instead of counts (in dumpfile and log)
#266: difference in "since" time between widget and screen
#268: error when checking charger status causes exception
1.10.1
#261: missing cpu states file causes references to stay empty
#262: battery level handling causes exception
1.10
A few changes in logging
New ?????
1.10RC3
#257: referencea are missing processes
#258: if debug pref is not checked since shows 0s
1.10RC2
#256: silent crash on progress dialog
#252: a better fix for the FC on enabling root features
Typo in prefs
Added drain to on screen battery info
1.10RC1
#251: added batter level from/to to screen (and a pref to enable/disable it)
#252: an attempt to fix the FC on enabling root features
#254: incomplete (ref missing) dump from tasker
#255: not systematic crash on creating custom ref
1.10b7
#248: added raw CPU states
#249: ratio of other stats is calculated against something that is smaller than "since"
#250: when a reference is null all stats should show that there is no reference availble
1.10b6
#247: fixed deep sleep sometimes being substracted twice, causing negative values
1.10b5
#245: source of "since" is now the reference
#246: added battery voltage/level from/to to dumpfile
Removed unneeded API calls (that were to cause to batteryinfo stopping)
New error handling exposes API errors to the user
1.10b4
#243: deep sleep not showing
#244: no stats when plugged (as some internal registers do not count when plugged, leading to inconsistencies)
Removed pre-1.9 migration code that may lead refs to be deleted at start
#235: grey background for bars
1.10b3
#234: show icon for stats providing package info
#8: call application settings when package info is available (click on icon)
Refactored error handling
Workaround to avoid SuperUser to obcess about asking for rights
1.10b2
#240: removed "test" menu
#241: fixed nested menu causing FC on SDK<14
#242: removed froyo specific references as BBS is not depending on Android's implementation of refs anymore
1.10b1
#209: added since boot ref
#227: fallback to since boot if default stat type is not available
#228: pref to control log level
#230: two step save of references to avoid empty references if su request times out
#231, #232: reorganized preferences
#233: reorganized menu
#238: process Siyah "deleted: " kernel wakelocks properly
#239: network stats / alarms are disabled by default, can be turned on in advanced prefs
1.9.2.1
#226: reference info to dumpfile
1.9.2 (|xda only)
Fixed error condition where "no ref since charged" appeared after a while when a reference was present
#224: screen on time is too high in "since screen off"
1.9.1 (@xda only)
Added more logging to references
#213: Tasker plugin does not create dumpfiles / custom refs
#216: more compact CPU state view
#218, 220, 221: various fixes from Google Play logs
I maintain A list of features to be implemented and bugs here.
Below you can find older releases.
If not required I do not recommend using these as they are not up-to-date with the most current development, features and fixes.
How-to and FAQ
How-to
I have created a GitHub project for the Knowledge Base where the online and in-app help will be maintained as well. You can find the information here:
The online help: https://better.asksven.io/betterbatterystats/help/
The how-to: https://better.asksven.io/betterbatterystats/how-to/
A good how-to by Chris Hoffman published by How-to geek
Online Hilfe auf Deutsch: http://asksven.github.com/BetterBatteryStats-Knowledge-Base/help_de.html
How-To auf Deutsch: http://asksven.github.com/BetterBatteryStats-Knowledge-Base/howto_de.html
The repo: https://github.com/asksven/BetterBatteryStats-Knowledge-Base
The Knowledge Base Project: http://asksven.github.com/BetterBatteryStats-Knowledge-Base/
FAQ
1. Q:Will BBS be fixed to support Kitkat (I get "Services could not be contacted" errors?
A: Kitkat is supported by BBS starting from version 1.15
2. Q:Why are partial statitics not available on Kikat?
A: If you have a rooted phone enable the advanced root features and all will be fine. If you have no root unfortunately you are stuck without Partial Wakelocks as Google has made changes to prevent apps to access that data (see also here)
3. Q:Why installing BBS as a system app as everything works with root?
Deprecated: BBS does not require the system app anymore
A: Starting with Kikat BBS has 3 modes: without root a limited mode provides a minimal set of stats. With root the set of stats is complete but some stats (other, partial wakelocks, processes) still use a workaround. Finally with the system app BBS is fully featured without any workaround.
4. Q:I have high wlan_rx kernel wakelock. What is it and how to proceed?
A: This kernel wakelock is caused by Wifi waking up your device. To avoid it you should turn your Wifi off if not using it, use a tool to control your Wifi state or try to find and remove the cause. More here
5. Q: Google Maps is causing a lot of overhead. Must I freeze it?
A: no, Karpfenhai wrote step-by-step instructions on how to configure autostarts and the location service to avoid that
6. Q: Are you aware of the bug in BBS causing SuperUser to ask for su-permissions over and over again
A: As you said, SuperUser is asking over and over again, it's no BBS bug as BBS only requests su rights. More here
7. Q: BBS shows "no ref since unplugged"
A: Starting from 1.9 is is mandatory to plug/unplug after boot to get a "since unplugged" reference to be created. Starting from 1.10 there is anew reference "since boot" and a preference to fall back to that reference if no other is available.
8. Q: Why can't you just skip deleting the references at boot?
A: If I could I would. In a nutshell: BBS is a passive monitoring tool; this means it does not cause any overhead collecting data but compares snapshots. Now the disadvantage of this is that it makes no sense to compare values of counters between two references (e.g. "since unplugged" and "current") if the counters were reset in between. In fact that would potentially cause negative values, in every case wrong values.
9. Q: But is used to work before. Why did you change it?
A: It didn't work, you just didn't notice. The kernel and Android reset their counters at boot. That means that there is no way to compare counters from before the boot with counters from after.
10. Q: What do the widget colors / graphics mean?
A (new round widgets): the legend is displayed if you resize the widget
A (legacy widgets): For the large widget it's pretty simple. The colors represent the values "Since" (blue), "Deep sleep" (green), "Awake" (yellow), "Screen on" (white), "Kernel wakelocks" (magenta), "Partial wakelocks" (cyan). The 100% is the max of those values.
For the small widget see here
11. Q: Where are the dumpfile and logcat saved / how are the files named?
A: Both files are saved to /sdcard, their names are BetterBatteryStats-.txt and logcat-.txt where timestamp is of the format "yyyy-MM-dd_HHmmssSSS" (starting from 1.12 there is an option in advanced prefs to save those files to the private directory /sdcard/Android/com.asksven.betterbatterystats/files).
12. Q: Are you aware of the fact that BBS does not work properly for secondary users (Android 4.2)?
A: BBS works fine for secondary users as long as you don't enable root features. The reason is not BBS but the lack of support of the multiuser feature in the superuser/supersu version you are using.
13. Q: What is *overflow*?
*overflow* is a sign that one stat counter was overrun. This may happen if you have not boote your phone since long or if some wakeup/wakelock is very frequent. The only way to see what is hidden behind *overflow* is to reboot and take a fresh reading.
14. Q: Why is 'screen off' reference not being created?
A: You have to enable the watchdog for that reference to be created
15. Q: Even after plugging/unplugging my phone no reference except 'boot' is shown
A: something is preventing the unplug event to be passed to BBS. You should check for tools like greenify or stamina mode that mask such events and make sure that BBS is whitelisted. On newer Android versions please also make sure that BBS is not "optimized" by Android, under "Settings - Battery Optimization"
16. Q: What is the watchdog and how does it work?
A: The wachdog is a feature to help you in analysing when happens when screen is off. When the watchdog is turned on a reference 'screen off' is created. You can also configure the watchdog to create a reference 'screen on'. Opionally the watchdog will notify you when screen is turned on and the awake ratio was bigger that the configured threshold. In order to avoid too much overhead in processing a threshold can be set to disable the computing for short screen off times.
17. Q: my logcat is empty and says "Unable to open log device '/dev/log/main': No such file or directory"
A: Check if you have a custom kernel that turns off logging. If not some file permissions may be broken: use the repair permissions function from your recovery
18. Q: How can I get rid of GSF wakelocks
A: GSF (google service framework) can not be avoided and in no case it should be frozen. Here are some settings that can help reducing the overhead.
19. Q: The other stat is wrong. It shows "No data connection" and "No or unknown signal" while was online with Wifi all the time
A: "No data connection" and "No or unknown signal" refer to your cell data (2G/3G) service. As you have had Wifi on for some time the cell data was turned off, consistent to what the stats say: work as designed
20. Q: I can not install BBS as a system app. What can I do.
A: BBS does not require the system app anymore
A: If you are on a version older than 4.4 you don't need to install BBS as a system app. If you are on 4.4+ you should first try the in app installer. If for some reason it fails you can use the CWM scripts attached to install / uninstall BBS as a system app
21. Q: I am suffering from a high NLPWakelock time. Is there something I can do about it?
A: Here's a good summary of what NLP is and how it can be positively impacted (thanks to @Perseus71)
22. Q: On CM12 based ROMs the launcher crashes when placing a widget. When will this be fixed?
A: I can not find anything wrong with BBS code and the crash occurs in the launcher, not in BBS. After spending quite some time trying to understand the problem I must conclude that the problem is with CM12 (other ROMs on Lollipop do not have this problem)
23. Q: I can not or do not want to root my devices but would like to use BBS to gain insight. Can this be done?
A: The answer used to be "no" but this has now changed. See post #4 for a detailed description on how to proceed.
24. Q: I can not get BBS to work. How should I proceed to find out the cause
BBS has no dependency to any root-tool and does not require root to work, it only requires specific permissions that can be granted by:
- using ADB as described in the FAQ
- letting the app grant itself the permission if root is available
25. Q: BBS Shows a permanent notification. Can I remove it?
The notification is due to the android app model having changed and now requiring apps that run in the background to show themselves. I have put the "background app" notification into a separate channel named "BBS Event Processing" so you can disable it if it bugs you: no other vital notification will be send to that channel
26. Q: What is this popup saying "Detected problems with API compatibility"?
For Android 9.0 Pie users getting the "Detected problems with API compatibility (visit g.co/dev/appcompat for more info)" popup error please see this post.
When diagnosing / analysing there are a few important things to know:
- the app (advanced settings) shows you whether the permissions were granted or not
- when checking if any acition had a positive result you should always use raw stats as the default view does a diff between two snapshots, i.e. if one snapshot is missing it may show no results
- logcat may give you some info about what is going wrong, e.g. the app not being able to contact the battery_info service
Running BBS on non-rooted devices
This is not an april's fool joke!
TLDR;
This knowledge article describes a method to enable BBS to run on unrooted devices on Android versions starting with Kitkat (on previous versions root is not a must). More about that here: http://better.asksven.org/bbs-systemapp/
As it requires a few tools to be installed on your pc it requires some basic knowledge, understanding, and the readiness to tinker and to learn.
What is describe here is a method to inject according permissions required to access the battery stats using the android debugging bridge to issue commands from the pc. This will allow to grant the needed permissions, that will survive reboots.
Credits
All credits for this brilliant approach go to @Looki75. My special thanks go to @Perseus as well as to the supportive bbs community in general for their tenacity, feedback and constant support and feedback.
Details
Congrats, you made it until here, let's get started.
We will go through all steps of the setup. If you are aware of the tools and techniques please feel free to jump to the appropriate section.
The initial post on this topic as well as the basic steps (for advanced users) can be found in this original post: http://forum.xda-developers.com/showpost.php?p=67441059&postcount=30632
1. Install necessary ADB drivers and exe on PC
This may be the tricky part but we can leverage some experience in that area. A good read:
The 15 second adb installer
2. Enable USB debugging on phone's developer options
This is pretty straight forward:
http://www.howtogeek.com/129728/how...menu-and-enable-usb-debugging-on-android-4.2/
Congratulations, your are now a developer!
3. Connect phone to PC
The easiest part: connect the usb cable on both ends. When you connect the phone to PC on ADB, some models will throw a authorization message on phone Screen asking if you authorize this pc to access the phone. Its a Android M Thing.
4. Run the commands:
This requires some explanations and some hints about how to check what may have gone wrong.
Once you have connected your phone via usb start by unlocking your phone and by issuing the command: adb devices
If it came back with a Device name instead of waiting for device or "no permissions" (on linux), then you know its safe to go ahead with the real command. Its this adb devices that also triggers the Authorize pc command.
If the "adb devices" command does not return a positive result you may want to look into:
a) on windows the proper installation of the special usb drivers
b) on linux you may need to add some udev rules. This may help: http://stackoverflow.com/questions/32151114/adb-is-not-detecting-my-android-device-on-ubuntu
If the "adb devices" returned a positive result is is safe to proceed:
adb -d shell pm grant com.asksven.betterbatterystats_xdaedition android.permission.BATTERY_STATS
Adapt the package name depending on which version - XDA or PlayStore (without "_xdaedition" extension) - you have installed
Update: starting with 2.3-150 two new permissions are required to support alarms fully on unrooted devices
adb -d shell pm grant com.asksven.betterbatterystats_xdaedition android.permission.BATTERY_STATS
adb -d shell pm grant com.asksven.betterbatterystats_xdaedition android.permission.DUMP
adb -d shell pm grant com.asksven.betterbatterystats_xdaedition android.permission.PACKAGE_USAGE_STATS (needed starting on Lolipop)
Update: starting with SDK28 (Android 11) google has restricted access to the private APIs that BBS uses. Google is fuzzy about the why and arguments in terms of privacy and security.
You will need to run the following (assuming your device is not rooted, otherwise BBS takes care of that for you) for BBS to get access to these APIs:
SDK28 (Android Pie / 9)
adb -d shell settings put global hidden_api_policy_pre_p_apps 1
adb -d shell settings put global hidden_api_policy_p_apps 1
SDK29 (Android 10 and following)
adb -d shell settings put global hidden_api_policy 1
Note: a restart may be required after applying the global settings...
See also here
Voila... congrats for your tenacity, you have earned it!
Ref, Hints and blacklist
Litterature
Article from the Android PDK about Power Management: http://www.netmite.com/android/mydr...s/power_management.html#androidPowerWakeLocks
Other useful tools
The default battery usage (Gingerbread): Settings -> About Phone -> Battery Usage
The most interesting data is shown when clicking on the graph (bars below the graph). Unjustified "awake" times when display is off is an indicator for rogue apps doing stuff in the background when you think your phone is asleep
Battery Monitor Widget
Has a great stat on battery drain over time. I use this tool regularly after leaving my phone alone for 1/2 hour to check how the battery drain looks like against my benchmark of 2-10 mAh average (optimal for my SGS2).
[android backup service]
(http://code.google.com/android/backup/index.html). It is a service that offers cloud backup/restore of your settings and offers an API for other apps to do the same (http://developer.android.com/guide/t...ta/backup.html).
You can turn it off (but will lose the automatic backup) under Setting -> Privacy ->Back up my data.
Backups are useful though but no need to do it in the cloud, I'd recommend scheduling a regular backup using titanium instead (that's my setting).
[DataTracker-FD] is fast dormancy. Find the 'secret' codes for your device to turn FD off. *#*#9900#*#* on an SGSII. (contrib. by nobnut)
[syncmanagerhandlesyncalarm] That service is documented here (http://www.kiwidoc.com/java/l/x/andr.../c/SyncManager) and is responsible for updating the accounts you have under Settings -> Accounts and Sync. High values may come from bad settings (sync too often, huge amounts of data) or poorly written providers.
[reserved for misbehaving apps]
Been looking for something like this since I installed a GB ROM!
So, basically I install this app, and then Spare Parts should work as it normally did? (or dial *#*#4636#*#*, or whatever that is)
thebeardedchild said:
Been looking for something like this since I installed a GB ROM!
So, basically I install this app, and then Spare Parts should work as it normally did? (or dial *#*#4636#*#*, or whatever that is)
Click to expand...
Click to collapse
No Spare Parts won't be of any help as BetterBatteryStats does not replace com.android.settings.battery_history.BatteryHistory (called by Spare Parts). Installing the app you will get a new icon and will get the stats when starting it
Excellent work! Just what Gingerbread needs. The very best of luck with the app!
Thank you.
Sent from my Motorola StarTac using Voodoo
chamonix said:
No Spare Parts won't be of any help as BetterBatteryStats does not replace com.android.settings.battery_history.BatteryHistory (called by Spare Parts). Installing the app you will get a new icon and will get the stats when starting it
Click to expand...
Click to collapse
Ah, I see, so I use this app instead of Spare Parts. Well awesome, thanks for the clarification, and the useful app!
This is great. What about mimicking the part in spare parts that showed percentage running time? That's valuable info too. I've seen many times where running time was pegged at 100 yet there wewettewere no partial wake locks.
lexluthor said:
This is great. What about mimicking the part in spare parts that showed percentage running time? That's valuable info too. I've seen many times where running time was pegged at 100 yet there wewettewere no partial wake locks.
Click to expand...
Click to collapse
I'd be happy to look into that. Can you give me the exact name of the option/dialog you are missing to make sure we talk about the same thing?
nobnut said:
Excellent work! Just what Gingerbread needs. The very best of luck with the app!
Thank you.
Sent from my Motorola StarTac using Voodoo
Click to expand...
Click to collapse
Thank you for the support and for the testing!
Bug in Network Usage stat
nobnut has reported incomplete stats for network usage (list does not show all apps that have generating network traffic). I reproduced this on Gingerbread where my phone only shows google maps traffic. I could reproduce this on HSDPA as well as on Wifi. The figures that are shown seem ok and increases when I use Maps.
Now interesting is that this problem can not be reproduced on Froyo where reported apps concur with the Network stats from Spare Parts.
As the stat is incomplete I'll remove it from the app till I can find a solution.
When I noticed this, it occurred to me that perhaps user apps were not reporting their data, whereas the system apps were. I can get readings for a number of apps, they are all system apps however.
This may just be concidence.
New version 0.4.0 is out. See second post for download link and changelog
Your blog link still reads 0.3.1
thebeardedchild said:
Ah, I see, so I use this app instead of Spare Parts. Well awesome, thanks for the clarification, and the useful app!
Click to expand...
Click to collapse
Not sure since I can't get there on spare parts.
It was in battery history and I think it was the default that came up that said "running" and it gives a percent of the time the phone is running.
I've seen that pegged at 100% with no wake locks, so that still indicated a problem.
Very cool, thank you for your efforts. Downloaded and following on twitter/subscribed to the thread.
nobnut said:
Your blog link still reads 0.3.1
Click to expand...
Click to collapse
oops, fixed, thank you
lexluthor said:
Not sure since I can't get there on spare parts.
It was in battery history and I think it was the default that came up that said "running" and it gives a percent of the time the phone is running.
I've seen that pegged at 100% with no wake locks, so that still indicated a problem.
Click to expand...
Click to collapse
Ok here's what I have on Froyo going to Spare Parts:
. Battery Information: useless
- Usage stats: it's an poorly formated list of apps with the launch count and CPU time
- Battery History: a list of graphable buttons with following stats: Other usage, Partial Wake Usage, Sensor Usage, GPD Usage, Network Usage, CPU Usage. Each shows a list of apps/processes with blue/red bars.
Maybe you are talking about "Other usages". Here I see % running, %screen on, %wifi on

NoRefresh enabler

Hi,
I am trying to put a code together to control the refresh behavior of the e-ink screen. The final goal is to have a drop-in library for app developers to help making their app more e-ink friendly.
The code works already for the PRS-T1, but needs a different driver for the Nook Touch (N2EpdController included).
My one and only beta tester gets the famous "There is a problem parsing the package" error. Pls find enclosed the sources.
I would be grateful if someone could fix possible Eclipse setting or other errors.
Hi,
I have some interest in adapting apps to the eink screen, so I will try to help with this. Unfortunately, I cannot post in the dev forums yet.
When you get error installing apps via android UI, it is useful to do via "adb install" to be able to know the error cause. The message was "INSTALL_FAILED_OLDER_SDK", which I solved by lowering the android:minSdkVersion parameter in Manifest. Then, the app installed and ran fine, but didn't do the desired effect yet. I will check the code now...
---------- Post added at 02:41 AM ---------- Previous post was at 01:53 AM ----------
I see that you're trying to use enterA2Mode() for the nook (btw, there is a typo at NoRefreshEnablerActivity.java:29, it should read EINK_NOOK). I've been playing around with this some time ago when I started developing a fast e-ink drawing app for the NST, you can see it here: https://github.com/marspeople/E-Paper (WIP).
With few testing I've done, I guess the 1-bit mode (A2) setting is not applied globally: it should take effect only in the View from which it is called. I haven't investigated further to try to use it globally.
Hi marspeople,
Thanks for pointing out the type, it should read
} else if (DeviceInfo.EINK_NOOK)
Regarding the global value of mode setting. From what I understand, A2 is a permanent mode, so whatever function or app is setting the updatemode, it is kept. With the PRS-T1, it is reset by calling any stock (Sony) app. For the Nook I don't know..
Good luck in compiling, hopefully we come to a version which works on both devices. Then I can proceed to dynamically change the updatemode within an app.
Yes, the A2 mode is kept until any process resets the EPD. Using logcat, I noticed several epd_reset_region messages appearing automatically when I close your app to go back to the launcher. It seems the system overrides the EPD setting, making impossible to use A2 system-wide (at least by this method).
However, if you want A2 just for an app, calling enterA2mode() will probably work, as I used in my own app above.
Can you send me your apk?
salsichad2 said:
Can you send me your apk?
Click to expand...
Click to collapse
You mean the apk for "NoRefresh" or my drawing app?
Hi marspeople,
I would be most interested to know why the initial source code does compile ok, works on the PRS-T1 and does not install on the Nook Touch + the fixes.
With this knowledge I can write either an app to set refresh modes or within apps.
Did you succeed to compile and install on Nook?
Hi again,
in your N2EpdController.java
Code:
83: mtSetRegion.invoke(null, "aarddict", enumsRegion[region], regionParams, enumsMode[mode]);
I would like to replace the hardcoded "aarddict" by something dynamic.
What would be the correct function to infer the wanted name?
Code:
activity.class.getName()
this.getClass().toString()
.. ?
bardo8430 said:
Hi marspeople,
I would be most interested to know why the initial source code does compile ok, works on the PRS-T1 and does not install on the Nook Touch + the fixes.
With this knowledge I can write either an app to set refresh modes or within apps.
Did you succeed to compile and install on Nook?
Click to expand...
Click to collapse
Yes, sorry about the confusion, but I managed to do it, despite the A2 mode didn't work. What I did was just edit the AndroidManifest.xml, changing the android:minSdkVersion parameter to 7 (since the NST runs Android 2.1).
Good luck finding out how to set A2 mode permanently. I guess you don't have a Nook, so feel free to ask me for testing purposes.
Since the Nook A2 mode seems to be overridden when switching foreground activity, I've tried another approach with a background service which toggles A2 mode when requested by user. This way, the foreground activity isn't switched and "fast refreshing" mode works (until you change activity).
This fast refresh mode (called A2) is only possible because it uses only 1-bit depth, i.e, just black on white, meaning you can't see grayscale pictures but it's good enough for black text on white background and scrolling. I have not "created it", it is built-in from the device (you can test using the stock reader, it is activated when holding a page button). What I implemented is a way to activate and deactivate it at user will from inside any app.
Thanks to dairyknight for his N2EpdController class, which made this possible.
Thanks to bardo8430 for bringing the idea.
Thanks to AndroSS source code for screenshots used in automatic contrast.
Changelog:
01/Mar: Now when you launch the app and it is already running, it will activate NoRefresh mode. So you can also use an activation shortcut to the app using NookTouchTools (i.e. B&N's book icon at top left corner).
02/Mar: Improve activation shortcut to perform toggle between modes. Tap gestures aren't needed anymore (use "-noGestures" apk version if you don't want them).
04/Mar: Got rid of initial ghosting by redrawing the screen after activating A2.
04/Mar (2): Minor improvement of removing ghosting at screen edges.
12/Mar (Beta): Now you can adjust contrast in A2 mode. Images shouldn't be dark or black anymore if you raise the contrast a bit.
22/May: Completely redesigned version 2.0:
- Several options can be customized via settings screen.
- NoRefresh can be toggled by manual app shortcut, tap gestures or automatically according to screen animation (new).
- New App Whitelist to avoid unwanted activation in specific apps (except for manual mode).
- Background service can be launched at boot.
- Small improvements and tweaks.
- Custom app icon (finally )
06/Jun: Fix crash on empty whitelist
08/Jul: (Version 2.1)
- Automatic contrast when activating NoRefresh, according to total "brightness" of the screen (simple algorithm). This should ask you for root permission.
- Also supports manual setting in specific situations (customizable).
- Fix possible crash at startup.
26/Jul: (Version 2.2)
- Fix contrast setting behaviour
06/Dec:
- Alternative version with fixed compatibility for FW 1.2.0 available at https://github.com/marspeople/NoRefreshToggle/downloads
First Video: http://youtu.be/6pBPsyno5PY
Other Video: http://youtu.be/kBbl6egyPsQ
Another demo: http://youtu.be/5b7JjllImjM
Repository: https://github.com/marspeople/NoRefreshToggle
Great to see that it works on the Nook! Good job.
When I try to compile on Eclipse, I have to remove the below Override:
//@Override
public boolean onTouch(View v, MotionEvent event) {
otherwise I get an error: The method onTouch(View, MotionEvent) of type A2Service must override a superclass method
When I compile with this mod and run the app, nothing happens after using your gestures. Except that I tap on other icons which then try to launch other apps.
Should NoRefreshToggle keep the focus?
I have a suspicion: The PRS-T1 needs to call a function of the Sony library with extended parameters to pass the updatemode. ANY function carrying the mUpdateMode parameter would do - but it must be called. Which might be the problem here. In the used EinkListView.java, a lot of "injection" functions like below are defined.
Code:
@Override
public void scrollTo(int x, int y) {
try {
Method invalidateMethod = super.getClass().getMethod("scrollTo",
int.class, int.class, int.class);
invalidateMethod.invoke(this, x, y , mUpdateMode);
} catch(Exception e) {
e.printStackTrace();
}
But your code has neither a Listview, nor would any injection function trigger. I am afraid you would have to make the app use a ListView (or WebView).
Can you?
bardo8430 said:
Great to see that it works on the Nook! Good job.
When I try to compile on Eclipse, I have to remove the below Override:
//@Override
public boolean onTouch(View v, MotionEvent event) {
otherwise I get an error: The method onTouch(View, MotionEvent) of type A2Service must override a superclass method
When I compile with this mod and run the app, nothing happens after using your gestures. Except that I tap on other icons which then try to launch other apps.
Should NoRefreshToggle keep the focus?
Click to expand...
Click to collapse
Well, I noticed that problem of accidentally tapping unwanted widgets, I would recommend tapping on a free area of the screen. I could use an overlay button, but it would occasionally get in the way too. What do you mean by "keep the focus"?
---------- Post added at 09:13 PM ---------- Previous post was at 09:05 PM ----------
bardo8430 said:
I have a suspicion: The PRS-T1 needs to call a function of the Sony library with extended parameters to pass the updatemode. ANY function carrying the mUpdateMode parameter would do - but it must be called. Which might be the problem here. In the used EinkListView.java, a lot of "injection" functions like below are defined.
Code:
@Override
public void scrollTo(int x, int y) {
try {
Method invalidateMethod = super.getClass().getMethod("scrollTo",
int.class, int.class, int.class);
invalidateMethod.invoke(this, x, y , mUpdateMode);
} catch(Exception e) {
e.printStackTrace();
}
But your code has neither a Listview, nor would any injection function trigger. I am afraid you would have to make the app use a ListView (or WebView).
Can you?
Click to expand...
Click to collapse
Well, to capture touch events I've used a dummy View which is added to an overlay (see A2Service.java:43). Despite being an android Service instead of Activity, maybe you can instantiate your ListView there and hopefully it will work.
Thanks for the hint on the dummy view, will try.
"keep the focus"?: window manager speak, I mean that a tap stays within your app and does not act on the icons below.
bardo8430 said:
Thanks for the hint on the dummy view, will try.
"keep the focus"?: window manager speak, I mean that a tap stays within your app and does not act on the icons below.
Click to expand...
Click to collapse
Since I'm using a transparent overlay, I have to let touch events pass through, otherwise only my app would see them.
PS: I've added a demo video at a previous post.
I've been trying to improve the functionality of the app by changing from this manual toggle approach to something like: fast mode is triggered (a bit after) when user starts dragging his finger on the screen and restored when released.
However, I've been searching how to do this with no success so far. The invisible overlay that detects touch events currently is only able to capture MotionEvent.ACTION_OUTSIDE event type, which is useful to detect a tap, but can't deal with a drag. I also need that the drag is passed normally to the app below (to perform scrolling or whatever).
I've found this page (http://stackoverflow.com/questions/8073803/android-multi-touch-and-type-system-overlay) in which is proposed a solution that can detect a drag but can't pass it to the app below.
The code is now here: https://github.com/marspeople/NoRefreshToggle . I would appreciate any help from developers.
Maybe it can be run every 1 second when screen is on. I mean nook is not locked. I don't think that changing one parameter would eat battery. Is it worth a try?
Hi marspeople,
thanks again for taking this. My initial intention was to help app developers with no e-ink experience to easily adapt their code. Doing these things inside an app is much easier but needs access to the source.
See the related question on stackoverflow:
http://stackoverflow.com/questions/9391710/adapt-scrolling-swiping-to-e-ink-screens
The external app was used as a mere demonstrator to have it work on the NST and PRS-T1. Good to have a repository for it now.
marspeople said:
Ok, I think I've got it.
Since the Nook A2 mode seems to be overridden when switching foreground activity, I've tried another approach with a background service which toggles A2 mode when requested by user via a touch gesture. This way, the foreground activity isn't switched and "fast refreshing" mode works (until you change activity).
The activation gestures I'm currently using (unfortunately, it seems you can't use hardware keys using this approach) are:
- 4 "downward-right" taps (each tap must be done to the right and below the previous one) to activate (A2 mode)
- 4 "upward-left" taps to deactivate (Normal mode)
Video: http://youtu.be/6pBPsyno5PY
Here is the source code and a apk. bardo8430, I believe it would be easy to port this to the PRS-T1.
Click to expand...
Click to collapse
Noob question.
So I just install the apk and run it and I have Norefresh.
dark_hawk said:
Noob question.
So I just install the apk and run it and I have Norefresh.
Click to expand...
Click to collapse
yes, just open the norefresh app, and like the youtube video tap the screen from top left to bottom right 4 point
but i think the trade off is the screen go black&white with no grayscale (at lease for me)

[Guide] Fix for blue screen tint

In my opinion, the screen on the Moto G4 Play is pretty decent for a budget device -- aside from the bluish/cool hue of the color reproduction. This is due to the white point of the display being set to 8653K, far from the ideal of 6500K (Velasco, 2016). It could possibly be fixed with a software-based recalibration from Moto/Lenovo (I'm not holding my breath), but there are a couple of things that we can do to make it a little better.
If you are using CyanogenMod you have the ability to adjust the colors under display settings to take some of the blue and green out. This is probably the easiest method.
If you are running a stock ROM the options are more limited, especially for anybody with a variant that does not support unlocking the bootloader and rooting. You might be out of luck. The following steps are for anybody running the stock ROM with root. If you have not rooted or modified your phone yet please read the warnings on the respective threads.
1. The Kernel
You will need a custom kernel that supports color correction, specifically what you want to look for is KCAL MDP5 color control. The squid2 kernel supports this feature, and there may be others as well. http://forum.xda-developers.com/g4-play/development/kernel-squid-kernel-moto-g4-play-t3496641 Remember to make a nandroid backup of your boot partition before installing any kernel or superuser software.
2. The Apps
As far as I know you need root access to use any of the software that allows you to do color correction. To install SuperSu it currently needs to be told to use systemless root on our phone. This can be forced by creating a hidden file called .supersu in /data with contents "SYSTEMLESS=true" (SuperSU Beta, 2016). You can do this in TWRP / Advanced / Terminal by entering the command "echo SYSTEMLESS=true>>/data/.supersu" There is also a flashable zip here in the forums that can do this. Just flash the SuperSU installer after this. There are many programs that can make the actual color corrections. An easy to use one is available from xda developer savoca here http://forum.xda-developers.com/android/software-hacking/dev-kcal-advanced-color-control-t3032080 Kernel Adiutor available on the Play Store can also be used https://play.google.com/store/apps/details?id=com.grarak.kerneladiutor&hl=en
3. The Settings
In Settings / Display / Color Mode I set the color profile to Standard. In the Color Control app from savoca I left all settings at their default values except for setting green to 248 and blue to 237. This results in a more natural white point in my opinion. If anybody else finds settings that work well please share them in this thread.
References​
Velasco, J. (2016). Moto G4 Play Review. Retrieved from http://www.androidauthority.com/moto-g4-play-review-716208/
Chainfire. (2016). SuperSU BETA. Retrieved from http://forum.xda-developers.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133/page408
Settings for CM
Color settings for CyanogenMod
If using LiveDisplay change the day color temperature to 5800k, otherwise in color correction set R, G, B to 100, 98, and 90.

[APP][5.0+]OBD2 Plugin for Android Auto - Use Torque with AndroidAuto

Update 30.11.2022
End of life and open source.
Due to lots of changes both in Android and in my life, I do not have the possibility to maintain / update the code any further, therefore I've decided to open source.
Code is accessible: https://github.com/borconi/obd2aa
I will like to thank all of those who supported this project.
App Requirement
Torque Pro
OBD2 Reader
Android Auto compatible headunit or at least a copy of the Headunit Reloaded App (see signature).
This app will have limited functionality if you are using Android Auto on a your phone, the only functions you will be able to use is to see are notification about the speed cameras and street card!
Gauges and torque data will NOT work!
Previous XDA purchases can be reclaimed here: https://www.b3itlabs.com/download.php
How to purchase:
Visit: https://www.b3itlabs.com/prod.php?id=2
Instructions on how to get it running:
Option 1 - Will work on any phone & car/headunit combination, however the following features won't: - AutoPlay Music, 6 Tap limit remover, DPI change
After installing the app from XDA Labs, sign up for beta testing here: https://play.google.com/apps/testing/uk.co.boconi.emil.obd2aa and update the app
Once app is updated, make sure you disable auto-update in PlayStore then please uninstall it and reinstall it from XDA Labs.
With your screen unlocked, plug in the phone to the car, when prompted which app to use make sure you select "Android Auto"
Option 2 - Might NOT work on some device combination (for sure it won't work on Xiaomi phones), but if this method works all functions of the app are available
Install
Make sure you do not have any other 3rd party app Android Auto app installed.
Open the app and hopefully it will be quite self explanatory on how to set it up (choose colours, set gauge number, etc)
Open Android Auto (on the phone), go to About, tap the "About Android Auto" header 10 times, once you are a developer from the 3 dotted right corner menu select "Start Headunit Server" (ROOT users can skip this step!)
Close Android Auto
MAKE SURE YOUR SCREEN IS UNLOCKED and connect to the car, when prompted which app to use select "OBD2AA" and always (this needs to be done one time only) - If you are a HUR user select Android Auto and always! (If you do not see the prompt to chose, please go to settings -> apps -> all apps -> Google Play Services -> Clear Defaults and then try again)
Select the last tab on the right, by pressing it again you should see an app selector and choose OBD2AA
Give it a bit of time to start pulling the data from Torque.
Change log
Version 3.2 and 3.3 released 04/11/2018
Fix "drunk" map effect on Sync 3 units
Fixed rooted devices not being able to start headunit server.
Added option to change DPI for your screen!
Added option to auto play music on start
Added option to select default start screen.
Version 3.1 releases 26/08/2018
Compatibility fix for Pie devices.
Tap limit remover now working on all device
Tap limit remover allows Maps to be searchable even when driving.
Can be used for those who have problem with the parking brake wire.
Freeze issues fixes.
Important notes
Version 3.0 releases 05/07/2018
Compatibility fix for AA 3.0 and above.
Added option for overriding 6 tap limits
Added option for Bluetooth Audio output.
Important notes
Thanks to @slash_m_a_x for the support offered on this.
- Some users have reported choppy audio when using the app, this will mainly be due to the speed of the phone, the buffer on the car/headunit and other factors which are out of my control, if that is the case and you cannot use the app please feel free to contact me for a refund.
- Bluetooth Audio output might not work on all devices, it does depend how the car/headunit handles the Bluetooth. There will be devices which completely disable A2DP/Bluetooth capabilities of the car when Android Auto is running. In this case all the sound will be heard from the phone speaker rather then the car speakers.
- Tap limit will be disabled only for cars/headunits which are equipped with a GPS.
- In rare cases it can happen that after unplugging the phone from the headunit you will see a message which says that you are still connected to Android Auto, simply Force Stop the Google Play Services.
- You always need to make sure that Headunit Server is running on the phone (unless you have root), if the icon bothers you simply hide it.
Change log
Version 2.0 releases 17/01/2018
Added new layout option
Added styled gauged
Option for custom background on each gauge.
Option for custom needle on each gauge
Removed integration for CamSam/Blitzer.de (fully integrated now)
Possibility to change needle color
Possibility to adjust arch (indent, position, length) when using custom bg
Separated speed camera settings
Option to only download speed cam db over Wifi
Fixes for min/max value
Speed camera warnings over car speaker (Thanks @martoreto for the how-to)
Street info card
Added French translation (Credit to @fbike for doing the translation)
Added Danish (Credit to @Gunde for doing the translation)
Added Finnish (Credit to @Pyrres for doing the translation)
Added Spanish (Credit to @madabase for doing the translation)
Added Italian (Credit to @ilgaspa for doing the translation)
Version 1.6a - releases 03/10/2017
Fixed negative input for min/max values
Code cleanup
Added Greek language (credit to @sosimple for translating)
Version 1.6 - releases 29/09/2017
Fixes for custom PIDS
Fixes on Graphics rendering.
Fixed overlapping text
Fixed PSI/BAR conversion
Enhanced the gauge style.
Different approach for torque data pulling.
Moved to service should start work automatically when connected to the car
Added Supports PID alarms from Torque.
Added Toggle/Collapse layout for Pid settings.
Added Preview button with random data
Added Option to toggle units display
Added notification cleanup on exit
Added translation for DE,HU,RO (Credit to @FormelLMS for DE)
Added import/export setting option
Added option for colored text
Added TPMS option/screen
Added option to override car's headlights based on day/night
Added warning screen if nothing is configured to prevent black screen with no information.
Added more settings and move them to separate Settings options.
Added customizable background
Added search for PIDs
Added Support for Heads-Up notification
Added Speed camera warnings (powered by CamSam Plus)
Supported settings/Features:
3 x Colors for each gauge
Text color
Toggle needle, arch,units,scale,decimal and text for each gauge.
Variable number or gauges ( 1 - 15 )
Set warning limit for each gauge (percentage). This will be calculated relative to the given PID max value which is retrieved from Torque at runtime.
Possibility to set gauge in reverse mode. (example fuel tank)
Units will be converted automatically based on your Preferences in Torque
TPMS Screen (if you have PID's for TPMS data)
Possibility to use custom background/needle for each gauge
Low Fuel warning
Warm Engine warning
Speed Camera Heads Up Warning
Option to Overwrite Headlights state based on calculated sunset/sunrise
How to use it?
Open app and select each PID you want to display on your screen, adjust the number or gauges you want to see adjust the preference for each PID. If you want to use custom background/needle and interested on how to, please read HERE
Locking Pid values
On some PID's Torque reports wrong min/max values, by default if while using the application a reported value is higher/lower than the initially reported range, the app will adjust the range to the new values. However in some cases this is not desired and you will like to specify manually what is the min and max value for the give PID. In this case, simple edit the minimum/maximum for the pid and they will become locked, meaning the app won't make any adjustments.
By editing, it means you have to change the min or max value, the lock is triggered by the first keypress on this input fields.
The lock will be automatically removed when you select a different PID for the same gauge.
Preferences menu
Alternative pulling - Only enable this option if you have difficulties getting gauges updated, it uses an old deprecated method of obtaining data so should not really be used.
Enable debugging - Only enable it if you have problems with the app and I requested you to collect a bug report, otherwise it will spam the logs for no reason.
Automatically start Torque on Android Auto - Nothing to explain here
Launch FartKontrol on start - launches a Danish Speed Camera app (useless outside Denmark)
Custom Background (any background you will like to use instead of the black color)
Demo - When enabled random data is generated for the PID's just to see how things will look (in case you do not have an OBD2 adapter), so don't enable it.
Pid Alarms section. You can set up a low level fuel warning (displayed as a heads up notification) and a notification when the engine is warmed up. There a several PID options for both of this, pretty self explanatory.
TPMS Settings
- You set up the 4 PID's for TPMS, this will be used to display the tyre pressure values on the TPMS screen inside Android Auto
Speed Camera
Show current street card - Displays information about current street (name and speed limit if know). This information is updated once in 5 seconds and at a minimum distance of 200 meters so it's not 100% accurate it's more for general information.
Enable speed camera warnings - This will enable the app to display speed camera warning when driving, like any app which does this it relies on a database, which means it does NOT guarantee that it will warn you of all the cameras, and it might also produce false warnings. All options are pretty self explanatory.
Export & Import
- Allows you to export your current app configuration file which can later be imported (grate way of saving time of re-doing everything) after a clean install or so. The format use for Export & Import is JSON so if you want you can manually edit/adjust the values. Please see following post for more details about the sturcture/value/meanings
Permissions
Read notification permission - Only required so the app can read the notifications from CamSam and display them on AA scren
Locations - Only required if you want the app to overwrite the day/night theme based on sunset/sunrise
Storage - Only needed if you want to use your personal image as a background and/or planning to import/export settings
Can I create my own layout for the gauges?
- Yes, see instructions below:
Here is an example of the XML structure required, once you created the XML please send it over by email to [email protected] and I will include it in the next build.
Code:
<FrameLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:tag="wrapper_layout">
<!-- Left column -->
<View
android:layout_width="226dp"
android:layout_height="226dp"
android:layout_gravity="center_vertical|start"
android:tag="gauge_2"
/>
<!-- Middle column -->
<View
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_gravity="center"
android:tag="gauge_1" />
<!-- right column -->
<View
android:layout_width="226dp"
android:layout_height="226dp"
android:layout_gravity="center_vertical|end"
android:tag="gauge_3" />
</FrameLayout>
Important
Each view must contain a tag, which is formated like in the example, where the number corresponds to the Gauge number from the setting screen.
The layout which wraps everything together must have a tag called: wrapper_layout
You are free to use any Layout you want, except ScrollView.
How to produce bug report?
Step 1 you need to enabled debugging in OBD2AA app, then follow this instruction set:
2. Enabling Developer Mode
Open Settings > About phone.
Scroll down to the Build number.
Tap the Build number 7 times in quick succession until "You're now a developer" appears.
Return to the Settings menu and select Developer options.
At the top of the screen, make sure 'Developer options' is set to On (green).
Scroll down to Debugging and enable both USB debugging and Bug Report Shortcut on (green).
Tab on Logger buffer sizes: Default setting is 256K. Select 16M to help capture more information for debugging. Of note, it can affect the apps performance especially with lower spec phone, so change it back after you have finished submitting bug reports.
3. Capturing a Bug Report
It's very important to do this right after you experience the issue again, so your device can log at least one occurrence of the issue.
Hold the Power button down until the menu appears.
Select Take bug report. and wait for the device to capture the bug report.
Tap the 'Bug report captured' notification when it appears.
Share the bug report. (I recommend to email it to yourself.)
Download the bug report to your computer.
Send the bug report by email to [email protected]
I have decided to open up my software, meaning I have made the source code available on GitHub, but it's only available for personal use, and you are not allowed (under any form) to redistribute your own version of the app. You can download and compile it yourself if you wish to do so, and you can implement your own changes for your own personal use, but you cannot create clones of the software which you redistribute under your own name. Source can be found here: https://github.com/borconi/obd2aa.
Due to the fact that there are some irresponsible developers out there, who created video apps for moving cars, which was one of the main reasons Google blocked 3rd party apps, I won't be updating the code on github any more, to try to prevent those developers to use my technique to overcome the limits. If you are developing a 3rd party app and you will like to know more about how I have done this, you are always welcome to contact me. If your project is something useful, I will be more then happy to share things with you.
This does not mean it is now a free app and apk can be freely shared!
Amazing work Emil, this along with your (and ofcourse @mikereidis) Headunit Reloaded app is perfect for Android Auto on the cheap ,
Gotta subscribe to this thread! The possibility of custom PIDs would be of huge interest to me.
Seems like its stuck without any option to change on Kmph rather than mph for speed etc, its set to mph in torque
fma965 said:
Seems like its stuck without any option to change on Kmph rather than mph for speed etc, its set to mph in torque
Click to expand...
Click to collapse
Yeap a few things to iron out....
Just to tired to work on it tonight.... it was a long one yesterday to get the alpha done for today but planning to work on it this weekend....
Emil Borconi said:
Yeap a few things to iron out....
Just to tired to work on it tonight.... it was a long one yesterday to get the alpha done for today but planning to work on it this weekend....
Click to expand...
Click to collapse
No worries, i wrote that quickly... other than that seems good, still figuring out what my car supports though. thinking about selling my tablet setup and buying the same car thing as me
fma965 said:
No worries, i wrote that quickly... other than that seems good, still figuring out what my car supports though. thinking about selling my tablet setup and buying the same car thing as me
Click to expand...
Click to collapse
Well I love my setup but I HATE my handsfree, have to come up with some solution for that because it's cr...
Emil Borconi said:
Well I love my setup but I HATE my handsfree, have to come up with some solution for that because it's cr...
Click to expand...
Click to collapse
does it not support external microphones?
fma965 said:
does it not support external microphones?
Click to expand...
Click to collapse
No. I have to try with a USB soundcard (which I use with my Odroid) but haven't got the chance yet, or I might just hook my himbox to the AUX in and use it that way. The built in mic is almost unusable especially over 30 MPH.
And first version of the app is live!
Bought, installed and looking good.
I've got the Prius PIDs plugin installed in Torque so I can see the data on my Prius C.
Only about half those PIDs are available to be selected, it looks like it's hitting the maximum number of allowed items in the "Select PID" list.
Great, could you please tell me, where I can find it?
FormelLMS said:
Great, could you please tell me, where I can find it?
Click to expand...
Click to collapse
The XDALabs app was a pain, I had to:
Install the XDA app from the Play Store
Log in
Install the XDALabs app it prompted me to install
Log in again
Then open Emil's link from the first post in the XDALabs app.
Ok, thank you. Any chance to have this in play store?
Hi.
Sorry for the pain caused by XDA labs, unfortunately Google play rejected the app submission so I cannot make it available trough that channel.
As for custom PIDs yes intending to support them in the future. Currently torque doesn't provide a method to expose them to 3rd parties so I need to speak with Torque developer if that is possible, alternatively I will need to fallback to manual PID configuration.
I will see if I can build a quick webpage to host/sell the app could potentially make it easier to get the app, but it will make it more difficult to keep it updated.
Emil Borconi said:
Sorry for the pain caused by XDA labs, unfortunately Google play rejected the app submission so I cannot make it available trough that channel.
Click to expand...
Click to collapse
Understood, I had a feeling Google wasn't going to allow it.
One of the issues with XDA is that you can get there via the web but it's not obvious at all how to buy it from there.
Then you have to jump through hoops to get the right app.
Emil Borconi said:
As for custom PIDs yes intending to support them in the future. Currently torque doesn't provide a method to expose them to 3rd parties so I need to speak with Torque developer if that is possible, alternatively I will need to fallback to manual PID configuration.
Click to expand...
Click to collapse
It's already showing around half of the Prius custom PIDs, it's like the list just runs out of space for more items.
edit:
Screenshot link
leonkernan said:
Understood, I had a feeling Google wasn't going to allow it.
One of the issues with XDA is that you can get there via the web but it's not obvious at all how to buy it from there.
Then you have to jump through hoops to get the right app.
It's already showing around half of the Prius custom PIDs, it's like the list just runs out of space for more items.
Click to expand...
Click to collapse
I'll send you a logging version at some point this weekend just to see if how much data Torque actually send over. For example it doesn't show any of my custom PIDs for KIA.
Thanks for this, it is awesome..
A magnificent add to the current great app.
Here is photo of my test
too low ISO 320.
My Observation:
1: I added in Gauge 2 : Volts(CM), then put "13.5" in W.Level 1, and 12 in W.Level 2, when I switch to ODB2AA it wont open and switch back to the current tab.
then I changed W.Level 1 to "13" and it works, so looks like it wont accept a decimal value!, don't know if its a bug or error from my side.
2: Each time I switch to the OBD2AA tab it takes 13s for the data to be pulled.
3: Just once "no data pulling", I had to unplug/plug usb to work.
suggestion:
* It would be good if there is a timeout option for the data pulling to stop, so no 13s delay when switch back and forth in that time, I don't know if it is applicable in AA.
Great job Emil.
MAJED.y said:
A magnificent add to the current great app.
Here is photo of my test
My Observation:
1: I added in Gauge 2 : Volts(CM), then put "13.5" in W.Level 1, and 12 in W.Level 2, when I switch to ODB2AA it wont open and switch back to the current tab.
then I changed W.Level 1 to "13" and it works, so looks like it wont accept a decimal value!, don't know if its a bug or error from my side.
2: Each time I switch to the OBD2AA tab it takes 13s for the data to be pulled.
3: Just once "no data pulling", I had to unplug/plug usb to work.
suggestion:
* It would be good if there is a timeout option for the data pulling to stop, so no 13s delay when switch back and forth in that time.
Great job Emil.
Click to expand...
Click to collapse
Check your email The version you are mentioning is the Beta, the release version has all those sorted
Sorry I'm moving too fast

Categories

Resources