Sync adapters without an account access cannot run until the
user approves the account access (for the case the account
access is not allowed by other policy such as being singed
with the same cert as the authenticator). However, if the
sync adapter package already got the account from another
app which means it already saw the account we white-list
the sync adapter app to access the account as it already
saw it - the bird is out of the cage.
bug:31162498
Change-Id: I2b72f3b0d6307561ed68db2f2e9c900b15e8d098
Explicitly state that "local state" is local to the window
which has started the drag operation.
Bug: 31372686
Change-Id: Idbea7586c4e74097362067fa90390b97744181bb
To address a security issue where a toast window can be
used by an app to overlay other apps without a permission
we now allow legacy apps to be able to put at most one
toast window on the screen to prevent adding the same
window over and over again to go around the new restriction
that toast windows are always removed after a timeout.
This change ensures that Toast removes its window immediately.
bug:31340854
Change-Id: Ia7f90844eb64b583321103d090e4407038b41547
(cherry picked from commit 1777c91f8f)
Issue:
Due to race conditions, if a recording frame callback is received
after a proxy listener is set to NULL, the callback is forwarded
to JNIContext which does nothing. This will lead to buffer leak
in metadata mode because fd would have been duped already.
Fix:
Release recording frame from JNIContext.
Bug: 30299751
CRs-Fixed: 1040448
Change-Id: I315ec3124014c6309d68fdc1be1e18091a84e154
Bug : 30143478
As of API level 21, the ACCESS_COARSE_LOCATION permission no longer
implies the android.hardware.location.network feature, and the
ACCESS_FINE_LOCATION permission no longer implies the
android.hardware.location.gps feature. Updated several docs
accordingly.
Bug: 28052540
Change-Id: Ia86dfd390f85c7a99b50af862d5096f0ac64a133
Filter ordering allows automatic disambiguation between multiple filters
that matching a pattern. Ordering currently only works for EphemeralResolveInfo
objects.
Bug: 30837021
Change-Id: Ia217218c7c7d159dbd75d7733c45556e690d06d2
Previously, when a Context Hub rebooted, this service would reset
all of the "handles" used to identify the nanoapps on the Context
Hub. This caused many issues for Java application code trying to
track nanoapps, and these issues were exacerbated under nanohub,
which reboots every times it loads an app.
We change this so that we keep the same handle across reboot if
the same nanoapp is still running post-reboot. We accomplish
this by never "invalidating" our caches, but rather performing
a query post-reboot and removing stale entries.
Due to b/30835598, we needed to change our post-load query to
be all apps. Without that change, a race between the two
query responses we would have post nanohub app load (one for
post-load, one for post-reboot) would leave us without knowing
which response we're dealing with. Now, since both requests
are the same, we don't care which response we deal with.
This is all (hopefully) just for the Nougat release. In the
O release, we hope to remove these caches (b/30835981) and
the idea of the JNI code inventing handles (b/30810861).
Bug: 30950975
Change-Id: I85a84ba5c1a039d69c1adaaea56609e0a38cce42
The updateRulesForRestrictPowerUL() method is used to set the
power-related restrictions for all apps and it ends up by calling
NetworkManagerService twice (and each call spawns an iptables process,
which takes ~50ms to complete). This method is called on some critical
paths, like when the device leaves Doze Light mode.
This change makes these calls asynchronously, hence reducing the delay
on such critical paths in the O(100ms).
Fixes: 31281543
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t
com.android.cts.net.HostsideRestrictBackgroundNetworkTests
Change-Id: If720a7112c72a18193ea9614ae187b7ed9c741ec
Prior to N, if a client received the surfaceDestroyed callback
from their SurfaceView they could trust that the surface would not be
reused. Now that is not true in multiple scenarios. If a client fails
to shut down its EGL context then, we could end up in a situation where,
the client will never disconnect. Then when we reuse the same
underlying IGraphicBufferProducer for surfaceCreated next
the app will crash with a double connect error. There is no valid
use of the surface inbetween surfaceDestroyed and surfaceCreated,
so we just force the disconnection after surfaceDestroyed.
Bug: 30236166
Change-Id: I2e3e4b3176492dc0c2d46a59e0b5a781bf9bc356
GMS uses a service proxy and needs the action to be able to route
the connection to the proper service.
Bug: 30805203
Change-Id: I4e2177170c19dd7572226fc4f7eb36f67592e45d
Fixes a bug where DozeService would not properly initialize
because the CPU went to sleep before onDreamingStarted completed,
causing the pickup gesture to not work.
Change-Id: I85955a2b7d6bad5171accbc336117a9660b1b198
Fixes: 31044352
updateRulesForRestrictPowerUL() should only affect the global
rules (Doze and Battery Saver), while app idle is an app-specific
rule. Such call was delaying setDeviceIdle() in O(100ms).
BUG: 31281543
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleNonMetered_enabled
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleNonMetered_whitelisted
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleNonMetered_blacklisted
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleMetered_enabled
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleMetered_whitelisted
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleMetered_disabled
Change-Id: I32ad6853a6d88e2709538d00cd1e77b96d331b2d
setPairingConfirmation was set to only require BLUETOOTH_ADMIN
permission which shouldn't be able to set the confirmation itself.
This is restricted to BLUETOOTH_PRIVILEGED permission.
Bug: 29043989
Change-Id: I887de32d156e672ec44aa0b286cd7ea7f9f8ad55
setPairingConfirmation was set to only require BLUETOOTH_ADMIN
permission which shouldn't be able to set the confirmation itself.
This is restricted to BLUETOOTH_PRIVILEGED permission.
Bug: 29043989
Change-Id: Iddc935f0b02f5ff56e930914b4b664377e786184
setPairingConfirmation was set to only require BLUETOOTH_ADMIN
permission which shouldn't be able to set the confirmation itself.
This is restricted to BLUETOOTH_PRIVILEGED permission.
Bug: 29043989
Change-Id: Iddc935f0b02f5ff56e930914b4b664377e786184
Because the user handles are not up-to-date, we need to update it when
necessary.
Bug: 30919785
Test: This branch doesn't support robo test, testcases will be added in
master branch when merged down(ag/1419729)
Change-Id: Ia095c3946c49db239e0b1b2bcc8588b02158c036
This patch adds releasing of MediaScannerConnection in ClientProxy
after disconnecting and releasing of ClientProxy and
IMediaScannerService in disconnection sequence in
MediaScannerConnection.
Bug: 30150344
Change-Id: I1e162e4c9a0b7a741ace20480bcf06f3151a93bf
