| 7ba4c2b254f87f66714266a0c06f687f470f2037 |
|
30-May-2018 |
Evan Rosky <erosky@google.com> |
Merge "Fixed a bug where sometimes unhandled handler would consume all keys" into pi-dev
|
| cd80e611cab3cc09366af23f2ef0b0f8e5146c86 |
|
18-May-2018 |
Evan Rosky <erosky@google.com> |
Fixed a bug where sometimes unhandled handler would consume all keys
In a situation where a focused view consumed only the UP of a key
and the unhandled key manager would focus a listener, it wouldn't
drop focus unless the original key was pressed/released again.
This updates the record of captured keys before it can be consumed
in the view hierarchy.
Bug: 79993136
Test: Added a test for this to cts ViewTest#testUnhandledKeys
Change-Id: I5dfdcf16c5c41e9ad51cb62b385580c5493e8520
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| f7b7426d81c5365473d00362cf158aa5ae35cee3 |
|
22-Nov-2017 |
Adrian Roos <roosa@google.com> |
Display Cutout: Fix ActionBarOverlayLayout to properly dispatch cutout
ActionBarOverlayLayout used to drop WindowInsets, extract the content insets
as a rect, and then dispatch a modified rect to the content view; this because
there was no way to retarget the WindowInsets to the content view, and the
WindowInsets were not truly immutable. That means however, that other kinds of
insets than the content insets do not get dispatched, such as the display cutout.
To fix this, we add APIs to inset WindowInsets, make them immutable. Note that
a similar change is needed for the support lib.
Bug: 79733300
Test: atest ActionBarOverlayLayoutTest
Change-Id: I6a69d8462163ca5e66fdb53f83def6bc4063f8aa
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 0d58b9bb647e49688d01661f51398df19701fcec |
|
03-May-2018 |
android-build-team Robot <android-build-team-robot@google.com> |
Merge "BackgroundFallback: Cover all cases where the fallback is needed" into pi-dev
|
| 786ea783ea109c67a50871b9a35dfb3c485b9585 |
|
30-Apr-2018 |
Adrian Roos <roosa@google.com> |
BackgroundFallback: Cover all cases where the fallback is needed
Fixes an issue where uncovered regions were not
covered if they are to the right or bottom of the
content view.
Fixes: 78661186
Test: Install test app from bug, enable cuotut, open test app, go to landscape, verify white fallback background is drawn in both landscape and seascape
Test: atest BackgroundFallbackTest
Change-Id: I442f03395a71550a534d64233762aa84002319dd
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| a213d306d556a140bafe8079b00b3654c62b534c |
|
23-Apr-2018 |
chaviw <chaviw@google.com> |
Update DecorContext's Resource cache when calling getResources.
DecorContext is created with the resources from the activity. However,
the resources in DecorContext may not get updated properly
ResourcesManager if the original resource object it's pointing to isn't
updated by ResourcesManager. Because of this, resources for the
DecorView can be incorrect when the activity's resources are updated.
This change updates the DecorContext's resources with the activity's
resources when getResources is called to ensure they get properly
updated.
This fixes the issue where windowing mode was incorrect when determining
what the window elevation should be. It was incorrectly getting full
screen when it should have gotten pinned. This was preventing surface
insets from getting set on the WM side, so PIP windows didn't get
shadows.
Change-Id: I5af2364f81b167e3732811d7413554d035c4a021
Test: PIP has shadows
Fixes: 78214575
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 32bcb10e336741c8e43a35ee1048c7ce36257e39 |
|
30-Jan-2018 |
Robert Carr <racarr@google.com> |
Restore pinned stack shadows.
We use the approach of outsetting the stack bounds and then
insetting windows which don't have surfaceInsets by said outsets.
Test: Manual. go/wm-smoke
Bug: 72657549
Change-Id: I9ac7e13ec696f88f02794175d0d44ac870f91d33
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 8f162c6e846ac99d6aac4473d7903722e9d6e54b |
|
10-Jan-2018 |
Yohei Yukawa <yukawa@google.com> |
DecorView#mNavigationGuard is gone
With this CL, DecorView#mNavigationGuard that handles navigation bar
only for IME windows [1] is finally gone and replaced with the
standard mechanism to handle navigation bar layout padding /
background color.
This CL addresses multiple anomalies regarding how the following APIs
work for IME windows.
* Window#setNavigationBarColor()
* Previous behavior:
- Only works for Color#TRANSPARENT [2].
- Ignores FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS.
* New behavior:
- Works as documented.
- Requires FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS to work.
* SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION flag
* Previous behavior:
- The system automatically sets
SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION to the IME windows [3].
- Does not work as documented. Content area is not extended to the
navigation bar area.
- Manually unsetting SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION can cause
unexpected layout, because the system expects that this flag is
always set to the IME window.
- Had a special logic for FLAG_LAYOUT_IN_OVERSCAN [4].
* New behavior:
- Works as documented.
- Can set/unset as necessary.
From the viewpoint of IME developers, this CL enables IME windows to
* correctly extend the input view to the navigation bar region by
using SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION as documented, instead of
relying on a special hack with FLAG_LAYOUT_IN_OVERSCAN hack.
* use Window#setNavigationBarColor() to easily change the navigation
bar background color, like other non-floating windows.
Note that SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR is not yet supported for
IME windows, which will be implemented in a subsequent CL.
[1]: I6a93f30aec83f1cecfb854073046cbc87ab4aa66
ae3349e1c34f7aceddc526cd11d9ac44951e97b6
[2]: Iea77915ecc55eedaf19899e72c44f704ba9d852c
0a9d1ea015af24056018ec02f6d9afd2f62243ba
[3]: I460912ee7c117480c57b947ed31eca330819f32c
c68d577f29604d205573ee4253704c5b2c5e4f81
[4]: Ic38f204a892bf34e8dae65990d5aa8c95af555d8
9b32a35aa7d47d39da919e777e2fe271cc83fa1c
[5]: I4b10a19641bd3ce6c43e7629404b6f202d4186e8
Fix: 25706186
Bug: 69002467
Test: ThemedNavBarKeyboard sample [5] works for the following cases
* Extended Dark Navigation Bar
* Separate Dark Navigation Bar
* Floating Mode (if the target app uses dark navigation bar)
Change-Id: I664630099b6eb3fe31675444ba94944cb0eb98b0
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 5e29c076cb0210b8698fdced8e985327bf2d75dd |
|
03-Jun-2017 |
Evan Rosky <erosky@google.com> |
Add "KeyFallback" handling ability to Views
This gives any view the ability to receive unhandled KeyEvents.
The order of Views receiving fallback key events is inverse
drawing order: this means higher views will receive fallback
events first.
FallbackHandlers can be added to any view via
addKeyFallbackListener. Within a view, listeners are tapped
in reverse order (such that more-recently added listeners will
receive the event first).
Bug: 32722450
Test: Added a CTS test ViewTest#testKeyFallback
Change-Id: Ibfff4db70de8fb98db0035e5aeb09271be1574c6
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| ea506c67ecc4697f661effc056e84be42101d8a2 |
|
01-Sep-2017 |
Jason Monk <jmonk@google.com> |
Make settings themed apps have light nav
This is needed to help with differential aging.
The nav needs to be white with a 1dp divider on it, so add support
for the divider and add hidden attribute to set the nav buttons
inverted.
Test: Open settings
Bug: 63630024
Change-Id: Iec6046baeb86fb554df73346df8652fee8b2736a
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 8fe8b86d5587f4188bf8f5194001feff84cb54d8 |
|
08-Sep-2017 |
Matthew Ng <ngmatthew@google.com> |
Merge "Always enable nav and status bar opaque/translucency" into oc-mr1-dev am: 8823588e36
am: 204b740fb1
Change-Id: Ifb744f93e5c29ac613b3391af31e571813302f21
|
| e6b393b1a9ba88d93b97ba95d8fe13ed25828300 |
|
01-Sep-2017 |
Matthew Ng <ngmatthew@google.com> |
Always enable nav and status bar opaque/translucency
Removed the logic to enable or disable translucency and have it fully
enable all the time. Having it on has very or no impact on RAM.
Test: boot device and look at nav and status bar
Change-Id: Id9e613abc689ab8c1b53424aa92e864f75f8ed02
Fixes: 65286386
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 66f4e1c3b55b7c1810fb8265a1ae298de7413a78 |
|
07-Sep-2017 |
Tarandeep Singh <tarandeep@google.com> |
resolve merge conflicts of 9a0d4240dd24 to master
Test: I solemnly swear I tested this conflict resolution.
Change-Id: I0c20323087f1a2d8eb1ead6cfc60a69e42d2d51b
|
| 4efdd567eab0e00d6df71c62c2b71751f2ba34a0 |
|
07-Sep-2017 |
Tarandeep Singh <tarandeep@google.com> |
Revert "Make settings themed apps have light nav"
This reverts commit 45484206740874ddd4024fedfdd8676d935ea67b.
The above change causes restart due to ClassCastException.
Test: Manually:
1. Open the Dialer app.
2. Focus into the edit field to show the IME.
3. Open the notification shade.
4. Tap the gear icon to show the system settings.
5. Make sure the system no longer restarts due to
ClassCastException.
Bug: 63630024
Fixes: 65413752
Change-Id: I4a17ba2f8d70f99009f091c2aaad5cd5f4e9b31c
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 3ab68966b87a75950a262b608edf0a271fa1bc9f |
|
06-Sep-2017 |
Jason Monk <jmonk@google.com> |
resolve merge conflicts of f2cd0f616e4c to master
Test: I solemnly swear I tested this conflict resolution.
Change-Id: Iffb48ac8e596f854f5cbc37d93ddf0a4e3ee75af
|
| 45484206740874ddd4024fedfdd8676d935ea67b |
|
01-Sep-2017 |
Jason Monk <jmonk@google.com> |
Make settings themed apps have light nav
This is needed to help with differential aging.
The nav needs to be white with a 1dp divider on it, so add support
for the divider and add hidden attribute to set the nav buttons
inverted.
Test: Open settings
Bug: 63630024
Change-Id: Iec6046baeb86fb554df73346df8652fee8b2736a
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 379f158b7780edad08deb2618bee0dd5d5fdb709 |
|
31-Aug-2017 |
Tarandeep Singh <tarandeep@google.com> |
Merge "Add multi-display support to FloatingToolbar." into oc-mr1-dev am: 01b6ff0178
am: a040bae50a
Change-Id: I29cea04f2a2401ee8aa50794db3612216e50a29c
|
| c9c83a9ccbf8040c4130cb896e40019250d9d636 |
|
29-Aug-2017 |
Tarandeep Singh <tarandeep@google.com> |
Add multi-display support to FloatingToolbar.
DecorView has no support for multi-display (bug 65172902).
Until that is done, the easy fix for displaying cut, copy, paste
on non-default display is to modify FloatingToolbar.
FloatingToolbar uses context of Default display. Changed it
to use context of the window (which makes it multi-display
compatible).
Fixes: 64837794
Test: Manual using AAe's KitchenSink test app
bit FrameworksCoreTests:android.widget.TextViewActivityTest
bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I513f1aac1c0d22355c996247e3bf56c6d812348f
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 3382ab1fc7cbd45194d502f18e7ea21c2b9a04ca |
|
27-Jul-2017 |
Wale Ogunwale <ogunwale@google.com> |
Migrated some windowing methods from StackId to WindowConfiguration
First pass at transitioning away from using stack ids for windowing mode
to WindowConfiguration. Added some TODO that will require the introduction
of applicationType in WindowConfiguration before additional conversation
can be done.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowConfigurationTests
Test: adb shell am instrument -w -e package com.android.server.wm com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: go/wm-smoke
Change-Id: I2b315623faa16445a9f942e082089123842cb5a1
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 4d8681ff6ae8f47566fdc97264fc6b3b4f3b9e9b |
|
24-May-2017 |
Winson Chung <winsonc@google.com> |
Workaround to ensure that PIP activities have a visible shadow.
- When the window for the activity enters PIP, update the outline provider
to override the alpha of the shadow (to be opaque) to ensure that is is
visible. Only applies to the task root activity.
Bug: 36741700
Test: Launch YT, ensure that there is a shadow when after it enters PIP
Test: go/wm-smoke
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: If089dae84e4916d3d0e7bbeb316215b46e522e05
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 17293cc8a214e3ad1e86dd0a4999fa86063bf70f |
|
22-May-2017 |
Abodunrinwa Toki <toki@google.com> |
Ensure FloatingActionMode has a non-null FloatingToolbar.
Test: none
Bug: 38472422
Change-Id: I8b1844e0cbbff6dedeb0a89536a4bc27535b56df
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 853d17d838ca53dcafabaf62f45518bbf58622c7 |
|
19-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix underdraw during resizing
Since we hide the navigation bar background during resizing, we
need to fill it with the fallback background.
This was always an issue but somehow in OC we are displaying
garbage instead of black.
Test: Open Contacts/Dialer, resize, make sure no underdraw is
happening. Also test a couple of other apps.
Fixes: 36206155
Change-Id: I6b02060ef4acf36c2529d49063a61034f9261696
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 134cee27b8a54ff4c8bebda51c5fe4a4e6f1fd8a |
|
06-May-2017 |
Philip P. Moltmann <moltmann@google.com> |
No need to deal with windowTokens
we have a link to the client which is enough to find the views.
Also there was some cases where the windowToken was not updated
properly. This is moot now.
Also: Read a array of views from the client to speed up the
client<->AutofillManager communication.
Fixes: 38070352
Test: CtsAutoFillServiceTestCases
1 Started autofill, saw fill UI
2 Home button
3 Kill activity in background
4 Recents -> back to activity
5 Saw fill UI restored
Change-Id: I7c2c9411204fa5d65867efae9b7296399121c3a2
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 232b5f820e38398a98791cfc3d03b4ea8307b31b |
|
18-Apr-2017 |
Robert Carr <racarr@google.com> |
DecorView: Avoid changing shadow size in Pinned Stack.
It seems at the end of the animation, sometimes we will
come to think we have focus, before we have properly
updated mStackId. This in-and-of itself seems like
somewhat of an issue...but I'm not inclined to dig too
deeply at the moment. For now just ensure a static shadow
size in the pinned stack.
Bug: 37425446
Test: Manual
Change-Id: I379f7a6de51670c90eacb52a5be5e17784be8ac5
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 51efddbd3bb304de2dd47fa8cd1114ac555958bb |
|
05-Apr-2017 |
Alan Viverette <alanv@google.com> |
Remove unnecessary casts on calls to findViewById
Just frameworks/ this time. More paths to come.
Bug: 24137209
Test: make -j32
Change-Id: Iff27abd26fa43296ac2fff8f534fc6742d2ae80c
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 936f27cbf73b335c7a1404af8406baa0f3576e05 |
|
12-Apr-2017 |
Michael Wright <michaelwr@google.com> |
Always request keyboard shorcuts, even if there's no menu.
Bug: 36964520
Test: cts-tradefed run cts-dev --module CtsAppTestCases -t android.app.cts.ActivityKeyboardShortcutsTest#testRequestShowKeyboardShortcuts
Change-Id: Idc2224260470dfd58a08cd8b2df5d8de67fbaea4
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 971fe468a493e8f1164ec4ae147e404505b551a0 |
|
11-Apr-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Revert "Revert "Handle case when snapshot dimensions don't match""" into oc-dev
|
| 30d64f3a93f5fc5aaf75eeb38d658ef04a884b41 |
|
07-Apr-2017 |
Jorim Jaggi <jjaggi@google.com> |
Revert "Revert "Handle case when snapshot dimensions don't match""
This reverts commit ba53d8ae410976709e1413b74173a791e8dead15.
Also fixes that we always had a size mismatch.
Test: TaskSnapshotSurfaceTest
Test: Open app in different orientation than snapshot, make sure
looks ok.
Bug: 36991071
Change-Id: If572b68fd72cec7679984fdff0be5905caba69f4
Fixes: 36703868
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| c2ec7bf965b00d7cbac699c25aa372a9b5f9fcc3 |
|
10-Apr-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Fix activity move between displays" into oc-dev
|
| 51c1b670224fa1598644426b472d51346dd22f30 |
|
08-Apr-2017 |
Andrii Kulian <akulian@google.com> |
Fix activity move between displays
1. ActivityConfigCallback might not have been registered
because DecorView was not yet attached to window and ViewRootImpl
was not available. In this CL the callback is set as soon as a
DecorView is attached to window.
2. When private display was removed from system, its stacks were
moved to bottom in AM but moved to top in WM.
3. When reparenting stack visibility of activities should be updated
before reparenting in WM, because otherwise WM will be resizing
windows that should no longer visible and reporting it to clients.
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Test: #testContentDestroyOnDisplayRemoved
Change-Id: I6ccc27d873d0d60d7650659fb25cbfcaaeb0fd07
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| eab62baabf290ea6671577a66cfc9fdd1b145d0e |
|
20-Mar-2017 |
Philip P. Moltmann <moltmann@google.com> |
Restore session on new window after app kill
Also:
- Give the session an integer ID as the activityToken is not stable over
restarts of the activity
- Verify that session is only accessed by one UID
- stabilize AccessibilityViewIds over activity lifecycle at least for
the IDs we can do that. This required to split the ID namespace in
"per-app" and "per-activity" views. Only the later ones can be
restored.
- Do not end session when app is killed (as it can be restarted)
Bug: 35484143
Fixes: 36392498
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases --test=android.autofillservice.cts.SessionLifecycleTest
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
Change-Id: I229acc1b3ce35fb57262da7d7466b5d4328b49d4
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| ba53d8ae410976709e1413b74173a791e8dead15 |
|
06-Apr-2017 |
Jason Monk <jmonk@google.com> |
Revert "Handle case when snapshot dimensions don't match"
This reverts commit aea6b74e17a0f7b105999adad50dd20eac17df35.
Bug: 36991071
Bug: 36703868
Change-Id: Ie71992144e78a6580bfce17dfdf20396af80eacd
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| aea6b74e17a0f7b105999adad50dd20eac17df35 |
|
21-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Handle case when snapshot dimensions don't match
If the snapshot starting window has different dimensions than the
snapshots we have taken, we do the following:
- Create a child Surface that has exactly the dimensions of the
snapshot.
- We fill the parent surface with the app background color, as well
as all screen background decorations (status bar background,
navigation bar background).
- We also clip of the status bar/navigation bar background in some
cases, as it looks ugly if it's not behind the system bars.
- Furthermore, we inherit all layout flags on the window and all
layout relevant SystemUI flags on the window such that it's very
likely that the size will match, and the system bars are drawn
correctly.
- In order to make the transition from the snapshot to the real
window a bit more predictable/less messy, we enforce a minimum
duration the snapshot is visible, which is slightly more than our
app transitions.
Test: TaskSnapshotSurfaceTest
Test: Open app, go home, go landscape, open app again
Test: Go to multi-window, open app from recents with a snapshot
taken in fullscreen.
Fixes: 36703868
Change-Id: Ia2d4add6971a18ab7aa2942d2b644d6e87a402af
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| f00cd14f17c0acd6bffe78947d32ea0a2900d139 |
|
03-Mar-2017 |
Phil Weaver <pweaver@google.com> |
Basic accessibility support for picture-in-picture
Exposing actions from the PIP InputConsumer to accessibility,
stripping all actions from a covered PIP app, and adding the
InputConsumer's actions on the PIP app's root view.
We were also using an "undefined" accessibility ID to mean
three different things: a root view, a host view of a virtual
view hierarchy, and a truly undefined view. I've introduced
new values for cases where the id could be defined.
Also gathering all window IDs into one place to reduce the
chance of collisions.
Bug: 34773134
Test: In progress. Current cts passes.
Change-Id: I97269741a292cf406272bf02359c76c396f84640
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 3787de16d24001eeb452e1c711d4290a396e67c9 |
|
21-Dec-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement pointer capture API
When in pointer capture mode, mouse pointer disappears and
further mouse events are dispatched to the focused view
in the window which has requested capture.
The captured events have the source SOURCE_MOUSE_RELATIVE
belonging to SOURCE_CLASS_TRACKBALL. They are
dispatched through dispatchCapturedPointerEvent /
onCapturedPointerEvent. There is also a new listener.
Pointer capture mode may only be granted to a currently
focused window, and will be canceled upon a window focus change.
Test: cts-tradefed ... --test android.view.cts.PointerCaptureTest
Bug: 30897034
Change-Id: I6e5934aa415ac2b6dda1cee173d0f23e5021af84
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| d9d871ff58d8fff4e02c72bf5d5b662fd8b92877 |
|
09-Jan-2017 |
Mark Renouf <mrenouf@google.com> |
Omit NavigationGuard if the input method uses FLAG_LAYOUT_IN_OVERSCAN am: 9b32a35aa7 am: 7ef0b07465
am: d5a1123109
Change-Id: Ie02c9f74fc93133a68940204420c48f92d4b352f
|
| 9b32a35aa7d47d39da919e777e2fe271cc83fa1c |
|
05-Jan-2017 |
Mark Renouf <mrenouf@google.com> |
Omit NavigationGuard if the input method uses FLAG_LAYOUT_IN_OVERSCAN
In some cases (e.g. Android Wear) SystemWindowInsets can be non-zero
due to overscan layout hints even when no SystemUI is present.
This change resepects the overscan flag on input method windows
allowing an IME to opt-out of the navigation bar guard and receive
full-height content view.
BUG: 32700226
Change-Id: Ic38f204a892bf34e8dae65990d5aa8c95af555d8
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 921f8e35d82f567b21a2faba6032b6e8f4f6f70c |
|
17-Aug-2016 |
Chong Zhang <chz@google.com> |
resolve merge conflicts of 9391bc5 to master
Change-Id: I6de231781233826b399688dc8ead70ba515b1ccb
|
| fea963edeeb60c76465c0d644078def191f41e0f |
|
16-Aug-2016 |
Chong Zhang <chz@google.com> |
Add new window type TYPE_DRAWN_APPLICATION
This type behaves like a normal TYPE_APPLICATION, except that WM
will always wait for it to be drawn before starting a transition.
WM always waits for TYPE_BASE_APPLICATION (main window), but for
TYPE_APPLICATION, it only waits if the window relayouts to visible
and gets a surface before the main window is drawn. If main window
itself is ready very fast, transition could start without the other
window.
bug: 30830849
Change-Id: Ife71a9812db7c8eba6ee4ead10ce4f31d9e93b40
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 45faba516e200760e977e8ceb76f079ee8aa7415 |
|
28-Jun-2016 |
Stan Iliev <stani@google.com> |
Fix wording regarding ThreadedRenderer
ThreadedRenderer is not synonymous with hardware rendering, so
remove references to hardware rendering when referring to
ThreadedRenderer.
Change-Id: Ic66a482ccf05f556ebe6ec194ce4f858f75bbb8b
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 5a80940852f199d490a70ebdd6cb391d381df162 |
|
11-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge \\"Reinflate primary action mode view after detach\\" into nyc-dev am: 82f2df6108
am: 6e6b0ce1a6
Change-Id: I712344966dfe02a647e5751c9741c6677e414f6e
|
| a9b59e9cf25218e25583d01fb1161964e1a50a48 |
|
11-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge \"Reinflate primary action mode view after detach\" into nyc-dev
am: 82f2df6108
Change-Id: Ic6def2b3eb5e654b028d11773a9527f01943289d
|
| 8d6ac26504ae3708732e0f5c0df02efb17937d9b |
|
08-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Reinflate primary action mode view after detach
When app is resized in multi-window mode we preserve the window along
with the decor view. If action mode view was shown before such config
change, its view is detached, but the mPrimaryActionModeView variable
is not cleared. So when action mode view is shown again after that it
thinks that its view is still alive.
This CL adds additional check to inflate new mPrimaryActionModeView
if it is not attached to any window.
Bug: 28971666
Change-Id: Ia8c24d4322be32e8b2c8967301beb3a4d889d501
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 85d202b18ada8dc95f151087ab9778d1a31f7a30 |
|
03-Jun-2016 |
Adrian Roos <roosa@google.com> |
Seascape Navigation Bar View
Allow placing navigation bar on the left side aka seascape. Also
deal with fallout from this change in frame calculations, decor view,
and all over SystemUI - notably no changes to the navigation bar view.
Bug: 28823676
Change-Id: I91187a974a10a940787a858e2609f2e9c5bade78
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| e65b3fbb63b4b6937fede2e4b889c0a51a881358 |
|
01-Jun-2016 |
Chris Banes <chrisbanes@google.com> |
Fix action mode animation on recreations - framework edition
Currently if an action mode is started in onCreate()
it will fade in. This isn't ideal though, especially
since Activities are recreated routinely with
multi-window and resizable Activities. In that instance
we fade it in on every recreate.
This CL fixes this in both the decor and toolbar action
modes to only fade in if the decor has been laid out.
BUG: 29036694
Change-Id: Iae985efcced170a0a4229124c1c132355c2aa71e
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 8e879f1fec1ca6c641f270b58447033ab4671851 |
|
26-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Enforce background fallback to be non-translucent
To avoid screen garbage or wallpaper shining through, the background
we use there for filling the whole needs to
a) Be non-translucent in all cases except if the window is translucent.
b) Don't infer it from the theme as it might be unexpected. Don't define
it in the theme, and use black if it's not defined.
Bug: 28763785
Change-Id: Ifb724b5c5feea3ed70d68e5bd7615fa91185e743
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 692a5feab998b5129be427589b77a77ef3ea2ad9 |
|
19-May-2016 |
Robert Carr <racarr@google.com> |
Correctly clear resizing drawable when nulling background.
When a null window background is set, we want to use the
fallback drawable for resizing.
Bug: 28801472
Change-Id: Ia616d7aa18b0d7aa2c7081a85ce7551ecfeca5b3
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| d0fa4d3aafa42da696c006ab96a11ed54deec14c |
|
06-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix status bar background flicker" into nyc-dev
|
| 867b812effbd8b24b60f4feb0188032c6cc8dfa5 |
|
06-May-2016 |
Chris Craik <ccraik@google.com> |
Fix status bar background flicker
Fixes: 28533578
Change-Id: I075f49b7d20e0e95e790a9755d104a0a51575054
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 880eff6e9bdb91a33ae4ff2514ef270425f38002 |
|
27-Apr-2016 |
Jaewan Kim <jaewan@google.com> |
Prevent pinned stack from having extra elevation
Pinned stack doesn't have focus, so there's no need for setting extra
elevation to show shadow for focused case.
This removes extra eleavtion for pinned stack, and improves the PIP
animation quality by preventing extra surface size change
at the end of animation.
Bug: 27364161
Change-Id: Id099a78de48b2e038a69600c94454b5cbfe0628f
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 23e282d297193655ce5a4b716312f0a985b27d50 |
|
20-Apr-2016 |
Oren Blasberg <orenb@google.com> |
Accommodate NaN in new context menu methods.
Bug: 28296401
Change-Id: I0ae6067e1ae01c342c1b39d6f64db5dcd02492d5
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 971d8e6399d556302b52a92dd29abf44830a587c |
|
12-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Don't remove background when resizing
This leads to flickers, as we should not draw in a translucent way
if we didn't specify that our window is translucent, because the
renderer has some about translucency.
Instead, we should clip the backdrop content by the inverse of the
content clip rect, which is not yet implemented.
Bug: 28009524
Change-Id: Ia3f54fb83997ace863e78ff1cbe45cfb64f92f26
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 8f5701bd9f1149d672d63758e522dcfaaa258a73 |
|
05-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Only force drawing status bar background if target >= N
Since forcing it all the time has the potential of breaking
compatibility with apps, we don't want to do this.
Instead, we only force it if the app targets >= N.
We communicate this to window manager with
PRIVATE_FLAG_FORCE_DRAW_STATUS_BAR_BACKGROUND.
We introduced this for 2-up split-screen. If we have an app
that doesn't draw the status bar background by itself, we
just force the whole bar to be black.
The same applies for windows that used translucent status
bar - we also force the whole bar to be black
Bug: 27285627
Change-Id: I7f1ceaa364f8a4e851935f77aa5e8d913bf11791
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| b2005a02170b0a5bc8518514c8a871c5fc526e09 |
|
08-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix BackdropFrameRenderer leak
Make sure to stop the thread when the window gets detached. When dismissing
the docked/fullscreen stack with the divider, we stop the activity while
we are still in resizing mode.
Bug: 28054032
Change-Id: I2d5d0ffaa9bc47e4d5252414b9a045beaebb7a69
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| e8a4eff9d919481f021903be8389d4b6e93d2ca5 |
|
29-Mar-2016 |
Winson <winsonc@google.com> |
Moving the background to the window.
- Make sure to remove the background from the DecorView while
resizing, so we don't draw it twice.
Bug: 27869246
Change-Id: I7f830e5c825749fdf2b5bbda7af92239702b70ad
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| e5638a6f75472127493422a68954aa3fd2109658 |
|
26-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix nav bar consuming
- Cache shouldAlwaysConsumeNavbar so it doesn't get reset when
insets == null
- Remove logic with frame comparison when determining whether to
consume nav bar. Not sure how that ever worked.
- Make sure shouldAlwaysConsumeNavBar survives when consuming
insets.
Bug: 27157904
Change-Id: I35f209ab27cc12240038da7efa9e79c95f70c6ce
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| c39c7b0ce2b80fbadfd58245c106cc513b83eac2 |
|
24-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add shadow during resizing in docked mode
Bug: 27738239
Change-Id: I48c45bd97c2aa7f3d7bbb5b1ba650fbe408bd0bf
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| fcd7e80b21cc9db6be00e37371401ea1d0938796 |
|
10-Mar-2016 |
Clara Bayarri <clarabayarri@google.com> |
Keyboard Shortcuts: plumb deviceId through
Bug: 27673736
Change-Id: Ie72807aa8c2bfd142b081a6a915e101c16d31473
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 2a6d9aa1cdfc7489fdc9ef1a0cec51c6c3c29c7d |
|
17-Mar-2016 |
Sunny Goyal <sunnygoyal@google.com> |
Adding a default implementation for the new Window.Callback method
Bug: 27702972
Change-Id: I6b8c1766ecf871801006d4dc47796a819e49bb57
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| f8fb6d1261dd7ee4ee5342766f0f12e1b31080b2 |
|
25-Feb-2016 |
Chong Zhang <chz@google.com> |
Merge "Make sure background drawable callback is cleared during resizing" into nyc-dev
|
| 0df63d5d57ee3741704290bd7f73f17c38cb1ee8 |
|
25-Feb-2016 |
Chong Zhang <chz@google.com> |
Make sure background drawable callback is cleared during resizing
bug: 27297724
Change-Id: I8ee3d0e093f94a7fc293f64949abbb612e0b2aa4
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 0ffd49cbe0ab4c13fd5528abacade898a8cff481 |
|
13-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Always consume bottom insets when navigation bar is force shown
When an app requests SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION but we
force show the navigation bar, we need to treat for the app like
there is no virtual navigation bar on the device. Because if you
combine it with FLAG_HIDE_NAVIGATION, you'd expect the navigation
bar gets hidden but it doesn't, so there could be content that
overlaps with the navigation bar.
Bug: 27157904
Change-Id: I088e02eae2e723c35e9cb4873de6b1325458533b
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| ffd049027f1cb85c67353abefcf130c1474c261a |
|
24-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix wrong measurement in DecorView
Bug: 27215338
Change-Id: I512df9b23788daf485b020a2199a55a7c6ab6311
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| d3fd96c20818d2f206416e53c0a6fa2108de6e07 |
|
09-Feb-2016 |
Chong Zhang <chz@google.com> |
Use background drawable from the client
And set the drawable's callback to null during drag-resizing, since
we use multi-threaded renderer, will do not want to schedule draws
to the ViewRootImpl's thread.
bug: 26729953
Change-Id: I6e5f94a5a6ba15edc2d391dd11d8fee3c657d337
(cherry picked from commit 1cc95075e89a0f91cb59ff37a1a027199040c7b4)
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 9f6798a9367cc6134f956c422107361db43c4212 |
|
11-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix layout for full-screen floating windows
When the app doesn't set IN_SCREEN and INSET_DECOR but the window is
still full-screen, we force SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN but then
we still need to communicate the content insets to the DecorView.
In DecorView, we consume these insets in this mode and set it as
layout params so this behavior is completely transparent for the
app.
Bug: 26464646
Change-Id: Ib7332b845767a5bbc0266c380bf6240e322db943
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 1af8eda6ea1c89d44123b2bfd5fa0293bb9d68cb |
|
05-Feb-2016 |
Winson Chung <winsonc@google.com> |
Drawing thumbnail background color for empty space in view.
Change-Id: I2e8dfbe9c11a61876956658eff0674adb26d855d
Signed-off-by: Winson <winsonc@google.com>
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 65bff3e4e9ac48f79a9da111f6e1d263af6d3a2e |
|
09-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix Keyboard overlap with navigation bar
FLAG_FULLSCREEN is really the wrong flag for determining whether
to subtract the window insets in the decore view and layout
it with a reduced size - FLAG_LAYOUT_IN_SCREEN suits these needs
much better.
Bug: 26014496
Bug: 26984057
Change-Id: I5c7a0fb7468d3981b91b23aa4c8b1e4841202131
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 0a13bfdefc8a74a147bdf64b44e9f50c097c1599 |
|
05-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix disappearing translucent status bar background
When relaunching an activity while preserving the window, the content
view was put on top of the status bar background, making it disappear
in case of translucent status bar backgrounds.
Change-Id: I1edff29c10616bf5386e982d7336327135f0f7a0
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 9511b0f1e9ac629a4a747a0c9373d33ab33cfc32 |
|
30-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix bug where surface was not clipped off during resizing
When dragging the divider in a way such the task size goes through
the following transition
- Half size
- Full screen
- Half size
the surface wasn't clipped off anymore. This was because in full
screen configuration, computeDragResizing() == false thus when
going full screen -> half size, we reset the draw state to
DRAW_PENDING to get notified when it has finished drawn. However,
this also broke clipping.
In order to fix this, we always put the window into a resizing mode
no matter whether the bounds are fullscreen or not.
However, this introduces an ugly flickering on the navigation bar,
when going into docked mode, because the app doesn't draw navigation
bar background in resize mode.
To fix that, we calculate the presence of navigation bar whether the
window is fullscreen, and not just whether it's resizing. For that,
we need to calculate the presence in BackdropFrameRenderer, by using
the insets just sent by window manager.
Change-Id: Idf56df4ae7fefe67d068bc2eeda8dc4d83bbefb7
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| adf7b5e817ec971eb4f20bb0bbe936b6451b7a44 |
|
28-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Don't extend alert windows onto status bar/nav bar.
This requires preserving information about the status bar/nav bar insets
and using it to reduce the available space when measuring wrap_content
windows.
Also remove the hack that was introduced for round devices and should be
handled instead by the round qualifier and theming.
Bug: 26014496
Change-Id: I5688c50153047dcabc197adab8fec141630a2b51
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 1937a4c68a586e75501a90253c90b213a4d6167f |
|
20-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Update width available for dialogs on all configuration changes.
Bug: 26504275
Change-Id: I7a0399e4af77ab02df8b3dff68adcf37b36d7ca7
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 75e097965cc273d33192555b0e65de3dbc1753ce |
|
29-Jul-2015 |
Clara Bayarri <clarabayarri@google.com> |
Request Keyboard Shortcuts for SysUI Dialog via Window
Keyboard shortcuts are requested via WindowManager, and
the request pipes through to the view root and the window
callback.
Bug: 22405482
Change-Id: Ic0071e91c7b554be3ac9df71e9539ee8a60e822e
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| a40fd09fa99fed9526c6603b5af93b7dba259000 |
|
08-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Load background drawable before passing to backdrop renderer.
Background renderer always expects that the default background drawable
is available. We pass the drawable to the renderer in two places, so we
need to make sure to load the drawable before each.
Bug: 26345599
Change-Id: I238623ff870e26ba34bb02197611172e316d3083
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 34dab0b3d9d461d441f9c63a39565c8734620cd3 |
|
22-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Use activity dimensions instead of display to calculate dialog size.
This adjusts the code for measuring and laying out dialog windows, which
used display dimensions as a basis for calculating the dialog
dimensions. Because of this dialogs would be too large in multi window
mode, where the parent bounds are far smaller than full display. This
switches to using dimensions for configuration received from activity
manager.
Mind, this is still not working as needed, because the resources return
minimal size of the dialog as if it was displayed on a full display,
rather than within activity bounds.
The CL also introduces better logging tags in ViewRootImpl and
DecorView. These normal approach works reasonably well when there is a
single activity on the display. However, when multiple windows are
displayed, it becomes impossible to determine which view root/decor view
logged what. This adds a suffix, that allows to identify the owner.
Bug: 26251921
Change-Id: I515a1ff9a81ee5ad086773196db71915e88a25eb
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 9084d22cb9fb2367ce56403ab6aecbee26a705bd |
|
16-Dec-2015 |
Alan Viverette <alanv@google.com> |
Check for null MenuHelper before setting presenter callback
Bug: 26219569
Change-Id: Ia19a1304aa10dac52b89d0ee85acdb5671a15777
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 3e5f080528c17acd93023ca47fa548da0e1ed2a7 |
|
15-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Fixed bug with caption not showing for some apps that handle config changes"
|
| eb6722c0bc87dd5419df1eb92268b824c2d29b50 |
|
08-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug with caption not showing for some apps that handle config changes
We currently decide when to show the decor caption onConfigurationChanged
However, if the app handles configuration changes or the threshold isn't
big enough for the configuration change to be reported to the app, we don't
display the caption in some cases when transitioning from fullscreen mode
to freeform mode.
We now also use the onMultiWindowModeChanged call to also determine if
the caption should be visible.
Change-Id: I237437f04ad90f904912ebac0253245f547b0e3e
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 77fb85eda9923970d6f8f699e8d628d37c3dd764 |
|
14-Dec-2015 |
Alan Viverette <alanv@google.com> |
Only handle Context submenus as dialogs when parent is a dialog
Bug: 25656520
Change-Id: I5841d8f0c3d4a537e2d94aacddb1687d05d5c258
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 3dec081967db3c0e906ff272d632618e260b6413 |
|
09-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remaining APIs for freeform window caption.
The APIs are:
* setting a listener for the area of the caption where we display
control buttons; this is intended for apps that overlay the caption on
their content, so they don't display the content in that area and clash
with the buttons;
* specifying the color pallete of controls in the caption; by default we
try to infer the best color from the theme (dark buttons for light theme
and vice versa), but in case we get it wrong, we allow the developer to
overwrite it;
* specifying the caption background during the resizing; by default we
try to infer a good color from the theme, but in case we do it wrong, we
allow the developer to overwrite this.
The CL also includes merging of layouts decor_caption_dark and
decor_caption_light into a single one. Not only it reduces code
duplication, but also is necessary for allowing adjustment of the
controls color pallete after the layout was created.
Bug: 25486369
Bug: 25818398
Change-Id: Ib87fe849b07df341893ec7873982bf7ab932f6d5
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 012ce3453f5f7737cae5d6afa1338191e740274f |
|
07-Dec-2015 |
Seigo Nonaka <nona@google.com> |
Merge "Allow IMEs to opt out the opaque navigation guard view."
|
| 0a9d1ea015af24056018ec02f6d9afd2f62243ba |
|
18-Nov-2015 |
Seigo Nonaka <nona@google.com> |
Allow IMEs to opt out the opaque navigation guard view.
Previous CLs [1][2] introduced an opaque navigation guard view to
avoid the island effect (the real nav bar is transparent but the IME
shows its UI with assuming that the real nav bar is opaque).
[1] I460912ee7c117480c57b947ed31eca330819f32c
[2] I6a93f30aec83f1cecfb854073046cbc87ab4aa66
Although the current guard view works fine for that particular case,
there are two major situations where having an opaque navigation
guard view does not make much sense.
1. The IME shows no software keyboard at all.
Some IMEs automatically hide software keyboard when a hardware
keyboard is attached.
2. The IME relies on floating UI that is disjoint from the bottom of
the screen.
The main goal of this CL is to address case 2 because unlike case 1
the system is not able to automatically detect the case 2. Only IME
developers know when the opaque guard view should be opted out.
Of course, if IME developers can opt out the opaque guard view,
it means that they can also work around case 1 without relying on
the system, but again it is not the primary goal of this CL.
With this CL IMEs are now able to opt out the opaque navigation guard
view by calling Window#setNavigationBarColor(Color.TRANSPARENT) from
InputMethodService#onWindowShown(). Note that this API used to have
no effect for IME, hence reusing this here should have no compatibility
issues.
Note that any other color is currently ignored to minimize the impact
on UX.
Bug: 22564251
Change-Id: Iea77915ecc55eedaf19899e72c44f704ba9d852c
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 04c2fbd6fe389bcfa3a6368d8ae2c20c9e81e4f4 |
|
03-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Draw status bar background in BackgroundFrameRenderer while resizing
To make sure there is always enough contrast between the status bar
icons and the background, we move the drawing for the status bar
background into BackdropFrameRenderer while resizing, so we can
extend the width into the full surface width.
Bug: 24365214
Change-Id: Ifbb10bacf66670c3637f6f6730a8ac47eb1c3939
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 6e0ce286a820b2eccb8106335c531a89d841d0c4 |
|
02-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Don't remove colored bar views when relaunching
Change-Id: I518521e6b5e0b18a7f9ad9c7c6a67d55e2dfa2ab
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 4fa7892f35268ff7d591928ac9f5a26c267031e3 |
|
01-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Add flag so apps always draw status bar background
So we don't have to implement crazy magic when one app requests
drawing the status bar by itself, and the other doesn't in split
mode.
Bug: 24365214
Change-Id: I1f6a0efd0865b784402055e008da2f31e626f163
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 021627eb5875372dea57ba91fa782fffbfbbc559 |
|
25-Nov-2015 |
Alan Viverette <alanv@google.com> |
Ensure only one context menu is shown at a time
Refactors the menu helper classes. Both classes now implement a common
MenuHelper interface, which eliminates the need to keep separate helpers
on PhoneWindow and unifies the DecorView showContextMenuForChild()
implementations.
We now explicitly dismiss any previously shown context menu before showing
a new context menu. Previously we relied on the modal nature of the dialog
context menu to prevent multiple menus from being opened at once, but this
is no longer reliable with popup context menus.
Bug: 25656520
Change-Id: Idab3daa6d6888f803f2e33660fe1dd488e4c28d1
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 63250651ca4656fc1b9e9ffb9c48d481df80454d |
|
18-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
API for overlaying app content over decor caption in freeform windows.
Bug: 25486369
Change-Id: I8fba30dd690d9f0ccc48149f57ce254286b0c2ae
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 62a91d67cee99998c941c76ad1a61acf1bb40b77 |
|
18-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Renamed NonClientDecorView to DecorCaptionView
DecorCaptionView better describes what it does now which is to
display the caption area and control buttons within it.
Change-Id: I6b641d6b117bb8f03656bff93702fc093160851d
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 2b547c3f30d3fdfd9b544972051a32b9aa4135cf |
|
18-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Control display of shadows for multi-window in DecorView
Allows us to display shadows without needing the NonClientDecorView.
For example, windows in pinned stack don't have a NonClientDecorView.
Bug: 25006507
Change-Id: Id573a30942a9bfcd002b86f0956d0b2a14ec2c2b
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 8cc5a74c9049423260a14e0ebb44a052ef8f4e2a |
|
18-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Only add NonClientDecorView when needed
We were previously adding it to all decor views because it was
required to be able to draw the resizing backdrop. We now manage
the resizing backdrop independently of the NonClientDecorView.
Bug: 25082500
Change-Id: Ib786d55eacd221e5d36a4afca9117d5409499674
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| bf9eefc72f7da2048252d96175d04904a9503c57 |
|
17-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Move management of BackdropFrameRenderer to DecorView
Allows us to have the BackdropFrameRenderer independent of having
a NonClientDecorView.
Bug: 24810450
Change-Id: Ibcda3d722970536ee037b192e90e01da5650ac74
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 0d7e912b001838748bfb61b92b81d2f493ef4a6b |
|
17-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Moved management of NonClientDecorView from PhoneWindow to DecorView
Bug: 24810450
Change-Id: I682afe1b15cb8ec1f98b38b88a499243d4c6c8a3
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|
| 8804af2b63b0584034f7ec7d4dc701d06e6a8754 |
|
17-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Move DecorView out of PhoneWindow into its own class file.
Bug: 24810450
Change-Id: Ifa4e01517c80cec6d9a5b1051e5ccb7bab94a470
/frameworks/base/core/java/com/android/internal/policy/DecorView.java
|