[Nexus 5 Original Android Development] amaces:
Volume Wake & Charging LED Props

A while back I mentioned resisting forking Settings for UI changes, so my solution for people who need little bits of custom behavior is props. Specifically, I created persist.wm.volume_wake_screen and persist.sys.led_on_charger for controlling these two features in lieu of UI toggles. The former is off by default, while the latter is back to on in all the latest N through P builds. You can enable/disable them with setprop (e.g., ADB shell, Terminal, etc) followed by reboot (soft might be sufficient).

The longer story is that volume button wakeup, without sacrificing normal functionality otherwise, needs frameworks changes that cannot be turned on by default for obvious reasons. People with power button issues will just need to use setprop once per clean install, and volume adjustments should still work after wakeup.

In other news, I'm working on scripting changes to releasetools such that /system resize happens automatically in recovery (https://review.lineageos.org/231356). Hopefully, these can be turned on in the next set of builds. Also, I'm stopping personal CAF Oreo builds for now (camera breakage was due to using Clang 8), but UA 8.1 builds and maintenance will continue. Of course, I'm continuing CAF Pie and AOSP builds, while absorbing all the pending changes on UA.

Indeed, we just crossed the five-year mark, and hopefully we can squeeze a couple more years out of it!

Sounds like you only have coarse location data (Wi-Fi based), and Google thinks your router/AP still lives at the old address. You can fix that by submitting a ticket on Google Maps.

Indeed, you're not locking any GPS signal apparently. Is this on UA Oreo, or my personal Pie builds?

CAF or plain AOSP build? I heard of occasional crashes with other apps (Viber), but can't do much w/o some sort of logs. I've only tested plain GApps-less install at this point.

It stopped happening after you fixed your battery issues, right?

You can install them on top of each other, and decide based on your use. They're both equally usable, albeit each with its own feel.

Thanks for contributing. Indeed, the hardware and our sensor stack is not very friendly for this purpose (w/o killing battery, that is). I guess hhcaf adapted some Moto Doze UI bits, which exposed more controls, but they didn't seem very reliable. I guess we could experiment with that once there's less to do.

I can help you with volume button wake (read beginning of post), but haven't looked at double-tap sleep. I guess we could implement that in frameworks hooked to another prop…

Not sure I follow. It has all the standard AOSP privacy features.

While porting third-party privacy managers is technically possible, the changes would be pretty invasive, so very unlikely to happen on UA builds. Still, I keep my kernel and device tree Lineage-compatible, I contribute everything new there, so once things stabilize, one could build LNOS from these repos almost painlessly.

Does it happen in the CAF builds? Also, please test current builds as well (10/28, all interchangeable).

Did he comment on BT HFP in his N5 Lineage builds? Clearly, we should look in there if that bug got fixed.

Please test current 10/28 builds. I'm hoping it's not due to my newer Clang toolchains.