Apps seem to rely on this undocumented behavior so that the
threaded sync adapter doesn't crash an app. That's really
bad on the app side, but we will have to live with it.
Bug: 67986472
Bug: 70122540
Test: m
Test: Device boots
Test: m cts && cts-tradefed run commandAndExit cts-dev --module CtsContentTestCases -c android.content.cts.SharedPreferencesTest
Change-Id: I1ee4dfba4ad29c4f66fa60d3c8f8a99900b3447a
The asynchronous loading code is not safe wrt/ exceptions. Instead
of adding a tri-state for loading, move the code to use a Future
for the map. This encapsulates the required wait & synchronization,
as well as propagating any exceptions.
Bug: 67986472
Test: m
Test: Device boots
Test: m cts && cts-tradefed run commandAndExit cts-dev --module CtsContentTestCases -c android.content.cts.SharedPreferencesTest
Change-Id: I6616e8a05e64eb1cfe024cc3239a05847dfe1fab
Clean up in preparation for an implementation change. Add missing
annotations. Rename inner lock to be uniquely named. Use the local
map instead of mMap in the commit logic.
Test: m
Test: m cts && cts-tradefed run commandAndExit cts-dev --module CtsContentTestCases -c android.content.cts.SharedPreferencesTest
Change-Id: Id3a798732c83a4aa6487225e2375ade4985852e2
When two processes modify shared preferences we use the timestamp to
figure out if the file was changes underneath. Do this with the highest
precision available (instead of sec) as before.
It would be possible to make the check more reliable by writing a unique
id to the shared pref file, but this would make this check much more
expensive in the common case that nothing changed. Considering that this
has not been a problem and we don't officially give any guarantee for
this sounds like a good middle-ground.
(cherry picked from commit ffe74357ae)
Merged-In: I04c96b6a946618d5599c26410c88d7cd654d31fb
Change-Id: I04c96b6a946618d5599c26410c88d7cd654d31fb
Test: SharedPreferencesTest
Fixes: 62949739
Fix typo in Activity class in requestPermissions method
Test: Existing unit tests still pass.
Bugs: None
Change-Id: If81117a0e769bca2f303e1ebce57ecda9544e129
Signed-off-by: Ahmad Melegy <ahmad.melegy@gmail.com>
We previously used the realpath to simplify the validation and processing
in installd. However it ended up making things more complicated when
cleaning up the profiles, especially because of /data/user/0 symlinks to
/data/data/.
Instead of using the realpath of the dex file to compute the profile
location, use the file path as given. This makes things consistent with
DexManager registration and allows for easier dex file reconciliation in
the presence of symlinks.
Bug: 64460009
Test: manual
(cherry picked from commit c119c5a8c1d8e3ba6c90300a82d2086273d0d3f3)
Merged-In: I2362f32a679324d4bc1e8a0fe83b5b17ee523e7a
Change-Id: Ic9c38a920c5eef85f26ac33f2b8a37c3694bfbad
This changelist removes checks that enforce that only fullscreen,
opaque activities may request orientation changes. An application
may itself be compatible with the change and update their SDK level.
However, it is possible they use a library that has not itself been
updated and still leverages this feature for non-fullscreen
activities.
Fixes: 68684796
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Change-Id: I75bbda96b132694c722b0b535e33ea5e1b9a55db
A user can manually enter time value using a keyboard.
NumberPicker then evaluates its value when focus is changed.
Currently when the dialog is closed by pressing OK, the value
from the focused NumberPicker is not taken into consideration.
To ensure retrieval of the correct value when closing the
dialog, the focus must be removed from the NumberPicker as
is done in DatePickerDialog.
Bug: 65664546
Test: Manual
1. Connect physical keyboard via OTG connector
2. Enter Settings and set time manually
3. Select keyboard entry
4. Change time and tap OK
The entered time should be applied
Change-Id: I8a77cb3aaa54acb228ec1ce0e9385e2eb5e88e9b
Record the class loader context for secondary dex loads and pass it to
dexopt during compilation.
The class loader context is passed from libcore every time a
BaseDexClassLoader is created and its recorded in the package dex usage
file.
Note that the context may be:
- unknown: if the dex file was not use after the the upgrade and its
context was not yet updated
- unsupported: if any of the class loaders from the loading context is
unsupported (only PathClassLoader and DelegateLastClassLoader are
supported).
- variable: if it changes over time, form one run to another.
In all the above cases the old compilation behavior is preserved for
now.(i.e. the dex file with be compiled with SKIP_SHARED_LIBRARY_CHECK)
(cherry picked from commit f1ff36f0f9)
Bug: 38138251
Test: runtest -x
services/tests/servicestests/src/com/android/server/pm/dex/
adb shell cmd package compile -f -m quicken ^Csecondary-dex
com.google.android.gms
(cherry picked from commit 3bec94d78b)
Merged-In: Ie8b78c7c0d5de43733b3d116f8dcb3a65324cca8
Change-Id: Ie8b78c7c0d5de43733b3d116f8dcb3a65324cca8
Move the secondary dex profiles inside the oat folder. This makes it
easier to clean them up and "protects" them against apps which may delete
unknown files from their directories (e.g. search).
(cherry picked from commit eec18f41e2)
Bug: 62336157
Test: Manual: boot the device, use the app, check the profiles are
collected in the new location.
Merged-In: I2fbce7591589d162775e4652b12e4698083adcff
Change-Id: I2fbce7591589d162775e4652b12e4698083adcff
New quota APIs are much faster than trying to measure manually, and
removing this last user of calculateDirectorySize() means we can
remove it once and for all.
(cherry picked from commit c8b29ac6f0)
Bug: 36056324
Test: builds, boots
Merged-In: Ibdf1ee4e8885680e106df6a9269b6309ddc61af8
Change-Id: Ibdf1ee4e8885680e106df6a9269b6309ddc61af8
Be more explicit about users executing processes in the time
zone updates code.The code was already running everything as the
system user but now that's more explicit / by design.
To service unit tests:
make -j30 FrameworksServicesTests
adb install -r -g "${ANDROID_PRODUCT_OUT}/data/app/FrameworksServicesTests/FrameworksServicesTests.apk"
adb shell am instrument -e package com.android.server.timezone -w com.android.frameworks.servicestests \
"com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner"
Bug: 64111659
Test: Unit tests: See above
Test: Manual testing installing updates as secondary device user
Test: PTS: run pts -m PtsTimeZoneTestCases
Change-Id: Idb754f3e1aa3830ba1ada8ef5740f9f7340f03d5
Merged-In: Idb754f3e1aa3830ba1ada8ef5740f9f7340f03d5
(cherry picked from commit 1281f39f86)
Rename the opt-out flag in AndroidManifest to
SERVICE_META_DATA_SUPPORTS_ALWAYS_ON
as directed by the API Council.
Bug: 64331776
Bug: 36650087
Test: runtest --path java/com/android/server/connectivity/VpnTest.java
Change-Id: I24326fad7a89083a2409134640bda81ee0359d08
Merged-In: I24326fad7a89083a2409134640bda81ee0359d08
(cherry picked from commit c57a01c166)
Always-on VPN is a feature introduced in N. Since then, all VPN apps
targeting N+ are assumed to support the feature, and the user or the DPC
can turn on / off always-on for any such VPN app. However, a few VPN
apps are not designed to support the always-on feature. Enabling
always-on for these apps will result in undefined behavior and confusing
"Always-on VPN disconnected" notification.
This feature provides a new manifest meta-data field through which a VPN
app can opt out of the always-on feature explicitly. This will stop the
always-on feature from being enabled for the app, both by the user and
by the DPC, and will clear its existing always-on state.
A @hide API is provided to check whether an app supports always-on VPN.
Documentation is updated to reflect the behavior change.
Bug: 36650087
Test: runtest --path java/com/android/server/connectivity/VpnTest.java
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Change-Id: I477897a29175e3994d4ecf8ec546e26043c90f13
Merged-In: I477897a29175e3994d4ecf8ec546e26043c90f13
(cherry picked from commit 3673863f3b)
To clear all overlay packages, the caller of
ResourcesManager#applyNewResourceDirsLocked will pass in null as the
second argument. Fix typo where the argument's annotation misspelled
@Nullable as @NonNull.
Change-Id: I7218f17ac8f121924e722d3e00d3ebdc4d6f3382
This is a partial cherry pick of commit
3bec94d78b.
It is partial because it only adapts DexLoadReporter to use the new
reporter BaseDexClassLoader.Reporter API.
Bug: 38138251
Test: make
Merged-In: I2486522fb811f9fc58a44b92642f43a41e7d5bac
(cherry picked from commit 3bec94d78b)
Change-Id: I4c41dbeb8a9297caac8b0eb936cf74832569f33e
Test: set different wallpapers for different users and switch between them.
Test: re-ran cts tests at cts/tests/app/src/android/app/cts/WallpaperManagerTest.java
Change-Id: Ic06d1dc6db26869a2948590863ca9b8ac81c630e
Merged-In: Ic06d1dc6db26869a2948590863ca9b8ac81c630e
Fixes: 63513694
Since IntentService is subject to the O background restrictions,
most devs are better off switching to the new JobIntentService.
(I assume IntentService is not actually deprecated; if it is, tell
me and I'll change this to a @deprecated tag!)
See first comment for doc stage location.
Test: make ds-docs
Bug: 64159987
Change-Id: I83a53d1e6336c2134bf4c61bedd2ae42cd80493a
Since appBounds encodes both dimensions and positions, movement will
cause a diff change. This happens in situations where the dimensions
stay constant, such as dragging a PiP window around.
To avoid flooding the client side with configuration changes, this CL
checks whether the new configuration is equivalent to the existing
configuration with the exception of the position of the appBounds
before sending to the registered callbacks.
Change-Id: I8fbc94458fd9ed3b39494c3587f25e704ec02a7d
Fixes: 63927944
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
Test: go/wm-smoke
We are already taking care of updating AssetManagers affected by
path changes to a running app's ApplicationInfo. There is no need
to invalidate ALL AssetManagers, thereby unregistering them
from ResourcesManager and preventing configuration changes from
reaching them.
Bug: 64004601
Test: manual
Change-Id: I39311ec9b1dfd34eb7025836f75c92e0516bc36b
We added a couple of protection flags that also apply to
normal and dangerous permissions. These flags are folded
in the protection level breaking apps that directly and
compare against the protection constants. Apps that target
older than O SDK don't get protection flags folded into
the protection level.
Test: All permission tests pass
Added a new test to ensure no protection flags reported
for normal and dangerous permissions
Change-Id: I87b10a7695d8ecfa7156525d6f3d101fc0639513
bug:62755026
We added a couple of protection flags that also apply to
normal and dangerous permissions. These flags are folded
in the protection level breaking apps that directly and
compare against the protection constants. Apps that target
older than O SDK don't get protection flags folded into
the protection level.
Test: All permission tests pass
Added a new test to ensure no protection flags reproted
for normal and dangerous permissions
bug:62755026
Change-Id: I72547b0146e6b6919803e33ff64b7208c4a255ad
