/data/system_de is only for per-user data; it *must* only contain
per-user encrypted directories. Only vold should ever create anything
directly in this directory. In preparation for removing system_server's
write access to this directory (https://r.android.com/2078213), make
BrightnessTracker store its brightness_events.xml file at
/data/system/brightness_events.xml instead of
/data/system_de/brightness_events.xml, and likewise for
ambient_brightness_stats.xml.
Migration happens lazily, except that the old files aren't ever deleted
since the SELinux policy will no longer allow system_server to do that;
the old files just stop being used. vold will need to handle the
cleanup instead, or we could just leave the files around.
Test: Flashed new build without wiping userdata. Log shows "Reading
ambient_brightness_stats.xml from old location" as expected.
Rebooted. Log message no longer appears, as expected. File
/data/system/ambient_brightness_stats.xml exists, as expected.
Bug: 156305599
Change-Id: I6e0948ac54ec9183348943234d505e7466042963
Internal storage must be prepared before adoptable storage, since the
user's volume keys are stored in their internal storage. Previously,
the order depended on the Java hashcodes of the volume IDs. It seems
that in practice things sort of worked out anyway even with the wrong
order, via a bizarre sequence of events involving the user's storage
being deleted and re-created several times. Regardless, let's fix it.
destroyUserData() sort of had the reverse bug, although I don't think it
actually mattered. My concern there was that destroying the internal
storage first would bypass vold's destroyKey() for the volume keys.
However, that's okay since the volume keys don't actually need a special
destruction procedure in this case. Also, internal storage has already
been locked when destroyUserData() runs anyway.
Test: On Cuttlefish:
$ sm partition disk:253,32 private
$ pm create-user 10
$ pm remove-user 10
Checked logcat for expected messages.
Bug: 231387956
Change-Id: I146d8c786c6b923aed7f8c748db8a7e90c96687f
/data/system_de is only for per-user data; it *must* only contain
per-user encrypted directories. Only vold should ever create anything
directly in this directory. In preparation for removing system_server's
write access to this directory (https://r.android.com/2078213), make
UsageStatsService store its globalcomponentusage file at
/data/system/usagestats/globalcomponentusage instead of
/data/system_de/usagestats/globalcomponentusage.
Migration happens lazily, except that the old file and directory aren't
ever deleted since the SELinux policy will no longer allow system_server
to do that; the old file just stops being used. vold will need to
handle the cleanup instead, or we could just leave the file around.
Note that before Android 11, UsageStatsService stored per-user stats in
/data/system/usagestats/$userId. These per-user stats are *not* the
same thing as globalcomponentusage, which was added in Android 12.
UsageStatsService contains code to migrate the per-user stats to
/data/system_ce/$userId/usagestats. This is fine, and is the right
thing to do, since the per-user stats are potentially sensitive per-user
data. This does mean that UsageStatsService now implements two types of
migrations, and that the source directory for one migration is the
target directory for the other, which is a bit unfortunate. However,
since different files are involved in each one, it all works out.
Bug: 156305599
Change-Id: I53c16640e8ed8b7eac111990f1cdb3f59579e051
NETWORK_TYPE_BITMASK_LTE_CA is not used anywhere even if it's
accidentally passed into setAllowedNetworkTypesForReason(). Will be deprecated in U.
Fix: 230383206
Test: atest cts/tests/tests/telephony/current/src/android/telephony/cts/TelephonyManagerTest.java
Change-Id: Id0c521c4fb74eaf7d73deaf122e923f72b924c18
Bug: 213183041
Change-Id: I043d3e7c24f59d17779f81c8a43109beecf7d881
Test: Manually verified by replacing it to US and sending messages to the short numbers
Apps are able to prevent their death by forking multiple processes
under different services and monitoring for the death of any of these.
When a child death is detected, the remaining process restarts the
terminating/terminated service before it's able to be killed itself.
This is now prevented by freezing all processes before killing any of
them so that no process can react to the death of another.
Bug: 148425913
Test: vsoc_arm64:/ $ monkey -p com.haok.nirvana 1
Test: bash arg: -p
Test: bash arg: com.haok.nirvana
Test: bash arg: 1
Test: args: [-p, com.haok.nirvana, 1]
Test: arg: "-p"
Test: arg: "com.haok.nirvana"
Test: arg: "1"
Test: data="com.haok.nirvana"
Test: Events injected: 1
Test: ## Network stats: elapsed time=3200ms (0ms mobile, 0ms wifi, 3200ms not connected)
Test: vsoc_arm64:/ $ ps -eo pid,uid,ppid,name|grep 10088
Test: 6827 10088 2973 com.haok.nirvana
Test: 6850 10088 2973 com.haok.nirvana:resident
Test: 6867 10088 2973 android.media
Test: 6895 10088 1 app_d
Test: 6899 10088 1 app_d
Test: vsoc_arm64:/ $ am force-stop com.haok.nirvana
Test: vsoc_arm64:/ $ ps -eo pid,uid,ppid,name |grep 10088
Test: 1|vsoc_arm64:/ $
Test: Also tested manually on Pixel 6 Pro
Change-Id: Ib0231eaf4b11b15a3d6bac5dc5486844f0f81d18
The /data/system_ce/$userId and /data/system_de/$userId directories are
created by vold, so they should be deleted by vold as well, and in fact
that would already happen except that system_server deletes them
recursively before vold gets to it. Change system_server to delete just
the contents of these directories.
This is a prerequisite to locking down the ability to create these
directories (https://r.android.com/2078213), which is needed to stop
subdirectories from accidentally being created too early. Technically
we could achieve this goal without limiting delete access, as it's
create access that really matters, but having the operations be paired
properly is much cleaner.
Test: Created and deleted a user, and verified that all their
directories still got deleted.
Test: atest UserDataPreparerTest
Bug: 156305599
Change-Id: Iec908e1bc15a00c7179fcd1d80321c315682d339
Removing all process groups during system_server startup can race with
process group creation from init which results in occasional failure to
create a process group and failure to boot the device.
Move process group purging into init to prevent such a race.
Bug: 228160715
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I2e50f53c9692424c994c0b4ee6f1e2762632c3bc
* changes:
Send VPN manager event when there is a network error
Send VPN manager event when there is an IkeProtocolException
Send VPN manager event when VPN is deactivated
Send VPN manager event when VPN always-on status is changed
Teach bit about @Ignored tests (resultCode -3). If any ignored tests
are found, bit will now print
Ran 10 tests for Foo. 10 passed, 0 failed, 1 ignored
However, if no ignored tests are found, bit will omit the "N ignored"
part.
Test: manual: bit CtsOpenGLTestCases:android.opengl.cts.CompressedTextureTest#testTextureATC, check output contains "0 passed, 0 failed, 1 ignored"
Change-Id: Ifde68efc99cb98bcf4a7bd73c389a846055c5449
By switching to 'adb exec-out' instead of 'adb shell', characters such
as # no longer need to be escaped when executing a single
instrumentation method. The new syntax is simply
$ bit module:class#method
Note: the old syntax (module:class\#method) still works.
Test: manual: bit InternalTests:android.app.WallpaperColorsTest#colorHintsTest, test should execute
Change-Id: I8c86faf2ccaf84834030f6ba7567cb4cecd37bc6
1. During the quick user switch, the user status is changed from
STATE_STOPPING to STATE_BOOTING, the process android.process.core
(ContactsProvider2) was not closed, but the AccountManagerService
cleanup the user in stopping stage.
2. When the user is switched back, the old ContactsProvider2
process was used, but the client doesn't have the listener
registered for AccountManager any more.
3. This causes the ContactsProvider reloaded again when the phone
is connected, then duplicated contacts will show on the screen.
4. Solution is cleaning up the user data in onUserStopped.
Test: manual verification
Bug: 224818967
Change-Id: I8fb44e0e66ff73c055a548d57ff3d45ecc213f71
