Emulator QA found this popup too noisy
to be useful.
Bug: 222604628
Test: boot the emulator, copy on the host
Test: check if there is no popup in the guest
Change-Id: I46323732a64202dabdd3a43bf17df7e7f3f9dd9c
Signed-off-by: Roman Kiryanov <rkir@google.com>
Add a Y2038 check into the time_detector and add infrastructure to allow
command-line testing to confirm it works.
This is before removing a Y2038 check from NITZ parsing code in the
telephony process. After this change, Androdi will consistently block
>= Y2038 suggestions, not just time signals that come in via telephony.
The initial checks attempt to limit the restriction to devices with
32-bit ABIs, since the main issue we're aware of is that time_t is a
32-bit signed int under bionic, hence there could be issues with that
type in 32-bit processes on 32-bit / mixed 32/64-bit devices.
Bug: 204193177
Test: adb shell cmd time_detector suggest_network_time --reference_time 2480587 --unix_epoch_time 1646473966056
Test: Run with 32-bit + 64-bit only builds, inspect adb shell dumpsys time_detector
Merged-In: Ib9d6472f5ca7a62d59b3224f1845846f99a0b52d
Change-Id: Ib9d6472f5ca7a62d59b3224f1845846f99a0b52d
Implement support for Ed25519 signing keys in Android Keystore.
Because Conscrypt does not yet handle those keys, the Keystore classes
implement EdECPublicKey directly and parse the keys.
Specifically, AndroidKeyStoreEdECPublicKey can take an encoded X.509 key
specification, validate the encoding is of an Ed25519 key, then parse
the oddity and Y point on the curve.
RFC8032 describes EdDSA signature scheme, particularly Ed25519.
RFC8410, Section 3, defines the OID for Ed25519 keys (1.3.101.112).
RFC8410, Section 4, describes the encoding of the public key.
Bug: 195309719
Bug: 194359292
Bug: 214203951
Test: atest android.security.keystore2.AndroidKeyStoreEdECPublicKeyTest
Merged-In: I07b793cbd5029630768368ad4a863bbc1c828ced
Change-Id: I477e87658b98bc3340da9a062d81508aad041c07
Os.read and Os.write don't throw exceptions if
`fd` is closed on the other end.
Bug: 231345789
Test: save a snapshot
Test: use clipboard both, check if there is no
Test: infinite loops which sets the clipboard
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: If98fb3adf58f2e4e13d483b78ea05ea9d8d61b58
Unsetting platform_apis while keeping sdk_version as is does not affect
the module's deps
Test: m queryview && builozer 'print soong_module_deps' :target (to
ensure the deps aren't affected
Bug: 219755537
Change-Id: Ic0d02c5e7fec24843e4cd2541cc5106381c7180e
This reverts commit 160172d92d.
Reason for revert: Should have removed platform_apis instead because
removing platform_apis doesn't change the module deps (done in aosp/2085943)
Test: CI
Bug: 219755537
Change-Id: I9657e569d942bf845c79352a042553c6fc6b0fd3
These two databases are (nearly) identical but the latter is generated
in a much more efficient way.
The diffs are very minor and it's not clear to me which versions is more
correct than the other, though I'm fairly confident they don't matter.
https://paste.googleplex.com/5567994005553152
Droidstubs now support using the api-versions.xml from another
droidstubs module, so reuse the one from api_versions_public
in framework-doc-stubs.
Bug: 187398174
Test: diff api-versions.xml
Test: diff stubs of framework-doc-stubs
Change-Id: I774be9097e97d6b180fe54d799c94515780be6ec
Some of these functions are called from IsolatedCompilationMetrics, a
class added to the system server classpath by the (non-updatabale)
com.android.compos APEX. Without this they are stripped as apparently
unused, leading to system server crashing when we try to call them.
Bug: 231271783
Test: Stage APEX, observe no crash, job scheduled successfully
Test: atest CompOsSigningHostTest#verifyArtUpgradeGeneratesAnyArtifacts
Change-Id: I5ad0249b0aae87e98ebdd3deb6e8c58bfb691ebc
Merged-In: I5ad0249b0aae87e98ebdd3deb6e8c58bfb691ebc
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
