So I got tasker up and running and have set up a small scene for when I plug my headphones in. It pops up a small screen asking what I'm doing, and I can either click do nothing (does just that), play music (sets volume levels and starts music), or car mode, which sets volume levels/wifi/blutooth/gps sensors and starts my ecu communication app (torque).
The only problem is, like any good computer science student, I know to unload something when done with it, and I unload the scene. This has the wonderfull effect reverting everything that little menu did back to it's previous state. I've come up with a few possible solutions, but have some gripes with each of them (see below). My question is though, is there any way to make those system changes static, so that when I unload the menu, it doesn't revert it's changes?
Solution 1 - Do not unload the menu, just hide it and have the profile that activates when I unplug my headphones unload it.
Problem - This leaves it in memory. Not the largest chunk of wasted space ever, but still less than desirable. Looks better to me than solution 2 though.
-------------------------------------------------------------------------
Solution 2 - Have the button set a variable which when active starts another profile to do all those things
Problem - That just creates 1 (or more) extra profiles that I assume tasker is constantly monitoring the status of. That's wasted cpu cycles right there.
-----------------------------------------------------------------------
Solution 3 - Somehow make the changes persistent, so that they do not revert when the scene is unloaded.
Problem - I'm not sure if it's possible to do this. Help would be appreciated, thank you!
---
parrotgeek1 said:
don't have this device, but could someone try decompilng framework-res.apk and go to res/values/config.xml and add these
Code:
<!-- Is the notification LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveNotificationLed">true</bool>
<!-- Is the battery LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveBatteryLed">true</bool>
<!-- Does the battery LED support multiple colors? Used to decide if the user can change the colors -->
<bool name="config_multiColorBatteryLed">false</bool>
<!-- Default color for notification LED is white. -->
<color name="config_defaultNotificationColor">#ffffffff</color>
Of course you can change config_defaultNotificationColor to any html color in lowercase, but start with white for testing.
Then download lights.shamu.so from aosp (one that supports notifications afaict)
https://android.googlesource.com/device/moto/shamu/+archive/master/liblight.tar.gz extract the tgz
and put the .so in /system/lib/hw (replace the old one)
then recompile framework-res DON'T SIGN IT! or use a kitchen and reflash
reboot go into notification settings and turn the lights on
it COULD also enable the green battery charging led natively, idk
Click to expand...
Click to collapse
Didn't work... I see the option for "Pulse Notification Light" and it's enabled but it doesn't light up when I try to text myself and receive the message with the screen off.
1. There is no config.xml.
2. I modified the bools in bools.xml and the color in colors.xml (no modification needed for colors).
parrotgeek1 said:
don't have this device, but could someone try decompilng framework-res.apk and go to res/values/config.xml and add these
Code:
<!-- Is the notification LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveNotificationLed">true</bool>
<!-- Is the battery LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveBatteryLed">true</bool>
<!-- Does the battery LED support multiple colors? Used to decide if the user can change the colors -->
<bool name="config_multiColorBatteryLed">false</bool>
<!-- Default color for notification LED is white. -->
<color name="config_defaultNotificationColor">#ffffffff</color>
Of course you can change config_defaultNotificationColor to any html color in lowercase, but start with white for testing.
Then download lights.shamu.so from aosp (one that supports notifications afaict)
https://android.googlesource.com/device/moto/shamu/+archive/master/liblight.tar.gz extract the tgz
and put the .so in /system/lib/hw (replace the old one)
then recompile framework-res DON'T SIGN IT! or use a kitchen and reflash
reboot go into notification settings and turn the lights on
it COULD also enable the green battery charging led natively, idk
Click to expand...
Click to collapse
Hey so I tried by baking it into my AOSP build. ( config_multiColorBatteryLed is not in the XSD so i did not include that) Nothing so far. Good thought! Im going to keep looking, at least I was able to add allow All Rotation to my build .
There is no ledtrig heartbeat trigger included and stock kernel does not support loading modules
.
parrotgeek1 said:
Please elaborate.... what's a heartbeat trigger
Click to expand...
Click to collapse
Well to put simply, it's the method that causes the LED's to flash like a heartbeat. (From what I can remember).
ie. OFF - - - ON OFF ON OFF - - - ON OFF ON OFF (so on and so forth).
The way Linux led works in nutshell as i understand it from my quick research is either setting brightness level manually (slow and unreoiable, better to be done at low level) or setting max brightness and setting appropriate trigger kernel module, e.g. set trigger to none to disable or mmc0 to blink to indicate card write activity and so on, ledtrig_heartbeat used to pulse the led and it is not an option in our triggers in nexus 6 (not in kernel) and without modules support we can not load it.
So just enabling led string would not be enough to get pulse notifications. Waiting for custom kernels.
Take a look http://fabiobaltieri.com/2011/09/21/linux-led-subsystem/
So, its working for me. What I did was just used light flow. I enabled root mode, then I enabled run every command as root, then I enabled direct mode. Then I had to choose the correct led for it to use in the other menu and when I ran the test it came on.
Xileforce said:
So, its working for me. What I did was just used light flow. I enabled root mode, then I enabled run every command as root, then I enabled direct mode. Then I had to choose the correct led for it to use in the other menu and when I ran the test it came on.
Click to expand...
Click to collapse
I believe the goal here is to have led notifications natively, without an app running in the background constantly.
Roger that, sorry wasn't sure, figured I would share just to be safe
The source is available, why not just compile a kernel with module support?
Random mutterings...
Note: I don't have a personal build environment set up at the moment, so it's really difficult for me to check these things properly.
# should already be set
CONFIG_LEDS_QPNP=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
Using these, it's already possible to, for example, activate a charging LED. (echo battery-charging-or-full > /sys/class/leds/charging/trigger) Where is the kernel support for those charging related triggers? Not finding it in drivers/leds/trigger, but it might be specific to a charging chip? No build environment means no grepping code for the strings...
# not set, but why not? does QPNP not support it?
#CONFIG_LEDS_TRIGGER_TIMER is not set
A "timer" trigger is one of the methods to create a blinking LED. (not heartbeat) the ONESHOT might also be useful. FYI, the heartbeat trigger is documented in the kernel as:
This allows LEDs to be controlled by a CPU load average. The flash frequency is a hyperbolic function of the 1-minute load average.
Click to expand...
Click to collapse
How are the triggers configured for hammerhead or perhaps for a motoX device, and how is that different from shamu? As well as kernel support, there needs to be liblights.so support for the kernel parameters, JNI support, and JAVA support. Some or all of these might already exist. Not sure yet.
The "three" LED's (red/green/blue) in shamu are configured as GPIO devices (see apq8084-shamu.dtsi.) In leds-qpnp.c, blink_store(), an ID of 8 (GPIO) will result in an error. Does that matter? If they are GPIO devices, why not configure them with leds-gpio instead of leds-qpnp?
In contrast, the "charging" LED in shamu (defined in apq8084-moto-common.dtsi, I think) appears to set up differently (MPP?) and should support blink types (that does work, actually.)
...
Why is the "charging" LED handled so differently from the 3 color LED? If I'm going to mess with the LED's, I'm going to get them blinking the way they should, dammit.
What is the disconnect between the kernel (which, at the very least, supports a charging LED properly) and the rest of android? It's been several years (i9300 -- galaxy S3?) since I've messed with the LED code in android...
Odd: there's no source for liblights.so in the shamu code device tree (just a compiled lib), but there IS source for liblights for other platforms (if there's any lib at all.) Not sure I've ever seen the LED stuff being considered a proprietary blob (especially when it's kernel driven and the kernel source is all intact.)
You know your losing your mind when you start excessively replying to yourself in forum threads. It's worse when you have to re-learn something you were very familiar with just a few years ago.
android notification system uses LightsService for various LED related stuff. (This includes the screen lighting.) LightsService relies on some jni code (com_android_server_lights_LightsService.cpp) to interface to the liblights library. The JNI module is tiny, and really doesn't need to be mucked with. However, it's a really nice place to put logging code. The JNI only has three methods: init_native(), finalize_native(), and setLight_native().
The init is called for each type of LED "device". they are backlight, keyboard, buttons, battery, notifications, attention, bluetooth and wifi. Add logging code here to see which ones are returning a valid pointer, and which ones aren't. (I'm guessing that only backlight is being returned. I hope I'm wrong, but if I'm not, then lights.shamu.so will have to be re-written from scratch to support the other device types.)
The only other interesting place will be in setLightnative(). This takes a crapload of parameters, which are all packed down to a light device pointer and a "state" structure. These are passed to the native (lights.shamu.so) code for processing. Adding logging here might be useful. It also might not be (depending on if the damn light initializes or not.)
Why does this all seem so damn familiar to me? (because I've done it before and managed to forget most of it.) (hopefully, by typing all this, I'll be able to find it again in the future via google searches.)
I was getting bored, so figured I'd reply to myself. Again.
It appears that lights.shamu.so is the base of the problem. (There might be other issues, of course, but one of the ways to dig these things out is to start at the lowest level and work your way up...)
Kernel: has support
sysfs supports (if somewhat limited)
The next layer is liblights.so (or, in this case, lights.shamu.so.) The ONLY "light" that this lib seems to support is "backlight." The following all give errors: "keyboard", "buttons", "battery", "notifications", "attention", "bluetooth" and "wifi"
I am curious what the "battery" light type is. Is that designed to be the charging LED, or have some other purpose within android? Will need to check that out...
Anyway, I'll whip up a "lights.shamu.so" replacement and see what happens with that..
hrmm.. I've never seen this before:
Code:
E/HAL ( 957): load: module=/system/lib/hw/lights.shamu.so
E/HAL ( 957): dlopen failed: empty/missing DT_HASH in "lights.shamu.so" (built with --hash-style=gnu?)
Of course, the obvious thing would be to edit device/moto/shamu/liblight/Android.mk and add "LOCAL_LDFLAGS := --hash-style=both", but that's giving me a compiler error:
Code:
arm-linux-androideabi-g++: error: unrecognized command line option '--hash-style=both'
Now, why is an LD flag being passed to the c++ compiler and not to the linker? For that matter, why is it using g++ instead of gcc? hmm... This should be easier than this.
I figured I should thank you for doing all these
garyd9 said:
hrmm.. I've never seen this before:
Code:
E/HAL ( 957): load: module=/system/lib/hw/lights.shamu.so
E/HAL ( 957): dlopen failed: empty/missing DT_HASH in "lights.shamu.so" (built with --hash-style=gnu?)
Of course, the obvious thing would be to edit device/moto/shamu/liblight/Android.mk and add "LOCAL_LDFLAGS := --hash-style=both", but that's giving me a compiler error:
Code:
arm-linux-androideabi-g++: error: unrecognized command line option '--hash-style=both'
Now, why is an LD flag being passed to the c++ compiler and not to the linker? For that matter, why is it using g++ instead of gcc? hmm... This should be easier than this.
Click to expand...
Click to collapse
I believe in you Gary! Seriously though thanks for taking the time to work on this.
I appreciate the support, but I hope everyone remembers that I have a full time job that takes priority. That generally means that most of my android "fun" work gets deferred during the working week.
The task will get done, but please be patient...
Take care
Gary
We definitely appreciate everything you and the other devs do! I'm very much enjoying the AOSP Email! I did not want to use Gmail for my work email. I know it might have some benefits but I just needed the basic email app so that was very much appreciated!
The app is setedit and you'll need to hand over almost $3 Canadian if you want these tweaks. 1 of them will work for sure without needing to enforce but I think it's a sweet deal and 3 of these are working on Pie. 2 of them, or even 1 is worth the price.
You'll need to go into a shell and enter exactly:
pm grant by4a.setedit22 android.permission.WRITE_SECURE_SETTINGS
Copy and paste it. If you don't know how to do that just look up ADB, android developer options, and Samsung USB drivers.
First the freebie. Go into Secure Table and click +add new setting (your first entry may ask you to grant a permission. DO IT)! enter: clock_seconds value: 1 BOOM! Hope you like it because it'll NEVER go away! Just kidding. If you factory reset... or simply enter a value of 0 you'll be rid of the ticker.
Next up I think is a freebie, too. Still in Secure Table, scroll down to sysui_qs_tiles delete everything. NO DON'T! Carefully, without erasing the entire list, add in MobileData exactly like that. So actually it'll be a comma first. Have a look around for other tiles because 'ol Sammy likes to keep things real tight with the carriers. You can also remove some but I think it's best to not potentially freezing your phone up.
Now, pretty sure these ones will need the guardian to stick so if you can manage 3 bucks it'll be worth it, especially the last 2!
Change tile rows and columns.
Right above the tile edit in Secure Table is sysui_qqs_count I like a value of 7. Don't go too small or too high. Or do it and see what happens. Please don't. I can only vouch for 7 and 8. I have heard of 3 but never tried it. This changes the first row, first pull on notification menu.
Now to change the rows, the long pull I guess you can call it, qs_tile_row in Secure Table still. I do 4. I heard if you enter in 50 you get a widescreen TV. No idea. I only tried 4.
Screen Timeout not long enough?
While some of you may not need it, I need more than 10 minutes. Head to System Table and... not sure why, but I think this needs both screen_off_timeout_rollback AND screen_off_timeout to work. I set mine to 1800000 (yes 5 zeroes) to get 30 minutes. Do it on both. Double that, 3600000 will give you an hour. So if you want 13 minutes and 27 seconds, figure it out. I think entering a value of 1 will get you a free trip to the ODIN app. Don't know what that is? You'll find out pretty quick if you screw this one up. Of course you're gonna head to the menu and look to see a new entry of 18 minutes and 55 seconds. Not happening. What you will see is that no selection is made. DON'T TOUCH IT! Just leave it alone. It's working. This one works in Pie. Only one setting is needed. Can't remember but you'll find it.
These 2 are the bestest and they work in Pie.
Goodbye HIGH BRIGHTNESS and HEADPHONE VOLUME warning!
In Global System set audio_safe_volume_state to a value of 2. "But mine's already at 2." So then you've been warned. Now add it to the guardian.
In System Table, you'll want to alter a value of 1 in the shown_max_brightness_dialog "But I don't have that entry." So close the app, crank up the brightness and be told how evil it is. Wasn't that fun? Now fix up the entry. Add it to the guardian with the 1 value and if set to 0 don't forget to change to 1
*NOTE* most of these values take about 15-45 seconds to kick in after every reboot. So, before you reboot and say it doesn't work, well, you're kinda right. But you'll soon forget about it and one day be able to reboot without seeing if it works or not. Finally, one day, you'll go to turn up the brightness, or volume, and that warning will not appear. And THAT'S when the real joy is felt. As you're cranking up that slider, in all of .02876 seconds, you're going to think, "Stupid warning" "OMG I am not gonna get a warning" "Hey cool I didn't get the warning. Anyone see that?"
Bonus Feature! When bored I random;y change values of random entries. See how fast you can screw yours up! Don't play with anything unless it's your friend's phone. We're not friends.
I can't vouch this works on any other device except A8. It's a representation of what's on your phone. Adding a custom ROM will change the output and results. Use your noggin, yo
Finally, I turned off battery optimization for the app and feature pack, and turned off notifications. It works fine. No usage pops up because it's very small and no problems with enforcing the edits. No annoying notification required.
mindlery,
I'm doing an article about Drone flight and high NITS display devices. A tablet or phablet that can display the sun equivalent brightness is very expensive so most pilots use cell phones. Of these cell phones samsung and lg both have models that will BOOST brightness (manually at least on the lg G7) but it will only boost for up to 3 minutes. one might think its' a heat issue but the timer is probably a battery saver because when flying I keep resetting my boosted brightness on the Lg-G7 and the phone never gets warm.
So you appear t6o have knowledge on this and there may be an opportunity to help a bunch of pilots if a boost timeout can be changed (easily via app or some easy method) to fix the boosted time to about 30 minutes or make it a manual switch.
If you are at all interested, I'm going to do an article and video for other pilots on this if I can get a solution down.
Bill
I have a strange situation that keeps happening. Every so often the wallpaper on my Pixel 6 will change to a solid color (that resembles the theme of the wallpaper I had active - for example sometimes it is gray, other times brown). From that point I can't seem to get rid of the solid color unless I reboot the phone. After a reboot the correct (previously active) wallpaper is shown. When the solid color is there it is almost like it is on top of the wallpaper because in the wallpaper settings the pixel thinks that the wallpaper is set properly and if I change the wallpaper there the solid color just persists and I never get an updated wallpaper.
Does anyone know how to fix this? It seems to happen most after I have used Android Auto, but happens at other seemingly random times too. I appreciate any help as I have tried many things with no success.
Not sure about you but I have a IFTTT applet that changes my desktop to black if my battery gets low. Well I know that now. I forgot about it though after setting it up. Drove me ****ing bonkers. I spent the better part of my free time in the evenings for a several days coming back to the mystery after work. I was digging into some deep reading in developer forums and official studio documentation after a full stock fresh start and it was still occuring.
Are you using any theming, root, power saving, optimization type apps? Or remote access, docking? Could be a setting or feature of what you're connected to. Can you reproduce it at will? or is it genuinely random. Did you change any settings related to freeform windows, overlays, hardware acceleration, Or systemUI mods, tweaks, or any hidden settings. If you have root, do you have any modules you haven't really tested for compatibility? Does it happen at certain times? only with certain events or places? Do you have assistant set up? automation, tasking? Set up any routines to run in the background that might be failing to do something with the wallpaper and just defaults to best possible match. Have you changed anything to do with locations of your media, where apps are installed, or what folders they have access to? Are you casting to wireless screens? enabled any "second screen" features or settings? Have you modified the DPI beyond stock ranges. Maybe your accidently putting the screen on something with similar conductivity with skin and have smart lock enabled and your getting random input while not using it.
Could be a lot of things.
Identify specifics, change something, track results; rinse repeat.
Thanks for the suggestions. I have tried some and will look into others. Based on lack of activity this does not seem like a widespread issue, so it is likely just some software causing this issue. I will continue to investigate and hopefully find the culprit. Thank you again!