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
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
Otherwise File.createTempFile() uses /sdcard which most apps don't
have write access to.
Bug: 6347289
Change-Id: Ibde191a63e4dbb9b03437406f8c999f192bcfa21
1. The date picker dialog shows spinners and a mini calendar on
tablet but on on phone the calendar is not show and the user
does not know the day of the week otherwise show on the mini
calendar.
bug:5264972
Change-Id: I06aeb7ba1ad34d4e99628d9586ff2777e981c963
Introduce IRingtonePlayer, which handles playback for both Ringtone
objects and Notifications. SystemUI now hosts this player, which it
registers with AudioService. It also keeps MediaPlayer instances
warm, and cleans them up after stop() or Binder death.
Move both Ringtone and NotificationManagerService to play back audio
through this new interface.
Bug: 6376128, 6350773
Change-Id: I1dcb86d16ee3c4f07cdb2248d33dcff4ead3609a
We didn't have a case for tvdpi, so ended up in the default
scaling. This resulting in us using 319 instead of 320.
Fixed the default case to round, and added explicit cases
for tvdpi since this is a standard density.
Change-Id: I752b924e1556af94682428c8c0ed7c75d15ac4a4
When used in a `ViewPager`, fragments that are present on the adjacent,
cached pages will receive context selection dispatches which, depending
on your fragment contents, can be difficult to determine whether or not
the event truly originated from your view.
By using the visible hint we restrict dispatching to only those fragments
which are marked as being visible. Since the fragment pager adapter
updates this setting properly most implementations will be afforded this
fix without any change required. If the user is implementing their own
adapter they likely already understand the implications of these cached
fragments and the reponsibility for updating the boolean falls to them.
Mirrors support library change Ie6a72c1c82c2784774373670007b6f5948fe16da
Integrated from AOSP.
Change-Id: I19bbbe4c8d910fb38c14d6ae5d462eb7dd44fd26
If a fragment's saved view state is null and the user
visible hint is true then the `result` bundle will have
never been initialized to a value resulting in a
`NullPointerException`.
Mirrors support library change I8ba585bc6b9298841490d64bc22a8219cd261adb.
Change-Id: Iabd5ac293d2ece3771da9ef257479eca0dcd523c
Let TaskStackBuilder discover a parent activity stack by ComponentName
in addition to explicit Activity classes.
Change-Id: I18b8378548ed1d6ef033800e6a3e11ab965d07e5
Otherwise registerReceiver() from views inflated with the returned
context will throw (like DateTimeView).
Bug: 6376149
Change-Id: I038a680e49fba81bbebfc8c0c94f15e7cd072f33
