Update to javadoc comments saying that for apps targeting N and up
the geolocation api is only supported on secure origins.
On non-secure origins requests to geolocation api are automatically
denied without calling the corresponding
WebChromeClient#onGeolocationPermissionsShowPrompt method.
BUG: 28080869
Change-Id: I57726f7f3b3d38db0535f742b1f74c40c1f1ce8b
Use a holder for an uncommon Pattern instance in FileUtils.
Allows to compile-time initialize:
* android.os.FileUtils
Bug: 28174137
Change-Id: I4a7a388795a96678b4b26e4f2c02b1117d6a67f6
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
Pinned stack doesn't have focus, so there's no need for setting extra
elevation to show shadow for focused case.
This removes extra eleavtion for pinned stack, and improves the PIP
animation quality by preventing extra surface size change
at the end of animation.
Bug: 27364161
Change-Id: Id099a78de48b2e038a69600c94454b5cbfe0628f
Since activity manager only issues a configuration change when
we are not relaunching the activity, the optimization to suppress
that on the client side is not needed anymore and only leads to
issues where there is a change in smallest_width but we are not
relaunching the activity because the change doesn't cross a size
threshold.
Bug: 28050773
Change-Id: I303c190bd7390363d1030edcdb2913b7c64c666d
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
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
List items are always positioned using the divider height, even if there
is no divider drawable, so we should account for that when calculating
list height.
Bug: 28402970
Change-Id: I14b8d3b04a369749ff4b7e6f1e6e003ac08f6b7f
Bug: 24088745
Use ViewGroup#getChildVisibleRect to transform the reported content
rect into the coordinate system of the root view. This allows the
floating CAB to be positioned correctly for views that may have a
scale (or other transforms) applied.
Change-Id: Ia6733a461b44070e7f6bab42f0b6fe2aed6870e5
Exports SOC specific low power state info to batterystats service.
BatteryStats service queries the powerHAL module whenever and
updates the HistoryStepDetails whenever setBatteryState is called by the
BatteryService. The stats get appended to the battery history whenever
there is a change in the battery level.
Bug: 26564574
Change-Id: I02b4db00aec0c69d1558492224f3a4dc1c386fa6
ViewRootImpl may be null at this point if
we didn't preserve. Sorry about the churn.
Bug: 28413589
Change-Id: Iebfd819490252b52332d94ccefbddfae160087cf
