----
Explicitly track consumed state for WindowInsets
Treating 0-insets as fully consumed is incorrect since it means that
you can't dispatch empty insets down the view hierarchy - traversal
terminates immediately. Track consumed state independent of actual
values. Replacing a given set of insets with all zeroes will mark it
consumed.
----
Fix incorrect dispatch of empty WindowInsets from ActionBarOverlayLayout
Fix a bug where ActionBarOverlayLayout was using a private constructor
of WindowInsets to return empty insets that should have been marked
fully consumed. This caused dispatch to further child views not to
stop appropriately, corrupting application layout in some cases.
---
Fix CTS regression in fitSystemWindows
Don't attempt to apply null insets from a call to fitSystemWindows.
Immediately return false since null insets cannot be applied.
----
Bug: 15452706
Change-Id: I34276a90305b141b4653aef0048f70350c69d02a
- This is needed to pass CTS tests on the wear devices
- Related CL: http://ar/479486
Bug: 15087985
Change-Id: I56673ff6085618a03ec61031e3af0f6631cb3425
The presence of ".bc" files in an APK implies
incompatibility with any of the 64 bit ABIs.
bug: 14900093
Change-Id: I66ca339a9a149cb3b7e7b349033d80acdeb4140a
This allows callers to force an install to a particular
ABI. This is intended only for testing (and CTS) and is
not meant for usage by the installer package.
Change-Id: Icb1528c0cd35b1aa9323386cb35ff4aaba374fcb
When ResolverActivity is created with a custom list of matching
applications (rList) as in NFC case, and the alwaysUseOption is
set to true, the prferredActivity is not saved even if the user
presses the "always" button.
When a list is provided the variable mBaseResolveList will be
!= null. This will set mOrigResolveList = null.
When an activity is choosen and one of the buttons are pressed
onIntentSelected is called. The first thing this method does
is to check mAdapter.mOrigResolveList != null, however in this
case mOrigResolveList is always null, and the value is not
saved as PreferredActivity.
This problem was introduced in
6d8dfbd8149942f25f2b9643a12f1fb38f3be834.
Change-Id: I9eac41b7861b5e68ad3978af0dc0285f2a34eb88
The zygote that's responsible for starting up the system server
now checks if there's another zygote on the system, and waits
for it to start up. Also, a few minor clean ups :
- Address a long standing TODO about zygote retries.
- Have functions throw IOException where appropriate and
wrap them in ZygoteStartFailedEx with a filled in cause.
bug: 14869939
Change-Id: I9e514659b79b3d2c98a4c5f93c0c376843f6c881
verify the user's gesture took up at least 40% of the screen
before dismissing
Part of b/14319825 Cliff guard against accidental card dismissals
Works in conjunction with GridViewPager change:
https://googleplex-android-review.git.corp.google.com/#/c/461036/
Change-Id: Id8ff02d0a2d727b54c9950ad14ddef7a110f4eef
Fixes an issue where dozing was treated the same as the screen
being fully on. Now dozing is treated the same as the screen
being fully off which is slightly better. The decision of how
to represent this state is now internal to the battery stats
so it can be improved later.
Removed noteInputEvent() since it is unused.
Bug: 14480844
Change-Id: Iee8cf8dce1a1f91c62678bb6d3d9fe567ad6db42
Starting from kernel 3.6, it requires processes to have the capability
CAP_BLOCK_SUSPEND to set/unset wake locks. Adds CAP_BLOCK_SUSPEND
to the list of capabilities for system server, so that PowerManager
can set wake locks.
Change-Id: I3246e6f6e6cb8f0bedb1c0417ed07085ee1f3aaa
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The change adds the view cookies for the menus rendered in the action
bar. This enables the IDE to map the menu to the relevant XML Tag in the
menu xml and show the highlighting accordingly.
The change also contains a bugfix where a method wasn't renamed
properly.
Change-Id: Idcfc263a8ebe0a4f25afa3a1eb085fa628fd03ca
(cherry-picked from commit 1001961f904bac5294aaf73a47c2497aa764bf7f)
This also makes a couple of changes to the framework:
1. ShareActionProvider - Use edit mode to execute activity chooser code.
2. ActionBarImpl - add a new constructor for use by layoutlib.
This also relies on some changes to the plugin to pass the correct params.
Change-Id: Ia30fef816afd91ec1e439734d56b59b1323bfee2
(cherry-picked from 14bf0cef7eeed572a67c29a328581afac4decc20)
Applying insets is now handled by:
* WindowInsets class - Encapsulate system insets and local decor
insets into a single object, written specifically so that new inset
categories may be added later. Apps cannot construct their own
WindowInsets, only clone with optional modifications. This is to
prevent losing data in the event of new insets added in the future.
* onApplyWindowInsets - Actually perform the application of insets.
* OnApplyWindowInsetsListener - Allow an app to use a separate
Listener object to apply insets to a View. This allows for things
like support lib integration in custom views written for older
versions where the verifier would otherwise complain about the use
of the new WindowInsets class as a method parameter. It also allows
for applying insets in a custom way without writing a custom view.
* dispatchApplyWindowInsets - Dispatch the call to self and children
in turn, if applicable. An OnApplyWindowInsetsListener will override
the behavior of the view's default onApplyWindowInsets method; a
listener wishing to call down to the 'superclass' implementation as
part of its own operation should call view.onApplyWindowInsets. App
code should generally not override this method and instead override
onApplyWindowInsets or provide a listener.
Compatibility support with the existing fitSystemWindows method has
been provided in both directions: for code that previously called
fitSystemWindows on arbitrary views and also for code that overrode
the fitSystemWindows method in custom views. A view that supports the
newer onApplyWindowInsets mechanism should not mix that behavior with
other calls to fitSystemWindows or vice versa. Support lib-style code
should take care to consistently use one mechanism or the other at
runtime.
Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105
Previously, the view hierarchy would suppress drawing whenever the
PowerManager.isScreenOn() method returned false. However, this method
really describes the interactive state of the device rather than the
actual display state. This is especially a problem when there are
multiple displays but it also breaks drawing while in doze mode.
This change makes the view hierarchy consider the actual state of the
display instead on an individual basis.
Bug: 13133142
Change-Id: I69870b6b14a3504607a30562aa48c3452f777c1f
