Instead of keeping reading the whitelist everytime, we want to store it in
Settings.Global variable and reuse it later.
BUG: 120869311
Test: Build, flash and boot.
Change-Id: I5e39757383c5ba7d31af7efb3e6e8a2996e669f4
- Drop Content Capture events when the session is disabled, otherwise sessions
on this state might never finish.
- Fixed PII leak.
- Created helper class for common stuff.
- Improved logging.
Test: manually chenged VERBOSE to true, restarted system_server, and watched logcat - without
this change, launcher's session would never die because it kept re-scheduling flush
requests.
Test: atest CtsContentCaptureServiceTestCases
Bug: 122959591
Change-Id: Idcc1bbb12763d1cf98149164c68c2712834d5112
PackageManagerShellCommand defaults to the versionCode contained in
PackageInfo.ApplicationInfo if ApplicationInfo is present. Set
longVersionCode to both PackageInfo and ApplicationInfo, and also change
PackageManagerShellCommand to use longVersionCode instead of the
deprecated versionCode.
Test: atest android.content.pm.PackageParserTest#testApexPackageInfoGeneration
Test: atest apex_e2e_tests
Bug: 123228186
Bug: 123086053
Change-Id: Ief32f708ba2fa997ac4175134db5bfac2e5eb1d2
Vendors can still set the default behavior by pm.dexopt.priv-app-oob*
system properties, but still the experiment flag can override the
behavior.
This change also removes the audit log because the setting provider is
not ready. The old code works because we use the default system property
(which may be inconsistent to settings).
Test: cmd package compile -m speed -f com.google.android.dialer
am start com.google.android.dialer
cat /proc/`pidof com.google.android.dialer`/maps |grep oat |grep /data
# Compiled code IS mapped as executable
Test: device_config put fsi_boot oob_enabled true
pkill com.google.android.dialer; am start ...
# Compiled code is NOT mapped as executable
Test: device_config put fsi_boot oob_enabled false
# Compiled code IS mapped as executable
Test: device_config put fsi_boot oob_enabled true
device_config put fsi_boot oob_whitelist com.android.vending,com.example
# Compiled code is NOT mapped as executable
Test: device_config put fsi_boot oob_enabled true
device_config put fsi_boot oob_whitelist com.android.vending,com.google.android.dialer
# Compiled code IS mapped as executable
Test: device_config reset untrusted_clear
# Compiled code IS mapped as executable
Test: atest DexManagerTests
Bug: 120793002
Change-Id: I67f29ac593bd2c33dc8c75ce2135cf9ec5490650
This is a preparation to mark
InputMethodManager#setCurrentInputMethodSubtype() deprecated.
InputMethodManager#setCurrentInputMethodSubtype(), which was
introduced in Android 4.0 ICS [1], was probably mistakenly exposed as
a public API, because it has required WRITE_SECURE_SETTINGS that
typical applications cannot have.
Keeping maintaining InputMethodManager#setCurrentInputMethodSubtype()
is not that simple because now we are about to enable per-profile IME
mode, where this method needs to have a more clear spec about what
"Current" means.
An ideal solution is just removing this method, because if the caller
already has WRITE_SECURE_SETTINGS permission, they can just directly
update Settings.Secure.SELECTED_INPUT_METHOD_SUBTYPE to achieve the
same goal. However, given that this has been a public API, it would
probably make sense to provide a fallback implementation like I did
for null IME token in InputMethodManager#setInputMethod() [2].
Either way, InputMethodManager#setCurrentInputMethodSubtype() will be
marked as deprecated in a subsequent CL.
[1]: I55daa19ba924999def544bf841f00bf54852f3e1
b66d287e30
[2]: I42dd0325b01c527009bf85566ca8ba0766b2294e
0c1ebffdb3
Bug: 123249820
Test: manually done with a test app that has WRITE_SECURE_SETTINGS
Change-Id: I76da83c57cffc6b73defccfd4a1b5734c958a97e
Bug: 121198030
Test: 1) atest RunBackupFrameworksServicesRoboTests
2) atest $(find \
frameworks/base/services/tests/servicestests/src/com/android/server/backup \
-name '*Test.java')
3) atest CtsBackupTestCases
4) atest CtsBackupHostTestCases
5) atest GtsBackupTestCases
6) atest GtsBackupHostTestCases
Manual testing:
1. Start secondary user -> verify fb-schedule file is created, full backup queue initialised
2. Verify fullbackup of 1 package for system/secondary users, [package] only exists for current user:
* bmgr --user [user-id] fullbackup [package]
* Verify in logs that backup is successful
* Uninstall/install [package]
* Verify data is restored
3. Verify fullbackup of 1 package for secondary user, [package] eixtst for user 0:
* bmgr fullbackup [package]
* bmgr --user [user-id] fullbackup [package]
* Verify in logs that backup is successful
* Uninstall/install [package] for secondary user
* bmgr --user [user-id] restore [token] [package]
* Verify the data restored is different from system user data and belongs to [user-id]
3. Verify backup of all packages for system/secondary users:
* bmgr --user [user-id] backupnow --all
* Verify system packages (android, settings, wallpaper) are skipped for secondary user
* Verify in logs that backup is successful
* Uninstall/install [package]
* Verify data is restored
Base -> Patchset 2: Update method calls to use asUser versions
Patchset 2 -> Patchset 3: Update opComplete callback to accept userId
Patchset 3 -> Patchset 4: Gate system packages from backup/restore for non-system users
Change-Id: Ic3986709ba4d46c0af9da45bb4dd682ee2aef3ce
The receiver of the broadcast would likely want to query the rolled back
packages via RollbackManager regardless, and it's not clear which
package to put when an atomic set of packages is rolled back.
Bug: 112431924
Test: atest RollbackTest
Change-Id: Ic8db00b62d8993e00a0dd2cb79ae68c430b45bb8
Rather than defining a new custom PackageRollbackInfo.PackageVersion
type.
Also clean up PackageRollbackInfo API by replacing public fields with
methods and picking better names.
Bug: 112431924
Test: atest RollbackTest
Change-Id: I68a91e07b8745df9c5ecb22fdccbfcd76385814a
To make it easier to specify what rollback to perform when a rollback is
executed.
Bug: 112431924
Test: atest RollbackTest
Change-Id: I860ad443848341fbb99169a05b084fa797c5e08c
* Add cancelBugreport method.
* Remove unused arguments to onFinished listener call.
* Publish the system service now that sepolicy for it
is submitted.
* Use the new bugreportd service.
Test: boots
BUG:111441001
Change-Id: I12d72e0e1f4ca72d285fd02a3fc1a44f5c179885
