Temporarily disabled new data stack until all CTS fixed
on aosp_master.
Fix: 226046162
Test: atest CtsNetTestCases
Change-Id: Ie40ca14ae986192542bc1318bd345d9d31562680
Invert the flag so even if this flag does not exist in the
resource, the new data stack is still enabled by default.
Fix: 228813515
Test: Manual && atest FrameworksTelephonyTests
Merged-In: I75737c0ef9bce91385f815133e1878e5abea68ff
Change-Id: I75737c0ef9bce91385f815133e1878e5abea68ff
Not create DcTracker and TransportManager instances
when new data stack is enabled.
Test: atest FrameworksTelephonyTests and manually tested on
Pixel 4 and Pixel 6.
Bug: 222323544
Merged-In: Ice595f329e2f4e531dc577cd3db7c863ba15d6d6
Change-Id: Ice595f329e2f4e531dc577cd3db7c863ba15d6d6
To hide other apps' data directories, zygote mounts tmpfs instances over
various directories such as /data/user, then bind-mounts in the needed
app directories. Files in tmpfs get the SELinux label "tmpfs" by
default. After creating them, zygote relabels some of these "tmpfs"
files to their normal labels; however, in every case the desired label
was "u:object_r:system_data_file:s0", so zygote just copied the label of
/data/user_de which happened to have this same label.
With https://r.android.com/2078213, the /data/user_de directory, but not
its subdirectories, will start being labeled as
"u:object_r:system_userdir_file:s0". This would break the
above-mentioned logic, as it would start assigning system_userdir_file
to files that should be system_data_file. Therefore, update it to
assign the appropriate type of [system_userdir_file, system_data_file].
Note that alternatively, it seems that we could just always use
system_data_file, or just remove this relabeling code entirely since the
sepolicy contains 'allow domain tmpfs:dir search' anyway. But as long
as zygote is trying to set the normal labels, it should do it correctly.
Test: Tested together with the sepolicy change
https://r.android.com/2078213; see there for testing notes.
Bug: 156305599
Change-Id: I325aa873cf216e33924d0508100fcc755f265cf2
/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
Provide a way for the system Setting app or other similar system
apps to set the app exclusion list for the specific VPN from
VpnManager. The list affects only VPN provisioned from
VpnManager to keep the design consistence for app using
VpnService.
The list is stored in the keystore for its persistence.
Bug: 192078259
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I157823866e1899b40aa36ea2c0bc4a80370108be
dataStateToString() will return string value of state
DATA_HANDOVER_IN_PROGRESS
Test: build & verified with AVD
Change-Id: I80e9bfd893144d1b23d6925a94e6569c10b7baa7
This change adds a utility to convert persistable bundles to and from
disk-stable byte arrays.
Test: atest FrameworksVcnTests:PersistableBundleUtilsTest
Change-Id: Ifafb7081ec6a34ce3ab8e2aa502d46411405cb6d
