- Fading out recents first, then scaling up app
thumbnail
- Fade Recents out over 130ms
- Delay the window animation for 200ms first,
then animate for 200ms (previously we didn't delay
and then animated for 300ms)
Bug: 6390075
Change-Id: Ia8c753bf7ee03d2acef6eb2772b28d88fe10a682
- Remove the notion of channel from an application perspective
- Remove the use of DnsSd as part of API and add a protocol type to allow
future extensions
- Use the listener object as a handler for stop and unregister operations. Also,
we now allow multiple active discovery operations.
- Remove init/deinit operations in favour of setting up construction
Bug:6434844
Change-Id: Id15521d571aac9c4053d81184ad66dfc54f636de
Allow applications to transition from 0=>1+ visible menu items outside
of onCreatePanelMenu/onPreparePanel. Previously, having 0 visible items
at this point would require an invalidation of the options menu.
Bug 6452605
Change-Id: I6cbfc46d0e5ec42b8d78ee516e9b57fdeaf1a890
Propagate the return value from onNavigateUp as the result of
onMenuItemSelected. This fixes a bug where the action bar Up nav
button clicks would not be propagated to support lib FragmentActivity
or other activity subclasses that rely on processing otherwise
unhandled onMenuItemSelected events.
Change-Id: Id879dd1756ed06b8a7b720ebf0eae2a8ddc66ca8
Also don't retain the source bounds in recent tasks, since it
has no meaning there and it would be better when relaunching an
activity to have a new bounds set based on wherever it is now
being launched from.
Change-Id: Ia90c04ee98a888a7f725b038abe23d71e2b12800
...without onPause() in between
There was a bug in the handling of "always finish activities" where we
would go through destroying activities while in the middle of updating
the activity stack. This would result in the activity behind the
non-full-screen activity being created and then immediately destroyed,
which things were not expecting.
Change-Id: Idaa89089f7b1af7eb747d7b8f9f394beeb2d23fa
1. The dismiss implementaton in Dialog was posting a message
on the main thread to perform the real dismiss work. The
goal of this was to allow calling dismiss() from multiple
threads. The side effect of this is that when dialog fragment
is dismissed the dialog is not dimissed until the current
loop on the main thread is completed. However, during rotation
of the screen the current activity has to be restarted, hence
all fragments whould be removed. In the destruction process
the dialog grament requests from the dialog to dismiss but
since this is asynchromous, the code in
ActivityThread#handleDestroyActivity detects a leaking window
since the dialog window is still not removed and removes that
window. Now when the dialog removal message is processed on
the next loop we get an exception that the window has already
been removed. Now if Dialog#dismiss() is called from the
main thread the call goes right though otherwise a message is
posted.
bug:5911682
Change-Id: I449d6dd75a84c0ff29ea13dac7d163219cc38341
Bug #6436642
An app invoking dismiss() during a draw pass could cause crashes.
This change makes the code simpler too.
Change-Id: Iba89a8522e23d02f87697cfeec6cc713a1462669
* commit 'cdea2a3e654543ecdf27528d505787770c1b5feb':
Add an alternate title that can be used in the overflow of a InboxStyle. Always hide contentText for BigTextStyle and InboxStyle. Style cannot be used without specialization, it should be abstract.
Always hide contentText for BigTextStyle and InboxStyle.
Style cannot be used without specialization, it should be abstract.
Bug: 6428978
Bug: 6274137
Bug: 6317471
Change-Id: I21531a94494f891a058a477805b177e736b921cf
