Active display: make sure mNotificaiton is set correctly

Change-Id: I4111ca843e340cca4d6dac4b2c2922ce3039e487
Active display: register/unregister recievers and listeners when enabled/disabled

Change-Id: Ic73e63da2c9634bc864ab1a1387eb9145eb0b5b0
Active Display: check if recievers and listeners are registered

Change-Id: I1a881aebcbfc2bae92535a4e9ea55ba3789d8b43
Active display: Catch Resources.NotFoundException

This caused the SystemUI to FC when the device was powered and a notification was fired.
Display stayed off and the SystemUI kept restarting until the device was unlocked manually.

Change-Id: Ibfd82242e82aa9ee5c0898f5f0714e490eac0ea9
Revert "Active Display: check if recievers and listeners are registered"

This reverts commit 16384847ed731e25b1a63f4fd921c9b4808ab674.
Active display: Unify (un)registering callbacks and add proper checks.

Change-Id: Ie4c4660a54d2c60831f7a3bcc66b3a9ca1d035f2
PrivacyGuard: New icons close to AOSP style

Change-Id: I3a82bba2d46a88ea13d37b7572af4108c9d43f83
Signed-off-by: Dan Trifan <jimsth@gmail.com>
Active-D: Make GlowPadView center the current notification icon for us

sudo makemeasandwich

ps2: make scaling both smarter and stupider SIMULTANEOUSLY

Change-Id: I582f387fd3c1c83f2bbd0d31a4b43e22d1b82d63
Signed-off-by: nuclearmistake <nuclearmistake@gmail.com>
Active display: Fix for HDPI devices.

Thank's to @AlmightyMegadeth00 for the tips...

Signed-off-by: aways <aways@c-rom.biz>
Revert "Lockscreen: Use bold for hours and thin typeface for minutes."

This reverts commit 0a97c6da7e515f3f741ce4baf381cda05a7b378f.
KeyguardViewMediator: Play lock screen sound sooner

When the screen is locked, there is a long pause before the lock
sound actually plays.

This makes that sound happen much sooner.

Also modified Lock.ogg slightly to remove the initial silence.

Change-Id: Iede7a5d22291d1ada98800d2b380c255547df61d
fix active display?
Signed-off-by: scott <scott@ubuntu.com>

Change-Id: I421cfc0dcdd91eabb70f2cb474efdd6fc7f57a59
Active display: Option to change display timeout…
…[1/2] [log]

Change-Id: I3e0d9d05ddf3892b0223c012b5420bbcf4e3b6e1
HALO: Code cleaning up

Credits to: Anu6is

Change-Id: I10c3db6a538ba475f567e3e00fe6f92e00364bbc
Signed-off-by: scott <scott@ubuntu.com>

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/halo/Halo.java
	packages/SystemUI/src/com/android/systemui/statusbar/halo/HaloProperties.java
AppOpsService: Add MODE_ASK support to AppOps.

Add support for new mode(MODE_ASK) in AppOpsService to show a permission
dialog box to user to confirm user permission before allowing or ignoring
that operation.

All strict operations (defined in AppOpsManager) are going to be in
MODE_ASK by default.

Operations will be moved to MODE_ALLOWED or MODE_IGNORED according to
user's choice.

Change-Id: I1314125a2b8be558e422e4a9eea0ff066c21bf94
Signed-off-by: scott <scott@ubuntu.com>

Conflicts:
	core/res/res/values/arrays.xml
	core/res/res/values/strings.xml
	core/res/res/values/symbols.xml
AppOps: Add support for whitelist of packages.

By default AppOps gives MODE_ASK permission to all strict operations.
This can degrade user experience for pre-installed apps.

This change adds support for passing a whitelist XML file to AppOps.
Operations requested by packages listed in whitelist file will be set
to MODE_ALLOWED by default.

User can still go into settings and override permissions of these
operations.

Whitelist XML file should have following format:
Example: whitelist_appops.xml

<whitelist-pkgs>
    <pkg name="com.android.settings"/>
    <pkg name="com.android.systemui"/>
    .
    .
    .
</whitelist-pkgs>

Change-Id: I78bf5e7baa95f0e86f9856fb38bf1ca238691303
wifi: Confirm user permission before toggling wifi.

Check user permissions before enabling/disabling wifi.

Change-Id: I1ddae6e47f42b6d3fc831c2c135ece75cf9e935d
AppOps: Add Bluetooth enable control into AppOps

Check user permission before enabling bluetooth.

Change-Id: Iefa4ea3319b33b2639beaf38d261d83649bbcf85
AppOps: Add data connect control into AppOps

Check user permission before enabling/disabling mobile data.

Change-Id: I6e1895b130788dfccbc0a8523dadf1559b698988
Keyguard: LaterLock: improve the handling of policy timeout

If the security policy specifies a maximumTimeToLock, the
previous implementation would consider the screen's
displayTimeout as having elapsed, even if the user simply
pushed the power button to turn the screen off.

Consider the case of a 30 minute policy timeout and a 30 minute
display timeout.  In this case, pressing the power button will
cause the phone to be immediately locked (even if the user
requested it remain unlocked for 30 minutes).

This commit differentiates these two cases (display timeout
vs. user initiated display off) and only counts the displayTimeout
period if it wasn't user initiated.  After this change, the
lock would only occur 30 minutes after the power button was
pushed.

Note: if the user requests, in the Settings app, that the
Daydream start immediately, it will still consider the
displayTimeout to have occurred because we don't have enough
context at this level to tell whethr or not Daydream was
user initiated or due to a displayTimeout.

Change-Id: I8ea971c75685b2c2b9d4ec050a7bce6e28f45746