am: 1d3c594
* commit '1d3c59457c9bcf30e6ecb898e64d9d9725e7803e':
Make isCaptivePortal perform both HTTP and HTTPS probes.
Change-Id: Ic58f5be8dce42c17213ef261f348eda31c6c11e7
am: 831ecc8
* commit '831ecc81f982282bdcc2121c2fa3ece22ac997e0':
Show forced resizable based on top activity
Don't move forced resizable info activity to the front
Change-Id: Ib61028c751a31b437fb459bd094c2fedadd40abe
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
am: 1a2f993
* commit '1a2f993ba5a81899500b989683364708025e13a5':
Fix issue #28431297: Crash in system process
Change-Id: I46aec10a524e6864b414d12bb2a79bc24d8b47ae
am: 0731806
* commit '07318065b22ba13ae003d7803a3e48e441f9f6e5':
Make sure FIRST_LAUNCH is after PACKAGE_ADDED
Change-Id: I91418919b5907986d13b7f9e113ab4c02fa7746a
am: 0db93ce
* commit '0db93cea0fef6aa73caa0ef422b8e0a4e45a24e5':
Tethering and Data Saver: There Can Be Only One!
Change-Id: I876c9a30e9451b1c346296c233068bdfb579f584
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
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
Clarifying region used for magnification as "magnificationRegion",
both in the public API and in the code. There's been significant
confusion about what "magnfifiedRegion" means. Removing
"availableRegion" from everywhere except where it's required, as
that region was identical to magnified/magnification region.
Trying to shut down magnification was a complex situation where
animations in progress and new magnification requests were tricky to
handle correctly. It was not possible to guarantee that the
magnification callbacks were unregistered consistently. There were
at least two situations that led to phone restarts:
1. If a triple tap was detected between unregistering the callbacks
and shutting down the input filter. In this case the magnification
request would go through.
2. If an animation had just started when magnification was turned
off, so the current magnification was 1.0 but the animator was
about to change it. In this case the callbacks would be unregistered,
and then the animator would start changing the magnification.
This change makes registering and unregistering magnification atomic.
It also makes MagnificationController stick around indefinitely once it
is created, registering and unregistering as needed to support
magnification gestures and services that control magnification. Services
that merely query the status of magnification no longer register for
callbacks.
One part of shutting down is turning off the animation and guaranteeing
that it won't try to make further changes. Adding a flag to
SpecAnimationBridge and a lock in that class so we can guarantee that
nothing happens when we aren't registered for magnification callbacks.
Also reconfiguring all accessibility options when a service stops to
make sure that only the features required by the current configuration
are enabled.
Bug: 27497138
Bug: 27821103
Change-Id: If697cbd34b117d82c8eee1ba7d0254089ee4241d
Framework edition
If a loader is already started when we try to rollback a content
change, force a new load instead of simply setting the flag to refresh
next time.
Bug 28406183
https://code.google.com/p/android/issues/detail?id=208278
Change-Id: If11d79088d30dd2dc48cf1b3d2882f3712b6cddb
