Through invalidating panel menus and action bar initialization it was
possible for instance state restoration to throw out a new menu
already in use. Invalidate the menu if it already exists instead. The
saved instance state will be applied later if a relevant panel menu is
shown.
Change-Id: I6bad7640ecb8d2f5f8ea658e1c68b07d52d108b9
Split action bar implementation details. Factor out common components
into AbsActionBar. Layout rules for the lower half of split action
bars.
Change-Id: I6bc39ba6c343055597880a7d4663dd8f30aa4999
Apply (or extend) the theme Theme.Holo.SplitActionBarWhenNarrow or
Theme.Holo.Light.SplitActionBarWhenNarrow to enable splitting the
action bar across both the top and bottom of the screen. This places
the action menu along the bottom, leaving more room at the top for
titles, navigation, and custom views and more room at the bottom for
menu items.
TODO: Refine layout of the action menu when placed at the bottom of
the screen. Make action modes split as well.
Change-Id: I92c91f99c533f26aecf6b828ed041386c4f16922
In Honeycomb we introduced navigation controls in the status
bar, for xlarge devices without physical buttons. What about
phones? The status bar is pretty cramped already, and
besides, it's at the top of the display most of the time,
not at the bottom where your thumb is likely to be.
Enter the navigation bar. It's a new window type that
appears atop almost everything (including the keyguard); the
window manager subtracts its rectangle from the default
visible rectangle of other windows (including the status bar
and notification shade).
However, it behaves (on phones) like the status bar in that
applications that request fullscreen windows can get access
to those pixels. Well, almost; they need cooperation from
the navigation bar implementation to make the navbar
disappear, just like the status bar.
The current SystemUI implementation of the navigation bar on
phones is still rough, but it has the basics:
+ back, home, and menu keys (NB: we're showing menu all the
time right now because checking the api level of the
package owning the top window is currently a poor
indicator of whether the app requires the menu key)
+ it tries to stick to the same physical end of the device,
regardless of device orientation (on a phone, this is
the strip of land closest to the microphone)
Change-Id: Ic613a3351220af0bbfbdef63e1d99cbefd5ed1c2
Not yet working, so turned off.
Also fix a bug where the display size configuration became inconsistent
after a configuration change -- we now figure out everything about the
display size when computing a new configuration.
In the old world, MenuBuilder and MenuItemImpl were responsible for
generating views for any presentation of a menu. MenuBuilder needed to
know any types and resources involved, and the implied caching
semantics did not work well for menus presented within AdapterViews.
In the new world, the MenuPresenter interface takes over the
responsibility of generating views or adapters for menu
items. MenuBuilder/MenuItemImpl still provide extra metadata tracking
used by these presenters. Mutiple presenters may be active for a
single menu at a time. All of this remains internal framework
implementation details.
BaseMenuPresenter provides a simple base for presenters that treats
the host MenuView more like an AdapterView. This allows for less
rebuilding of views when items are added/removed.
Callbacks have been restructured. Calls that relate to the menu itself
are still handled by MenuBuilder.Callback, but calls related to a
specific presentation of a menu are handled by MenuPresenter.Callback
objects attached to a MenuPresenter.
Also add API to programmatically set divider options for LinearLayout
and hidden API so that ActionBarView can have finer-grained control
over divider placement.
Change-Id: I2265b86a084279822908021aec20dfbadc1bb56b
Alt-TAB should have different semantics from the APP_SWITCH key
or long-press on HOME. Accordingly, remove the fallback action
for Alt-TAB and initiate the task switching behavior directly
in the policy.
Modified RecentApplicationsDialog to be more precise about the
initial modifiers that it considers to be holding the dialog.
The dialog is now dismissed by a second press on the APP_SWITCH
key or by a second long press on HOME.
Change-Id: Idf4d803f51103819057cb655ff3b770b7729e4be
Also be more careful about canceling fallback keys during focus
transitions, when the application handles the key, or when the
policy decides to do something different.
Fixed a crash due to JNI CallObjectMethod returning an undefined
value (not null) when an exception is thrown.
Fixed a crash due to the policy trying to create a Dialog for
recent apps on the dispatcher thread. It should happen on the
policy's Looper instead.
Bug: 4187302
Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
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
