The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).
Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!
The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.
Also did some improvements to debug dumping in the window
manager.
Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
Allow fullscreen windows to specify crossfade or jumpcut animations
that override the default rotation animation. Only if the incoming
and outgoing topmost windows are fullscreen and both specify the
same animation to use.
Fixes bug 8182773.
Change-Id: I6b3c0020d7bd2cdfba5c66189e114ec62cd54fcf
Keyguard currently relies on being in the system process to grab the
given user's widgets. When we split keyguard into a new process,
it will need to have access to user-specific info to instantiate a
specific user's widgets. In order to accomplish this, we add an
explicit userid to each binder call as well as new permission
check to allow keyguard access.
This also fixes a potential race condition of having an incorrect user id
due to an async call to change the user. Every binder call now has a specific
user id. The user id is either the calling process user's id or an explicit
one passed by applications like keyguard. It is created once when an
AppWidgetManager is instantiated and remains for the lifetime of the object.
Fixed bug where widgets sometimes didn't show up for secondary users.
Moved permission check in AppWidgetService into getImplForUser()
Refactored to use userid from context associated AppWidgetManager instance.
Clean up AppWidgetHost to use userId from Context.
Remove redundant userId check in checkPermission since it's handled by
ActivityManager.handleIncomingUser()
Removed redundant userid check.
Upload after rebase...
Change-Id: Iae3e20f2b342c323bb58768b3d22051510f8268b
Introduce another new rectangle in window layout, the
restricted overscan region. This is for windows that can
be in the restricted region (that is, full screen but with
hard restrictions like the nav bar) but whose content can
be adjusted for the overscan constraints.
In other words, normal application windows now always extend
into the overscan region, and we push their content inside
of it.
Change-Id: Ibccf3d7f144912d49de3fc497c1ec2e8e0b7f714
The window manager now keeps track of the overscan of
each display, with an API to set it. The overscan impacts
how it positions windows in the display. There is a new set
of APIs for windows to say they would like to go into the
overscan region. There is a call into the window manager to
set the overscan region for a display, and it now has a
concept of display settings that it stores presistently.
Also added a new "wm" command, moving the window manager
specific commands from the "am" command to there and adding
a new now to set the overscan region.
Change-Id: Id2c8092db64fd0a982274fedac7658d82f30f9ff
If starting window is added to arrays like mViews in
WindowManagerImpl.java, but not accepted by WindowManagerService,
we leak starting windows. To avoid leaking, remove the view
from WindowManager.
Change-Id: I4d98b883e9dfaf5e71bdece385643ba1b59b2633
- Following disable and reenable of the WindowOrientationListener
the state was the same as before. State should be reset to default.
- Provide a Handler to the sensor task to deliver events on the
same Thread that WindowManagerPolicy operates on.
- Expand lock protection to all of WindowOrientationListener.
- Move WindowOrientationListener to policy package.
- Make SensorEventListenerImpl non-static.
Fixes bug 7964531.
Change-Id: I17cecf3d0b6d125cb3e4d7350c3adb3f62b684bd
The ActionBarContextView popup window was set to use the "layout in screen"
and "inset decor" flags even though it's not a fullscreen window. This was
causing the popup window to be created by taking up all the available space.
Because the views inside the popup window are wrap_content, this would cause
part of the window to not be drawn and since the window is, correctly,
marked opaque, we would get random graphics corruption on screen (the user
would see the content of the tiles on a tiled renderer such as QCOM's.)
This change simply removes the two unnecessary flags from the popup window,
forcing it to be created and laid out at the exact size it needs. It will
be properly positioned by the window manager underneath the status bar.
An interesting side effect is that the window is now smaller than before
(since it doesn't extend underneath the status bar) which saves a bit of
memory.
The popup window also contains an unncessary black background behind the
action bar context view. This helps in a way because it allows us to
create an opaque window but it increases the required bandwidth to draw
that window. Given the benefits for SF it's probably best we keep the
window the way it is for now.
Change-Id: I4aeeb42a6232ff6b71811e766846d45635eb3365
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
When launching an assist, we have a new API allowing the
current foreground activity/application to provide additional
arbitrary contextual information that is stuffed in the
assist intent before it is launched.
Change-Id: I0b2a6f5a266dc42cc0175327fa76774f814af3b4
This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.
UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.
The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.
The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.
bug:8028258
Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.
bug:7678973
Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
When switching to a widget, examine its hierarchy to determine if it
contains TextClocks that show hour and minute for the local timezone.
If so, hide the status bar clock. Doesn't fix closing walls.
Bug: 7667638
Change-Id: I1e2c40345c9e5eb0193efd70838c7ca9f779190b
1. This patch takes care of the case where a magnified window is covering an unmagnigied
one. One example is a dialog that covers the IME window.
bug:7634430
2. Ensuring that the UI automator tool can connect and correctly dump the screen.
bug:7694696
3. Removed the partial implementation for multi display magnification. It adds
unnecessary complexity since it cannot be implemented without support for
input from multiple screens. We will revisit when necessary.
4. Moved the magnified border window as a surface in the window manager.
5. Moved the mediator APIs on the window manager and the policy methods on the
WindowManagerPolicy.
6. Implemented batch event processing for the accessibility input filter.
Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116
This fixes a bug introduced in Change-Id: I34b7db402401a824f463d35d7546c05dc2979243 where
the top-most view was allowed to capture focus in order to ensure the device handled volume
key events.
This resolves the issue by restoring previous behavior and ensures we still handle media keys,
regardless of focus.
Fixes bug 7676996
Change-Id: Id2d1200be81640e4b4b7b5e3a0af099d6fc2d259
