[Moto Maxx Android Development] Septfox:
By your logic then, if the pattern/PIN/etc lock you're using could be instantly bypassed by pressing the home key...it'd be perfectly alright to ridicule you and try to persuade you to use the simple keyguard instead. Your usage scenario is common, but we don't use it, so fair's fair right?

Nobody "deserves" to be affected by what appears at first glance to be a bug during normal usage. And regardless of how you personally feel about it, keyguard+Ambient Display is a common setup.

This is going to get long, so I'm wrapping it in a spoiler to keep the thread cleaner.

I already made a fairly lengthy, detailed post explaining what the problem is, how to reproduce it, and from a usability standpoint how the sensor should affect Ambient Display. It's not beyond the realm of possibility that the keyguard is being dismissed by accident, it does register short/quick flings.

While we can all agree that Moto Display and Ambient Display are and should be different aesthetically, the latter should at least be similar or better in usability.

I've gone and checked for this behavior in the stock ROM; the proxy sensor does actually kick the display on, unconditionally. The thing is, since Moto Display is essentially a KitKat-style keyguard combined with a simple form of Ambient Display, this works fine; it's unlikely that you'll be able to dismiss it with random flings, and the power drain due to the AMOLED screen is so small as to be unnoticed.

But for actual Ambient Display, having the display kick on unconditionally is harmful because it has no such protection against accidental touches.

Does this mean Moto Display is better? No.

Does this mean Ambient Display is worse? No.

All it means is to make Ambient Display function optimally, the sensor behavior should take its differences from Moto Display into account.

You continue to insist that the "fix" is to use a proper lock. That isn't a fix, it's a workaround to prevent the phone from doing things if the sensor pulses when it really shouldn't. The display still turns on fully, and still wastes power until it manages to avoid being touched long enough to time out.

Further, if we have the feature that does so (not sure, can't find it immediately), a user could potentially find that their phone has wiped itself due to too many failed pattern attempts, just because they opted for a little extra security while carrying it in their pocket. Does this seem like good behavior to you?

Others are insisting on Moto Display because from a typical Quark user's point of view, Moto Display currently works better than Ambient Display. Remedy the issue itself instead of bandaiding it, and you fix the majority of complaints.

(not "you" you, the royal "you". you know what I mean.)

I used cm11 (well, SlimKat), cm12/.1 and cm13 on my Droid 4; when Ambient Display and the phone's sensors work in harmony, it's a wonderful thing. It's one of the things that kept me from ever downgrading to cm11, despite cm11 running consistently much better on that hardware. I'm certain that more people would learn to like it if it interacted intuitively with the proxy sensor.

I'll take this to the CM13 thread, because it's not specific to RR itself.

---

[MENTION=5747496]bhb27[/MENTION]

First, apologies for disrupting your thread. It wasn't my intention when I began posting here.

As mentioned earlier, notification sounds and I believe vibrations are stopped immediately when the screen is turned on, whether it is by Ambient Display, or a third-party app (DynamicNotifications turning on the screen does the same thing).

Reproduction: wipe everything but internal storage, then freshly install RR and Gapps, enable Ambient Display or install an app that wakes for notifications and toggle all gestures. Turn off the screen and do something to trigger a priority notification (I sent emails to myself in testing).

This doesn't occur in the latest CM13 nightly with exactly the same Gapps package, nor does it occur in CM13 with your kernel flashed. I believe it is exclusive to RR.

Please disregard the aforementioned Wifi instability and proximity sensor/Ambient Display behavioral complaints, as these are present in CM13.