Handle backup transport registration dynamically

Bug 11369873

Change-Id: I9bbdcc21ce25159c6645690123b5d03c553b0ddc
FLAG_PRIVILEGED disappears if privileged app is updated and rebooted

Since Kitkat, an app pre-loaded under /system/priv-app/ has
FLAG_PRIVILEGED. However, if the app updated and the device
rebooted, privileged flag is unset from pkgFlags. This patch
fix issue to assign privileged flag when scanning the updated
packages.

Bug: 12640283

Change-Id: Ic24b5882f65dabdfae9cc39da3d68661bed4fc31
Only send storage intents after boot complete

It is not possible to send a broadcast before the system
boot is completed. If you do it anyway you will get an
IllegalStateException: Cannot broadcast before boot completed.

If a memory card is inserted or removed while the phone is
booting up, there is a risk that the MountService will try to
broadcast a storage intent too early, and cause the device
to crash.

Use FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT to avoid
problems with too early broadcasts.

Change-Id: Ied36a13d235df37c9788e45a35de40d919ae0cd0
Remove unused field from AssetManager.

This field was introduced in commit 4bdd33b81a17 but wasn't
used there (or since).

Change-Id: I0615e98b8990d42da6b85f8094ab19eb0465fd9e
Telephony: Modify code to check that PUK code length is always 8.

As per 3GPP TS 31.101 Release 11 section 9.6, the number of digits
for UNBLOCK PIN (PUK) is always 8.

Change-Id: I4ea69fd8e2e8e96330d10a67b2d1f5a1859c1016
[1/2] FB: Make menu unlock configurable

For devices with hardware menu keys, menu unlock is turned on by default
This can cause unintentional unlocks. This commit adds the ability to turn
Menu Unlock on or off as desired (Settings -> Security)

System Default is for menu unlock to be ON. This default value can be
overriden using a device overlay:

overlay/frameworks/base/packages/Keyguard/res/values/config.xml
<!-- Allow the menu hard key to be disabled in LockScreen on some devices -->
    <bool name="config_disableMenuKeyInLockScreen">true</bool>

This commit requires the matching commit from Settings repo:
https://gerrit.slimroms.net/#/c/2395/

Based On: https://gerrit.omnirom.org/#/c/3317/

PS6: correct config/overlay location and make multiuser compatible
PS7: derp
PS8: remove the symbol
PS12: rebase

Conflicts:
	core/java/android/provider/Settings.java

Change-Id: I3b6108e4bd403cb76827daed226a4d6a5b868741
Squash UMS Commits [1/3]

Credits: CyanogenMod

Change-Id: I09ed8bcc053f545377f28839673eadd2b9a2b872
[1/2] base: Add support for ADB over network

Originally from CM.
This patch actually consists of three parts. SlimKat has already patched the ADB service in vendor/slim: init.local.rc

Conflicts:
	core/java/android/provider/Settings.java

PS2: Put CM in commit message, reorder import and fixed space indent.

Change-Id: I2983caddbe6079305a8d8caab32f6538a51d7db9
[1/2] Slims Hardware Key Rebinding

First thanks to CM team for the 2 years where we used their approach for our
custom hw key rebinding. This hardware key rebinding
patches did in the past a good job and we extended it prior 4.3 with a lot
Slim custom stuff.

But it is time to go new way and to do the complete
hardware key rebinding more flexible and more centralized. Especially due
that we have now all possible shorcutactions centralized in 4.4

Possible mapping are:
ACTION_HOME
ACTION_BACK
ACTION_SEARCH (in app search)
ACTION_VOICE_SEARCH
ACTION_MENU_BIG
ACTION_POWER
ACTION_NOTIFICATIONS
ACTION_QS
ACTION_RECENTS
ACTION_SCREENSHOT
ACTION_IME
ACTION_LAST_APP
ACTION_KILL
ACTION_ASSIST
ACTION_VIB
ACTION_SILENT
ACTION_VIB_SILENT
ACTION_POWER_MENU
ACTION_TORCH
ACTION_EXPANDED_DESKTOP
ACTION_THEME_SWITCH

and custom app/shorcut of course

Possible actions on all keys are:
normal tap / longpress / double tap

So to sumarize if it is in settings array enabled user can bind whatever of the above
actions to every hardware key action.

Main changes to prior solutions are:
- do not depend anymore on hardcoded integer values. We use now strings. This has
  the advantage that we can save whatever shorcut or intent URI we have into this
  value. And gives us the possibility in future without changing anything on the hw
  key rebinding code to get more options/or modify the options. Actions are holded
  like on all other of our features in ButtonsConstants.java
- All actions are peformed over our SlimActions like all other features. SlimActions
  takes care about all possible solutions the user can run into and sets the right
  open animation, keyguard handling etc etc. As well it is easier to maintain only
  one code base.
- Only observe and update the values on hardware key devices. On non hw key devices
  the complete code is non operational
- Removed in settings the not needed overlay due that we can use the fb one to
  check if it is a hw key device or not.
- Major cleanup of a lot old code.

This patch add as well one new SlimActions action....VOICE_SEARCH

To configure your device you need to add the device overlay as usual:

overlay/frameworks/base/core/res/res/values/config.xml
<!-- Hardware "softkeys" present on the device, stored as a bit field.
         This integer should equal the sum of the corresponding value for each
         of the following keys present:
            1 - Home
            2 - Back
            4 - Menu
            8 - Assistant (search)
           16 - App switch
        For example, a device with Home, Back and Menu keys would set this
        config to 7. -->
    <integer name="config_deviceHardwareKeys">7</integer>

Also requires Settings commit (https://gerrit.slimroms.net/#/c/2389/)
and overlay to function correctly

cheers HCP and kufi

PS:
- code cleanup and some code comments
PS:
- fix softkey devices
PS:
- fix back button (I think lol)
PS:
- fix wrong null checks lol
PS
- revert back to last ps due of more derp
PS
- added some debbugging lines
PS
- redefine injectInputEvent code and get rid of the handler we used to fix
  exception due that PhoneWindowManager is no UI thread and cannot handle the handler
  and to speed up navbar/navring etc. No need to delay it for 30ms
PS
- reworked the complete interpretation code. To fix up the initial issues we had on first patchsets
  and as well the new ones. Nuked vibrations as well and lets handle it like all other over SlimActions
  cleanup again
PS
- I remember that jeff had similar problem in the past and got the solution. We just check now
  who is really calling home key event. If it is a VIRTUAL key then launch home....for all other
  lauch the saved action on the home event. As well this fixes the wrong launch if DoubleTap
  timed out and launches home (now it launches the saved action for home like it should).
PS
- cleanup
PS
- finally fixed home button
PS
- last major cleanup
- cancel recent preloads only if it is really required
PS
- introduce central HwKeyHelper class to avoid code duplication in PhoneWindowManager and as well
  in Settings
PS
- fix small logical error in home key handling to avoid to go over SlimActions if button is set to default
  home
PS
- fix wrong menu default value
PS
- added double tap to all bindable buttons
- fixed reported missing vibration on longpress
- possible fix menu shows up on longpress menu
PS
- small cleanup
PS
- fix home/assist/appswitch call when it is set on the natural button as longpress or doubletapp.
PS
- attempt to fix the problem mentioned in PatchSet above on the other keys + simplify this fix
  Please test
PS
- fix navbar
PS
- fix double vibration if double tap is pending
- fix deprecated System.SHOW_PROCESS value call and call Global instead
- execute on assist and appswitch default action if no other action was executed before
- HwKeyHelper do not call provider values if not needed
- cleanup
PS
- menu and back button: if normal tap action does not equal natural back action return -1
  to avoid processing back/menu action
PS
- reset the indicating boolean for prevend second vibration when we reset the doubletap
  callback - this fixes the reported issue that vibration is suddenly completly gone
PS
- return on back and menu hardware trigger always the action and let it use the virtual
  key to process the final action
PS
- handle virtual key on back and menu a bit other
- rename vibration var
PS
- fix double vibration if double tap is disabled
PS
- fix back key wrong condition on double tap which caused 2 action calls
PS
- do not assume that double tap has always a pending vibration...check for the action
- respect keyguard on APP_SWITCH key
PS
- remove again the keyguard check lol....I forgot that I was some months ago allready
intelligent enough to check this in SlimActions lol. So no need to check it twice

Change-Id: Ic5c9b4eb03d2baa3b0ddfb3e9fcaf10d6e45dcd3
frameworks: translation - RU

I7848523e7bc3d9577361ff55f010a9909d46e665
I4ea69fd8e2e8e96330d10a67b2d1f5a1859c1016

Change-Id: I495ec8f5a87e847dbb351c55f27d7599d5b67425
Base: CS Translation

Change-Id: I7185729436cf9f3e2edbea7bba971a60f8ce4854
fb: handle for our navigation bar recentspreload in the button

Recents screen is since some time wonky. With new hardwarekey rebinding
it showed now only more how wonky it is due that home button does not
cancel the preload always to keep the hwkey button logic alive.
As well a problem is that if you bind recents to whatever other navbar
button the preload takes no effect at all (is only binded from google to
the recent tagged view)

Whatever to solve this let the buttons itself decide dependend on the
action if a preload or cancelpreload is needed an peform the action.

This solves all the weird recent screen behaviours and we will need it for
the new recents screen which is in development as well

It looks a bit weird to aquire the statusbar service here for this but in the
button itself there are not much other alternatives. In theory we could set listeners
like google but instead to all buttons and fetch the action from there to decide but
this gives a problem to get if it was a longpress recents or a normal press recents.

So this way seems to be ok.

Change-Id: I9b3b08356f72840399eaabd0be8b0c3fdf09a4bd
SystemUI: Fix missing top task in recent panel.

If preloadRecentTasksList was not called or was called too
late and RecentsActivty already started and last top activity has
excludeFromRecents flag setted it might be missing
from recent application list.

Change-Id: Idf7153824805ceea9fcaf04ac645b73a5e93a4d9
fb: handle globalmenu in SlimActions not over Powerbutton anymore

We used till now a hacky workaround to show up the Power menu which worked
but is indeed not the best way. Last tweek on it broke 3rd party root application
which use similar hackish workaround.

Whatever make global menu over wm service available and call it from
SlimActions directly. This respects of course the usual security checks
if the device is provisioned etc

PS
- derp
PS
- puh I just should go sleeping :(

Change-Id: Ia12ce467cee0d60741079b3fa2c78449d707a09f
fb: unbreak recents animations on thumbnail click or dismiss recents screen

We load now correctly the recents screen and preload the first task on press
down off any key to get always recents without issues up. We cancel only
if any other key was pressed. I discovered during I am working on new recents
that this solves all issues but has one downside that if he user dismiss he recents
screen or click on one of the thumbnails to bring the choosen app to forground
that of course the last thumbnail is not cleared. Due that the entry animation
and some other things depent on what is currently preloaded we need to cancel
first task to have always in all cases the right animation.

Fix it with just calling cancelPreloadingFirstTask() if the user either
clicked on one of the thumbnails or dismissed the recents screen.

PS
- do the same when all thubmnails are swiped away
PS
- derp

Change-Id: I786c05d929f6a02b6d4928fc4a96aeb9a8e2d03e
Appears black screen fix for a while

This issue is side-effect of added google patch on KK MR1.

Fix a couple of issues with mOpeningApps.
https://android.googlesource.com/platform/frameworks/base/+/a8ee262c04749db4f32f73d2b9e7f58989c4638b%5E%21/#F0

[Reproduce path]
Settings -> Location -> Location OFF -> Location ON -> "Location consent Dialog" Popup-> "Agree btn" press
-> Black screen appears for a while

Change-Id: I14efdce87e8d78d38f9aae48568f69937e4fe1fa
Perform NTP lookup at Mobile data connections

If NITZ isn't supported by the current carrier the Android framework
relies instead on a remote NTP server to set the system clock. The
NetworkTimeUpdateService class polls for NTP time during the first 4
minutes after boot, failing to get NTP time within these minutes will
increase the polling interval to 24 hours. Hence, if a data connection
isn't activated directly after boot it can take a long time for the
system clock to be updated. To prevent this situation, NTP lookup is
scheduled as soon as a Mobile data connection has been established.

Change-Id: I046e0330147e7ace4b720a7e70f9d5047d42cfe6
AssetManager cookies should be int32_t and not void*.

Cookies are really indices into vectors and arrays, so
they don't need to be void*. We choose int32_t instead
of size_t to allow their width to be well specified.

(cherry picked from commit ebfdd0f467e39c3af8d92cade78263935340acb7)
(cherry picked from commit a7fa2e592e2e579e5acdb903dba83fc074ebc215)
(cherry picked from commit a9d5701b034ed2d9771b3f0943e1add00741d7cd)

Change-Id: I2aed3db568b6fdc487bf99e2c5dd123206736fda
Fix dest == src bugs in Matrix.cpp.

The main bug was that the AutoJavaFloatArray autoSrc was not passing in
read only. This meant that the destructor overwrote the data which
the autoDst AutoJavaFloatArray had written in it's destructor.
This case only happened if src == dest and the arrays were copies.
Also improved performance by passing in read only a few other places.

Bug: 12570144

Change-Id: Idc8764087dc165433c584b87a0f9d4ed0ec795e8
Fixed race condition in Spinner.DialogPopup on null reference.

NullPointerException is triggered when DialogPopup is
dismissed due to object mPopup being null when not showing.
Race condition is triggered when dialog is dismissed before
touch event to dismiss dialog has been processed properly.

Fixed by adding a null check prior to accessing mPopup object.

Change-Id: I3c4fe9c279d92a7103fb4f68189d1d42beedc606