First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
Added some plumbing to enable the policy to intercept motion
events when the screen is off to handle wakeup if needed.
Added a basic concept of an external device to limit the scope
of the wakeup policy to external devices only. The wakeup policy
for internal devices should be based on explicit rules such as
policy flags in key layout files.
Moved isTouchEvent to native.
Ensure the dispatcher sends the right event type to userActivity
for non-touch pointer events like HOVER_MOVE and SCROLL.
Bug: 3193114
Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
Unable to destroy activity {com.android.browser/com.android.browser.BrowserActivity}:
java.lang.NullPointerException at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:2809)
Add a bunch of guards to not call on to the window callback after the
window is destroyed.
Change-Id: I66ca0705f421bafdfe953d03654c8f78d9e68249
Properly close down overlay windows when decor is detached. Delay
opening popup overlays to prevent issues when restoring instance
state.
Change-Id: I7ff44ce65e78c0172a12a9ddfe11460c885593ca
DigitalClock could sometimes leak when the keylock was recreated.
This happened because onDetachedFromWindow() was called BEFORE
onAttachedFromWindow().
This is the flow that causes the memory leak:
1) The LockPatternKeyGuardView is created and added. This will start
a loop dispatching onAttachedToWindow() to all views involved.
2) PatternUnlockScreen.onAttachedToWindow() is called
3) If the configuration has changed since creation, recreateMe() in
LockPatternKeyguardView.java is called.
4) recreateScreens() is called
5) PatternUnlockScreen is removed (to be re-added later) in
LockPatternKeyguardView.recreateUnlockScreen()
6) Since DigitalClock is a part of PatternUnlockScreen, its
onDetachedFromWindow() will be called.
7) The loop started in 1) will continue to dispatch
onAttachedToWindow() - and will eventually call
DigitalClock.onAttachedToWindow()
8) DigitalClock.onAttachedToWindow() registers a receiver that is
normally unregistered in onDetachedFromWindow(). But since
onDetachedFromWindow was already called in 6), it will not be called
again.
9) The receiver has leaked, and it has a reference to DigitalClock,
so that will leak as well, together with its parents e.g.
PatternUnlockScreen and LockPatternKeyguardView
The fix is to wait with the recreation of the screens (in 4) until
the loop (in 1) is finished. This is done by posting this as an event
instead of calling recreateScreens() immediately.
It is possible that this a fix for the root cause mentioned in
"Fix 3106227: use WeakReferences for receivers in DigitalClock class"
8b886fab5496b0b1f5193f21855220176deddc37 by Jim Miller
<jaggies@google.com>.
Change-Id: I6a5f6f49a565d459bf4e285f34f053cc1022286f
Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View
hierarchy as onGenericTouchEvent. Pointer events dispatched
this way are delivered to the view under the pointer. Non-pointer
events continue to be delivered to the focused view.
Added scroll wheel support to AbsListView, ScrollView,
HorizontalScrollView and WebView. Shift+VSCROLL is translated
to HSCROLL as appropriate.
Added logging of new pointer events in PointerLocationView.
Fixed a problem in EventHub when a USB device is removed that
resulted in a long stream of ENODEV errors being logged until INotify
noticed the device was gone.
Note that the new events are not supported by wallpapers at this time
because the wallpaper engine only delivers touch events.
Make all mouse buttons behave identically. (Effectively we only
support one button.)
Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
Only initiate fallback key handling if the first key down was
not handled and there is no other fallback key already in progress.
This prevents spurious fallbacks from being generated when
applications handle the initial down but not repeated downs or the up.
Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
E.g. if an app is sensorLandscape and the device rotation is
locked to landscape, the activity should not be allowed to
flip to seascape even if the device is inverted.
If the rotation is locked 90° from the activity's
supported orientations, we must override the lock as before,
but we now suppress the sensor input (confining the activity
to one of its two orientations). This best preserves the
spirit of the rotation lock while still allowing the
activity to run in a supported configuration.
Bug: 3453407
Change-Id: I8ee255e0250ba7e4534f4622ac37b82d31cf9936
We were setting ACCELEROMETER_ROTATION to 0 before putting
in the proper USER_ROTATION value, and PhoneWindowManager's
content observer would eagerly rotate the screen to the last
locked orientation before re-rotating to the updated locked
rotation.
Now we set USER_ROTATION first. Additionally, the
content observer is now the only place we set
mUserRotation{,Mode} (previously we would race with it in
setUserRotationMode()).
Bug: 3425657
Change-Id: I04ba1a3631c6d985c2e406c4d148c39fb5c36216
Added support for tracking the mouse position even when the mouse button
is not pressed. To avoid confusing existing applications, mouse movements
are reported using the new ACTION_HOVER_MOVE action when the mouse button
is not pressed.
Added some more plumbing for the scroll wheel axes. The values are
reported to Views but they are not yet handled by the framework.
Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
Added API on InputDevice to query the set of axes available.
Added API on KeyEvent and MotionEvent to convert keycodes and axes
to symbolic name strings for diagnostic purposes.
Added API on KeyEvent to query if a given key code is a gamepad button.
Added a new "axis" element to key layout files to specify the
mapping between raw absolute axis values and motion axis ids.
Expanded the axis bitfield to 64bits to allow for future growth.
Modified the Makefile for keyboard prebuilts to run the keymap
validation tool during the build.
Added layouts for two game controllers.
Added default actions for game pad button keys.
Added more tests.
Fixed a bunch of bugs.
Change-Id: I73f9166c3b3c5bcf4970845b58088ad467525525
Some devices that use LiPo batteries do not charge them to 100%
as a safety margin and to preserve battery longevity. This change
allows KeyguardUpdateMonitor to determine when the battery state should be
reported as "Charged", provided the device sets BATTERY_STATUS_FULL in
that case.
Manual merge of Change-Id: Iac6cb78e24f9a696017459cc773c38ef7fe7779f
Change-Id: I15c316a17108c064bf2c7e657ca908f8767be936
This fixes a bug introduced by a recent change in GB that
fixed a memory leak and subsequent OOM crash. The code in
cleanUp() is now more aggressive about releasing unused
references because the view is expected to go away afterwards.
However, due to the immediate callback from reportFailedUnlockAttempt(),
the member variables are cleared before we reach the end of the
handler. The fix is to postpone reporting the failed attempt
until after the rest of the logic has completed.
Change-Id: Ic35eaf17e9921213c8793d00f9008d957a290b88
Prevent the usual menu pipeline from trying to open the action bar
overflow menu when the action bar is not visible.
Change-Id: I0708d142ad271368baa79351b97aad1533636fe7
* commit 'd6874a105ee584b1dc60aae2f2af7c78ee875114':
Make keyguard also ask to turn the back button off, now that it is controlled separately.
Allow independent control of the back and the other navigation buttons.
Allow the status bar disable flags to be used as View's system ui visibility fields.
* commit 'cfd0bafdebf1fccd3f5a0baed5cad8a539546e9b':
Make keyguard also ask to turn the back button off, now that it is controlled separately.
Allow independent control of the back and the other navigation buttons.
Allow the status bar disable flags to be used as View's system ui visibility fields.
Some devices that use LiPo batteries do not charge them to 100%
as a safety margin and to preserve battery longevity. This change
allows KeyguardUpdateMonitor to determine when the battery state should be
reported as "Charged", provided the device sets BATTERY_STATUS_FULL in
that case.
Change-Id: Iac6cb78e24f9a696017459cc773c38ef7fe7779f
This fixes a bug in StatusView believed to be caused by
seeing "invalid charger" update from BatteryService.
The code normally relies on "interesting events", as determined
by KeyguardUpdateMonitor. I believe something else is
triggering an update (perhaps a SimStateChanged event) that updates
the status without also updating StatusView.mShowingBatteryInfo
and mPluggedIn.
The safer way to do this is to explicitly check the battery
level before telling the user the device needs to be charged.
Change-Id: Ic39ed86c78a157dc9fbdef4d76a9c3db39ccafca
When invoking a registered shortcut for which the activity was not
found, the startActivity throws ActivityNotFoundException. If this
exception is not caught and handled, then the shortcut key is
dispatched to the application instead of being suppressed as it
should have been.
Found while fixing Bug: 3396233
Change-Id: I0e8e9e3ba09dd403a901d5eae12839734be467ed
