https://b.corp.google.com/7060284
- Throw exception before we try to start window
transition with null thumb
- also remove some old unneeded debug code
Change-Id: Ic9693372724cbfaa4c4cb2594128ca10677d9d8f
Replaced all remaining places that used it with explicit user
specification.
While doing this, I ran into stuff that was creating PendingIntent
objects (that now need to specify the explicit user they are for),
which are also posting notifications... but have no way to specify
the user for the notification.
So the notification manager in the system process now also gets a
formal concept of a user associated with the notification, which
is passed in to all the necessary aidl calls. I also removed the
old deprecated aidl interface for posting/cancelling notifications,
since we now always need a user supplied.
There is more work that needs to be done here, though. For example
I think we need to be able to specify USER_ALL for a notification that
should be shown to all users (such as low storage or low battery).
Along with that, the PendingIntent creation needs to be tweaked to
be able to handle USER_CURRENT by evaluating the user at the point the
pending intent is sent.
That's for another change, however.
Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
(That is: you must have discovered the flying-jellybeans
easter egg to gain permanent access to the Dreams version of
same.)
Change-Id: I65ce39c0ab5b61f492a3637e3c31b3c91f4f0f89
Ensures that the navigation buttons are properly oriented
each time the screen comes on.
Bug: 7086018
Change-Id: Iac6243792a8c64001ff7409108fb892bd470e4c4
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
For now, each time the dead zone captures a touch, it will
flash to let you know that's what happened. We should
probably turn this off before shipping.
Note also that this currently only expands the navbar on
ACTION_DOWN elsewhere in the UI (because this is the only
time ACTION_OUTSIDE is generated); this isn't perfect and
we'll need to do some mucking about with the input system to
get information about ongoing drags or additional pointers
down, but this CL is a good start and introduces the general
mechanism for expanding and contracting the dead zone.
Change-Id: I43e63aed1e541fd07d83fde4d66bcb5be89b69d2
Since the Recents is now an activity running in the respective user's sandbox,
it shouldn't use the special API to get the current user's recent tasks.
Otherwise it causes all users to fetch the state of the current foreground user
instead of their own recents.
Change-Id: Ice8c2978e6a7ae71c44666c79a19ac07a2cbea1b
As a part of this change, Recents is now an
activity.
Known issues:
* Jank: jump-cut as app icon appears suddenly
after the aniamtion
* Preloading recents is broken on phones without
soft nav bar and on tablets
* Thumbnail window from animation lingers/flashes
sometimes
Change-Id: Ie6f991f3c2e1e67f9ed84eb6adba9174ed957248
The notification panel uses LayoutTransition to animate changes to
the list of notifications. This works for the items themselves as
items are added or removed; the new/old items animate in/out and the
existing items animate to make or remove space.
But the handle at the bottom of the list (the gray translucent line) does
not play well with these changes. For example, when an item is swiped away
the handle snaps into its new location before the rest of the items have
finished animating.
The problem comes from a constraint of LayoutTransition; it handles changes
to the container it operates on, and to the parent hierarchy all the way up
to the root. However, it cannot animate changes to siblings of the parents.
So when the list resizes due to item changes, the handle (which is in a sibling
of the list) does not animate this change, but just reacts instantly.
The fix is to draw the handle not as a view itself, but rather as part of the
parent container of the list. So as the list animates a resize, the container will
also animate, and any graphics in the container will animate along with it.
No matter what size the container of the list is, the line will be drawn at
the bottom of it.
Issue #7024902 Notification panel animation incorrect when swiping notification out
Change-Id: Ifc412cb6bcdc6ead35993b0320364a2a95a16e11
When the notification panel is opened larger than the list's length,
the penl is put into a "rubber band" mode, to animate the bottom of the
panel back to the end of the list. But the rubber band mode is never
unset, which causes an improper result if another notification is ended,
preventing the panel from resizing to the new, appropriate size of the list.
Fix is to unset the rubber banding flag when the snapping animation finishes.
Issue #6992133 Notification bar does not drop down completely in Mako
Change-Id: Id93918086353f58d6eb6bb071556f08eb2e2706e
The UsbDebuggingManager listens to adbd requests and displays a dialog
when the public key authentification fails, for the user to confirm if it
wants to allow USB debugging from the attached host. If the user chooses
to always allow USB debugging, the UsbDebuggingManager writes the public
key to adbd's config file so that the public key authenfication succeeds
next time.
Change-Id: I115c828331d8e326c380844ee33915d5dff22260
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
