We now make sure, when scanning post-factory app installs, that we do not
accidentally activate a "leaked" or otherwise superfluous APK tree that the
scan algorithm happens to encounter before the one that we expect a priori
based on the persisted package-installation state. When we find such an
extraneous installation we ignore it in favor of the expected one, similarly
to the policy used when collecting system-bundled packages that have been
updated.
Even if we find an unexpected APK for the package, if the expected one
turns out to be absent we fall back to the existing "we thought this app
was present and now it isn't" logic.
Bug 19602471
Change-Id: I141a93661946176c05d8cf52a123bdf75c8eef74
Ensures that the playback device turns on display output signal
upon receiving CEC command <User Control Pressed>.
Bug: 19518981
Change-Id: I4f898380c9ffc071da2357a51e61309ae5d233f5
(cherry picked from commit 9b8507c52ae845c8eed9fd9952bf66538934b8fd)
OEM unlock enabled bit is not computed in the checksum,
causing OEM Unlocking to be disabled after the second
reboot.
Bug: 19829441
Change-Id: I100bf5d3958b89323ee35b9e97b19c162209fcd7
A security leak was discovered whereby a malicious app could get the
IActivityContainer object from one app and use it to inject events
into another app. This fix removes the availability of the
IActivityContainer and replaces its one use with a method for
returning the information the IActivityContainer was used for.
Fixes bug 19394591.
Change-Id: Ib3cec25b25130cd8e098892c057742cfd575cfdd
Clearly document which methods in Vpn.java are designed to be used to
service a Binder call, and which must therefore check permissions and
clear the calling identity, and which methods are designed for
internal use only and which therefore need not check permission.
Add a new startLegacyVpnPrivileged method which bypasses the
permission checks, to be used by lockdown VPN which is a trusted
system service. Ensure that the existing startLegacyVpn method checks
permissions as this is used whenever we respond to a binder call.
Bug: 19311172
Change-Id: I34f13258ee7481f1356bc523124cf5db068b4972
1. If reportInetCondition says the network is not working, and
the network is already marked not validated, don't revalidate
it. This was superfluous and should save battery.
2. If reportInetCondition says the network is working, and the
network is not marked as validated, revalidated. This will
allow us to get out of a validated state quickly based on app
input (e.g., allowing GCM's exponential backoff timer to drive
revalidation instead of our 10-minute timer).
Bug: 19258761
Bug: 19209043
Change-Id: Iaa4bac82d117ed1f4088dab106e6f6ce46b34bc3
If a user is subject to a VPN, getActiveNetworkInfo() will return
the VPN's underlying network (e.g., TYPE_WIFI), so that apps that
call getActiveNetworkInfo to answer questions like "is the device
connected to wifi?" will continue to work. Make getNetworkInfo
do this as well: if the query is for a network type that is
underlying the current user's VPN, then return that network.
Bug: 19196545
Change-Id: Ic5a651735b927c758594a26d26a03fbd704b52e6
As a backstop against missed alarm delivery / wakeups or clock slew,
make sure to always schedule a kernel alarm for the next alarm events
of interest when we've reexamined the set of deliverable alarms.
Bug 19201933
Change-Id: I3cd37a63dfb0c8258941497d4ba516ed00e2edad
On networks with a per-network PAC, Network.openConnection(URL) will
fetch using NO_PROXY. This will fail on networks where Internet
access is only permitted via the proxy. Always failing network
validation has the potential to disable WiFi auto-join. Instead
of performing the normal connectivity check, instead attempt to
fetch the PAC, as this is meant to succeed with NO_PROXY.
bug:19143573
Change-Id: Ia482f5c046d338c27daf42571f20851dfa36671c
We were using an approximation to determine where to send a pair of down
and up events to click on the view that has accessibility focus. We were
doing reverse computation to figuring out which portion of the view is
not covered by interactive views and get a point in this region. However,
determining whether a view is interactive is not feasible in general since
for example may override onTouchEvent. This results in views not being
activated or which is worse wrong views being activated.
This change swithes to a new approach to activate views in accessibility
mode which is guaranteed to always work except the very rare case of a
view that overrides dispatchTouchEvent (which developers shouldn't be
doing). The new approach is to flag the down and up events pair sent
by the touch explorer as targeting the accessibility focused view. Such
events are dispatched such that views predecessors of the accessibility
focus do not handle them guaranteeing that these events reach the accessibiliy
focused view. Once the accessibiliy focused view gets such an event it clears
the flag and the event is dispatched following the normal event dispatch
semantics.
The new approach is semantically equivalent to requesting the view to perform
a click accessiblitiy action but is more generic as it is not affected by
views not implementing click action support correctly.
bug:18986806
bug:18889611
Change-Id: Id4b7b886c9fd34f7eb11e606636d8e3bab122869
If the scheduled job fires but backup is disabled or the device is
not yet provisioned (i.e. has not yet finished going through setup),
bow out gracefully without running any backup operations. Also, even
if a backup is directly invoked (e.g. via adb), verify again right
before we start collecting app data, and abandon the operation in
that path as well.
(This is redundant; having only the latter test would suffice, but
this lets us distinguish in the logging more easily.)
Finally, make sure that if we were waiting on setup before permitting
backup operations to begin, that we startup the full-data scheduling
as well as the [separate] key/value scheduling.
Bug 19197062
Change-Id: I3d8fb650c50f946d8ed7ac7170df361c707f2528
Make sure AVR device removal due to hotplug detection failure occur
in a less strict manner - doing it only if the failure is detected
3 times in a row.
Bug: 19171321
Change-Id: I1479663b05cdc957cc52123799c756f6b74f6708
The HdmiControlService.getActiveSource() has a regression (exception)
when calling getDeviceInfoByPath since method should be called on
a service thread. Introduced a method that can be invoked safely
from the main thread.
Bug: 19170884
Change-Id: I393161e08c916270faf46147a97076bc573b808f
Help devices be processed sooner when new device detection operation
takes longer than usual.
Bug: 19181472
Change-Id: I96c29081a9c7c9f73ebcd027ed9d18056dc89bf9
<Active Source> from the device which is already in active
source state is being ignored now, but it should work with an effect
of putting input view foreground in case it is hidden behind
home launcher overlay.
For better user experience, this change lets the command from
the active source takes effect to hide the overlay if present.
Bug: 19171319
Change-Id: I43d2646f2ad470b3636e82ff71ac83cf0031ef6c
In the case when some possible resolutions of a given intent are at
different priorities (typically when they're intended as fallbacks when
no "normal" handler for the intent exists) the check for "is this the
same set of possible handlers that we saw last time?" was broken. We
now ignore resolver priority entirely in that check: match set comparison
should be orthogonal to prioritization within the set, and indeed the
priority is dealt with separately in any event.
Bug 19011225
Change-Id: I3c1658442cc88b1f4a5c5f2fe9f64472799e156c
Taps outside of the stack boundary were causing the current app to
lose focus. This led to timeouts waiting for the app to respond.
Disabling the tap recognition keeps the focus from changing. It will
be reenabled for multiwindows.
Fixes bug 17721767.
Change-Id: Iad854b19979390e73b97239e489ad7ef82e03d47
Additional debug and useful information.
Also removed am_resume_activity verbosity and refactored method to
eliminate unused parameter.
For bug 17721767.
Change-Id: Ie1c0652a38a0c6ae6db27a52a9e5da29e252e300
