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
Declare a new method, Display.getState() to retrieve the actual
power state of a display.
Improved documentation for Intent.ACTION_SCREEN_ON and
Intent.ACTION_SCREEN_OFF to clarify what they really mean in
terms of the interactive state of the device.
Deprecated PowerManager.isScreenOn() and replaced it with
PowerManager.isInteractive() with a more suggestive name and
better documentation.
Redirect display power state changes to go through the display
manager first and only then head over to the power manager for
legacy compatibility.
Eliminated the bright here and woke here policy flags since they
were unused. Simplified the input dispatch policy somewhat.
Ensure that screen wake locks are respected up until the point
when dozing really begins.
Fixed a regression in DreamService where onDreamingStarted
might be called before onWindowAttached.
Bug: 13133142
Bug: 13472578
Bug: 13929355
Bug: 13760290
Change-Id: Iabef96921dd554ce3768fb18619cefc3230b5fb0
Also change MotionEvent.PointerCoords bit packing and unpacking
methods to be consistent with BitSets which are now used on the
native PointerCoords object.
Bug: 11480300
Change-Id: Ib18c99b94ac555104c69eac526860aa501e89e03
This is a cherry-pick of https://googleplex-android-review.git.corp.google.com/#/c/399886/
Instead of storing a kb layout per device descriptor (which is expected
to be unique), store it for each vendor/product. This way we can keep
a consistent layout between identical but physically different keyboards.
There are some corner cases this is expected to fail on, namely devices
that incorrectly have the same vendor/product id. Devices that don't
define a vendor/product id will continue to use the descriptor to store
layout files.
Change-Id: I1f2508561992080459310d5a644dad65a9c24f1a
Allow device overlays to override the behavior of the
hasPermanentMenuKey method at build time. This is useful for devices
that do not behave as the usual autodetection mechanism expects.
Device overlays should set config_overrideHasPermanentMenuKey to 1 if
the device DOES have a permanent menu key or 2 if the device DOES NOT
have a permanent menu key.
Bug 11698700
Change-Id: I467b68528cf681b08adcaebc2402d8bdd84f6b5c
Extract the size from the MeasureSpec value before adding the
delta. The opposite order could result in a negative delta causing
overflow into size from the EXACTLY mode, creating a very large size
value in the resulting MeasureSpec.
Don't reapply optical bounds insets after pulling a value from the
measurement cache. (The insets will have already been applied before
insertion into the cache.)
Change-Id: Ib0154f4d6c3a7c31e7fee24fd7d5d10cc5dc71a1
These new keys behave in similarly to KEYCODE_POWER but do not
simply toggle between awake and asleep states.
Sleep puts the device to sleep if it is awake.
Wakeup wakes up the device if it is asleep.
Bug: 12938999
Change-Id: I260fb918cc858882fe06fa880910df5763a76c5d
This adds a new window feature -- FEATURE_SWIPE_TO_DISMISS -- and a
theme attribute to activate that feature. When the feature is
activated, a SwipeDismissLayout is inflated as the DecorView layout.
SwipeDismissLayout intercepts touch events and steals ones that are
large swipes to the right if its children don't. PhoneWindow registers
handlers that listen for these swipe events, translate the window when
necessary, and finish the activity at the end of the gesture.
Change-Id: I512e758f3c3ffd3b353dba3b911c0e80a88d6f5f
Remove private WM flag (used only by the volume panel) to force
the clearable system UI flags clear.
Instead, always lay out the volume panel as if the bars are visible,
as we do for system dialogs - and don't clear the flags.
Reverts part of I25f29af5b6518aba695b64a75977ae240b742118
Bug:11986621
Change-Id: I842729d729d2a6eb2a687d0b930ddb160c6a1b57
Reverts commits 4567e40eb0 and
a977707d6e, which added special case fallbacks
for game controllers in the Japanese locale.
Bug: 12923922
Change-Id: I229126e589e11fb5de86772ef9c59d09723af941
When a doze component has been specified in a config.xml resource
overlay, the power manager will try to start a preconfigured dream
whenever it would have otherwise gone to sleep and turned the
screen off. The dream should render whatever it intends to show
then call startDozing() to tell the power manager to put the display
into a low power "doze" state and allow the application processor
to be suspended. The dream may wake up periodically using the
alarm manager or other features to update the contents of the display.
Added several new config.xml resources related to dreams and dozing.
In particular for dozing there are two new resources that pertain to
decoupling auto-suspend mode and interactive mode from the display
state. This is a requirement to enable the application processor
and other components to be suspended while dozing. Most devices
do not support these features today.
Consolidated the power manager's NAPPING and DREAMING states into one
to simplify the logic. The NAPPING state was mostly superfluous
and simply indicated that the power manager should attempt to start
a new dream. This state is now tracked in the mSandmanSummoned field.
Added a new DOZING state which is analoguous to DREAMING. The normal
state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP.
The PowerManager.goToSleep() method now enters the DOZING state instead
of immediately going to sleep.
While in the doze state, the screen remains on. However, we actually
tell the rest of the system that the screen is off. This is somewhat
unfortunate but much of the system makes inappropriate assumptions
about what it means for the screen to be on or off. In particular,
screen on is usually taken to indicate an interactive state where
the user is present but that's not at all true for dozing (and is
only sometimes true while dreaming). We will probably need to add
some more precise externally visible states at some point.
The DozeHardware interface encapsulates a generic microcontroller
interface to allow a doze dream for off-loading rendering or other
functions while dozing. If the device possesses an MCU HAL for dozing
then it is exposed to the DreamService here.
Removed a number of catch blocks in DreamService that caught Throwable
and attempted to cause the dream to finish itself. We actually just
want to let the process crash. Cleanup will happen automatically if
needed. Catching these exceptions results in mysterious undefined
behavior and broken dreams.
Bug: 12494706
Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Transform DisplayManagerService into a SystemService and start cleaning
up other local services that it uses from window manager and input manager.
Clean up service thread initialization.
Remove unnecessary static variables from ActivityManagerService.
It's starting to become clear that we really need a better way to manage
service dependencies. Boot phases don't quite cut it.
Change-Id: If319dbd7cbfbd4812fe55ece969e818d4b20755b
For storing pointers, long is used in view/input classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Iafda9f4653c023bcba95b873637d935d0b569f5d
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in VelocityTracker class,
as native pointers can be 64-bit.
Change-Id: I8c454663a97745c7440bb6f99ef49d28e9026876
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
For storing pointers, long is used in MotionEvent class,
as native pointers can be 64-bit.
Change-Id: I88ebfef26070b7f49c14945cad37aa3db209ec90
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in KeyCharacterMap class,
as native pointers can be 64-bit.
Change-Id: Idc1b39874202e96b9231d7801e6707003787659b
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used as
native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I3c0855373c0e4bedc172adb82b103586de9219dc
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
