[Nook HD, HD+ Android Development] amaces:
I've been aiming for Sunday afternoon/evening builds, but the context of the recent review items also matters. If I see a flurry of changes to core systems, and people debating back-and-forth, or reports of breakage across many devices, I'll hold off till things settle down. Thus, the recent Monday/Tuesday builds, but I think we're good this week.

About Browser, the APK does get compiled with the system, but can also be extracted, and assuming no major library incompatibilities, can replace other versions. Not sure much has improved with it recently, though.

I've been hoping that for a while now… The OP has been updated with a little section about how I see our official nightly progress, and I'll reiterate here:

Now, these issues will eventually be fixed in the upstream repositories, either my way, or in some other incarnation, but I'm no good at arm-twisting, so the timeline is beyond my control. Even after official nightlies flow once more, many of my kernel and device changes will likely not be integrated upstream, so I'm definitely continuing my own thing on my ovation. We'll have something akin to current TWRP situation: official baseline build, and a somewhat crazier variant that I cook for myself ;)

I think most BT profiles have been working for a while, with the notable exception of audio input (i.e., 8 KHz headset streams, and that's due to audio HAL). There've been barely any changes to the BT stack.

Thanks for providing feedback despite your dominant wrist happenings ;) I'd like to maintain my sanity, and firmly believe that regular apps don't have anything to do with our current reboot/power off woes… I'm going to keep working under that assumption, pretend that correlation is different than causation, since otherwise all the learning curve so far was for naught…

Thanks, [MENTION=4190710]drmarble[/MENTION]; I was looking through that commit the other day, but I'm not sure what problem it's attempting to fix. If it's solely about the initial calibration/NVS BIN generation in fix-mac.sh, I don't recall us having a problem there on CM12. The change seems benign enough, but why introduce a two second delay if not needed?

Aww, my Color is hidden somewhere, and I'm periodically tempted to turn it on, try to torture it with some LP ;) I really don't see any good reason anymore…

Our audio driver and codec (TWL6040) likes 48 KHz much better, and definitely hates switching sampling rates (see the recent changes in our audio HAL). Mixing in 44.1 KHz was the main reason for the broken built-in mic/wired input in VOIP apps, Voice Search, etc. The TARGET_NEED_44KHZ_SOUNDS flag would be an interesting things to have, but we're OK either way, I think.

That doesn't look right at all… I don't know what to tell you beyond general advice: make sure the back and the screen (right/bottom edge especially) are not overly warm, suspend/turn off the device for a while, etc. Have you ever tweaked the touchscreen sensitivity settings with verygreeen's app? If so, make sure no leftover settings remain; if not, find that app from his thread, and play with the settings.

That's the thing, nothing has changed with the touchscreen controller for a long time. I cannot imagine that CM12 has anything to do with it, and I certainly haven't noticed anything related to this in the repo changes. Glad things are OK for you now.