Notification cancellation fixes:
Permission should only allow cancellation of other app notifications, not enqueueing.
Fix checkapi breakage.

Change-Id: Idbcfd4617057984250dc4d4fa32ff55bfbb155e2
Validate restored file paths against their nominal domain

Bug 8460775

Change-Id: Ib16d740a001adf4f9cb9ccaa31066ac7cadfb430
Ensure install-during-restore is like install-then-restore

When we've installed an apk from the archive, recheck whether
to apply the system-uid policy restrictions around file system
restores.

Bug 8833099

(cherry picked from commit 2baf6dcfcf7fc1705db25e64dc0cb11fa3509d39)

Change-Id: I972fe1543f2234aa76baf562d6f806175ac0248e
Add a delimiter between scheme and host

Bug: 6923539
Change-Id: I49aac145e8e80a5af7475cfe93ef4a353d2d3fe6
libdrm: fix bad strncpy / snprintf calls

Fix the following bugs reported by IOActive:
* GOOGLE-AN01 - Android libdrm drm_parseDM.c Boundary-CRLF Buffer Overflow
* GOOGLE-AN02 - Android libdrm 'drm_parseDM.c' contentType-CRLF
		Buffer Overflow
* GOOGLE-AN03 - Android libdrm drm_parseDM.c contentID-CRLF Buffer Overflow
* GOOGLE-AN04 - Android libdrm 'parser_dcf.c' Multiple Headers
		Buffer Overflow
* GOOGLE-AN05 - Android libdrm 'parser_dcf.c' ContentType Buffer Overflow

Bug: 8727221
Change-Id: If386922e907567f54e26897beffaa1cfe4777896
Prevent notification acces via HALO on protected lockscreens
Fix deadlock of WebViewCoreThread

There was a deadlock in destroy process.
Investigation showed that WebViewCoreThread is waiting some
callbacks but in this case WebViewCoreThread can not resume
itself not to call notify method.

Flow:
1. CallbackProxy.sendMessageToUiThreadSync
2. WebViewClassic.destroy()
3. CallbackProxy.blockMessages()
4. CallbackProxy.handleMessage is called via MainThread
5. The WebViewCoreThread deadlock is occured.

The cases we have to call notify method are followings.
OVERRIDE_URL
CREATE_WINDOW
SAVE_PASSWORD
NOTIFY
OPEN_FILE_CHOOSER
JS_ALERT
JS_CONFIRM
JS_PROMPT
JS_UNLOAD
JS_TIMEOUT

Change-Id: I9d95ae500bf6338d77b32b5fa15de7cff5720d0f
Avoid adding FORWARD_LOCK flag to an updated system app

Consider the following case:
1. An app exists in /system/app or /vendor/app. (i.e, it's a system app)
2. If the app would be updated as a forward-lock app by downloading from
   market(google play), then it would be installed in /data/app-private.
3. Moreover, if it would be updated by the whole system image (i.e, FOTA
   or something like that), then the app would be applied a FORWARD_LOCK
   flag.

The app SHOULD NOT have a FORWARD_LCOK flag. Because the resource path
of such app does not refer to the proper resources to access.

Change-Id: I0750f69a93a3115f4201029796b598507de3555f
Lockscreen : Reference correct layout

Include correct layout for portrait.

Change-Id: I6de511357aec0f4364cd68c3ed740c7d4f47379d
Avoid unnecessary FindClass("java/lang/String").

Use previously retrieved global reference instead.
Check for NULL after creating the global reference.

Change-Id: I21670d2ef0f63ddb5801dd21e7e56359e5519479
Add BeanStalk battery style - thanks skyliner
Signed-off-by: scotthartbti <scott@ubuntu.com>

Change-Id: I7352ff0128e428957eeec6ab332531575b713e50
Revert "Add BeanStalk battery style - thanks skyliner"
Not ready for prime time yet...  still needs a little work
This reverts commit 78607bf9d081d4031491513ad3e29e2d59e5ef2a.