Bug: 28053584

To avoid holding the resource (surface) for too long.

Test: CTS on x86_64 emulator
Change-Id: I2fdec107c2a16b7dadbf78a9aee79c33423a3676
(cherry picked from commit c48a09cc)

This reverts commit e15e7cb5.

Change-Id: I116904fd8c2b28df7e03bc5ec2414ed67761b380

Such that we know how much startup latency is the system to blame
and how much of it is the client process to blame.

Test: Open dead app, inspect logs
Change-Id: Ib8d359c2d59ef6f90893928f2b1d4e2ac2590d74
Fixes: 37327717

Don't include the wallpaper window when calculating the frame
in multi-window.

Test: Go multi-window, go recents.
Change-Id: I8b4fb48767d6bdbda055d9c631811ad5a1dcaee6
Fixes: 36240988

- Better explanations of some strings.
- Fix to use the right package when an item is pressed in
  the foreground services dialog.
- Improve java docs on Service.startForeground().

Bug: 37925387
    735566 lv - Android - [Source] Context unclear or missing:
    Apps running in background
Bug: 37925888
    735566 lv - Android - [Source] Context unclear or missing:
    Tap for details on battery and data usage
Bug: 37897953
    735566 gl - Android - [Source] Context unclear or missing:
    LEFT_SIDE, RIGHT_SIDE
Bug: 37943079
    Music is dying mid playback

Test: manual
Change-Id: Ied41932c61f59335bd18dfba3fcb13af28a0bddd

Change-Id: I9b5ebe94df837619db36f6d104daff7637c449b5
Auto-generated-cl: translation import

* changes:
  Fixed a bug where the media notification image was wrong
  Improved the gradient drawing of the media notification

Change-Id: I5197115980fb305b5bbd25b15c4bffb1a7985743
Auto-generated-cl: translation import

When a FocusRequester gains focus, always unduck it.
This fixes a bug where a player could remain ducked even after
  regaining focus. The issue was that the unducking was only
  done in the focus gain if the loss had been
  AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK, which is the only one
  that could have caused a duck. But between the moment
  the app lost audio focus with LOSS_TRANSIENT_CAN_DUCK and
  the moment it regains focus, it could have lost the focus
  once more with LOSS_TRANSIENT. And in this case, it would
  not have been unducked.
The fix consists in always unducking an app that gains focus. If
  it wasn't ducked, that operation is a no-op.

Test: see bug
Bug: 37433811
Change-Id: I95a5bfcc2d5063986bd62841c1893bbbd00b45bf

In RTL the gradient was being applied the wrong way.

Test: switch to RTL, play music
Change-Id: Ie1686719d56436712fd0e6c99ba2723ba53d0025
Fixes: 37996998

Previously we were drawing with a color on top of the
image instead of fading it out. This could lead to
visible artefacts in the background.
We're now fading out the alpha in a similar manner instead.

Test: runtest systemui
Change-Id: Ie6af7751a734b8fa44279eba970e7ca5ba67a4c0
Fixes: 37950482

Change-Id: I25d7e172be92bc7c637b272de450966b409982a6
Auto-generated-cl: translation import

CheckedTextView style defaults are not derived from TextView, so they
were not getting hyphenated at all. Now they are hyphenated the same
way a normal TextView is hyphenated.

Test: Manual
Bug: 37763646
Change-Id: I3d14e5a1764561cc2922eea569d124c77cb53631

Refactor management of list of ducked players:
  DuckingManager has a list of DuckedApps, which reference
  the ducked players per uid.
Only consider ducking a player when it is in STARTED state.
When a player is released, remove it from the list of ducked players.

Test: play audio in GPM while having driving directions, music ducks
Bug: 37433811
Change-Id: I038a963432c0df6c9470a3a4fb80049d55e8719c

This CL gets rid of unnecessary operations from
LocaleUtils.filterByLanguage() to speed it up, especially for the case
where there is an IME that has many subtypes.

ULocale.addLikelySubtags(ULocale) is known to be slow. Given an IME
that has N IME subtypes, LocaleUtils.filterByLanguage() calls it no
less than N times even when the only one system language is selected.
This has contributed to device boot time (Bug 32343335) time and user
switching time (Bug 28750507) since Android N where IME support
started taking multi-locale into account.

With this CL, LocaleUtils.filterByLanguage() no longer calls it
for a subtype unless its language part of the locale matches one of
user-selected system locales.

The only assumption we made here is

 for any Locale objects l1 and l2
   TextUtils.equals(l1.getLanguage(), l2.getLanguage())
 and
   TextUtils.equals(ul1.getLanguage(), ul2.getLanguage())
 are equivalent, where
   ul1 = ULocale.addLikelySubtags(ULocale.forLocale(l1)) and
   ul2 = ULocale.addLikelySubtags(ULocale.forLocale(l2))

This should be reasonable assumption, at least for locales we want to
care about for IMEs. Under this assumption there is no behavior
change at all.

Test: bit FrameworksCoreTests:com.android.internal.inputmethod.LocaleUtilsTest
Bug: 37647204
Change-Id: Ic96900fcaf3db8b7046a50b3fe6ad65aceada369