If we start the forced resizable activity with an existing task,
avoid moving that task to the front. This can cause that a previous
task that was moved to the back gets moved to the front again just
because we started that activity. That's not good.
Bug: 28223489
Change-Id: If8acf31b8be98b82665de1015d5621331c37fb64
We could run into this situation on some devices (eg. clockworks),
the next activity doesn't get launched until we destroy this one.
allResumedActivitiesVisible() will return false if there is no other
activity running at all. Check top running activity and it's visibility
instead.
bug: 28400334
Change-Id: Ib8957e499580a10206fdd4e27da19fbc2bdb5843
processStoppingActivitiesLocked() only removes one record each time, so
instead of stopping on the next window visible (or next idle), it now
requires two such calls to move the app to destroyed, if there's only
one report, the app never gets removed.
bug: 28417200
Change-Id: I7c5eac240074ed0434a72643a8d52f1726ab906c
Previously, the disabled color was used for the contrast
calculations, which resulted in too dark RemoteInputView
backgrounds.
Change-Id: I99e8b2fa64a22a59fdc5d1be8a6aff5af3523a27
Fixes: 28429720
Per feedback from the support library team, updated the support
library overview page to better explain what the libraries are
and what they're for. This is the beginning of a big overhaul of the
support library docs.
The "overview" section has been rewritten and expanded in this CL.
The "revisions" section hasn't been touched, except that the heading
was changed to "Support Library Revision History". (I'd like to
move "Revision History" to a separate page, but I'll do it in a
follow-on CL.)
See first comment for doc stage location.
bug: 27274455
Change-Id: I12ce21c948421e1bd0be5d3151845f900750e7b1
Since the field might be null, we can't just read and write the
object directly. Use Parcel's convenience methods to do so safely
instead.
Bug: 28427070
Change-Id: I6460c9cb43dc6da97d5fd9edeaa78bdaaf105446
The transformed view could get updated during the transition
leading to a crash sometimes. We're now handling this better and
make sure the correct values are set.
Change-Id: I1a311cb7c108afeec0fc1c92eb3359c622db7b87
Fixes: 27922191
This plays nicer with SELinux and generally means we can be more robust
about file security policies.
Bug 28403975
Change-Id: I857ee7073c0090c7515421f41c9334025e25bc79
Also fixes a bug where the lockscreen wallpaper was
showing in occluded mode and where the regular wallpaper
was flashing when going back from occluded mode.
Change-Id: Ibe6404acc4ed5db8807b3ef223b149e841730c8f
Fixes: 28271756
Added endian.h into include list to avoid build error in "docs".
The function "htobe64" in endian.h is used.
Change-Id: Ic76dab25d34c56b58b97849dfa7b103963392568
- update mTempConfig from mCurConfig first to decide if
config is changed or not. This fixes recursion of putting
new config again from reconfigureDisplay
- ignore setNewConfiguration if there is no change in configuration
This fixes another recursion due to config change -> app restart
loop
bug: 28381048
Change-Id: I4c2e6072b269baf9fa11d4b8073f0800c0e0d28d
If an app undergoes restore during install, it is considered 'started'
and the FIRST_LAUNCH broadcast needs to go out. However, this must not
take place until after the restore operation has fully completed, in
order to avoid publishing the app's existence while it may still be in
an incoherent state. We now make this broadcast part of POST_INSTALL
in the restore case.
Bundled apps are in the 'started' state regardless, so no FIRST_LAUNCH
broadcast is ever sent for them -- this CL does not change that
existing behavior even in the case of setup-time data restore of
factory-installed packages.
Bug 28173625
Change-Id: Ibcc3758576662dc447b75476173a0d008a9fe4da
