SSAID is currently shared across all applications for each
user on the device, giving developers the ability to track
users across multiple applications. Using SSAID for tracking
is an abuse of the original intention of the SSAID and has
inherent privacy concerns.
This change will make the SSAID unique per application, per
user on a device. To not affect applications installed prior
to this change they will retain the legacy SSAID value until
uninstalled and reinstalled again.
Across subsequent installations the application will receive
the same SSAID as long as the package name and signature remain
consistent.
Tested manually the following cases:
- App retains the legacy sssaid after OTA.
- App gets a new ssaid upon post-OTA installation.
- App retrieves same ssaid across post-OTA unistall/reinstalls.
- Different Apps receive different ssaids.
- Factory reset removes ssaid data and generates a different
ssaid after App install.
- System retains legacy ssaid.
Bug: 30979321
Test: CTS tests passed, Manual testing passed
Change-Id: I4acc190c14ec249e6365e05e7943148ed6f17f71
This fixes two cosmetic issues in APK Signature Scheme v2 signature
verifier in Android Package Manager:
* Accept APKs with ZIP End of Central Directory comment of length
65535. Previously, only comments of length 65534 were accepted due
to a off by one bug.
* Accept APKs with empty ZIP Central Directory.
These issues should not affect actual APKs because they cannot have an
empty ZIP Central Directory (they must contain at least the
AndroidManifest.xml entry) and shouldn't contain any comments in ZIP
End of Central Directory.
Test: cts-tradefed run singleCommand cts --skip-device-info --skip-preconditions --skip-connectivity-check --abi arm64-v8a --module CtsAppSecurityHostTestCases -t android.appsecurity.cts.PkgInstallSignatureVerificationTest
Change-Id: I461c43472fa97c04e7579d129a6053e44233adb7
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Id7f0e8a4c861b0b9fa796767e0c22d96633b14d1
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ie267646eb88014034fbd048d7a9bc273420c7eff
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ib8e50afcdb5475123968572ac9696e8ed4031631
- Add a set of write methods to ProtoOutputStream that figure out the type.
The other methods are doing all the type checking anyway, so this won't be
much slower, and it's way easier to use. The expected java type casts
that people would do anyway happen inside.
- Add writeObject and writeRepeatedObject methods that write a pre-encoded
object.
- Add a constructor that takes an OutputStream, and a flush() method. Right
now, all the data gets flushed at the end, but given this API it would be
possible to write smaller chunks at the object boundaries and do more
sophisticated buffering.
Test: CTS
Change-Id: Ieb852092d3d65812c81139558151de9e3f467dc8
If the constuctor throws, then the handles would be closed without
setting "closed" to true. As a result, the finalizer would close
the handles again, which would cause a crash on the native side.
Test: Unit tests are no longer flaky.
Bug: 33301253
Change-Id: I527ba38d5d65ce844258d894441d4fe16bac6e23
Previously, they weres using libcore.io.Base64, which is @deprecated.
The two implementations' encoders produce the exact same result.
The two implementations' decoders' behavior differs for malformed
input:
- In case of error, libcore.io.Base64.decode() returns null while
java.util.Base64.getDecoder().decode() throws.
- java.util.Base64 tends to be stricter about rejecting malformed
input; specifically, it allows neither whitespace nor unexpected
'=' characters (should only occur in the padding) whereas
libcore.io.Base64.decode() leniently allows them throughout the
input.
- if the input terminates prematurely, libcore.io.Base64 tends to
return fewer bytes (stops at a four byte boundary).
The behavior differences for malformed Base64 encoded data should
not affect ShortcutPackageInfo because it should only need to deal
with XML attribute values written by itself, which are well-formed.
Note that this CL does not lead to any known changes of the encoding
step, so values written by earlier versions should not cause problems
when read by later versions of ShortcutPackageInfo.
StrictJarVerifier may now reject or behave differently for .jar /
.zip files with malformed attribute values but this seems okay since,
per its name, it is meant to be strict. For example, after this CL,
StrictJarVerifier will no longer accept algorithm + "-Digest"
attribute values with extra whitespace or padding characters as valid.
Test: Confirmed that the two implementations' encoders produce the
same result by running the following code just before this CL:
assertEquals(
libcore.io.Base64.encode(allBytes()),
Base64.getEncoder().encodeToString(allBytes()));
where allBytes() returns a byte[] with values (byte) 0 .. (byte) 255
Test: Test that phone still boots after flashing code that includes
this CL.
Test: CtsLibcoreTestCases
Bug: 31292683
Change-Id: I775d32f329f693514a8f14d87e1ef0d7a757e6c3
This class can be used to define color spaces. A color space has a color model
and a profile connection space (CIE XYZ D50). This implementation can be used
to query various properties of RGB color spaces or perform conversions between
various color spaces (RGB, XYZ and Lab).
Refer to the documentation for more details.
Test: cts-tradefed run singleCommand cts-dev --module CtsGraphicsTestCases --test android.graphics.cts.ColorSpaceTest
Bug: 32984164
Change-Id: Ie2117c1212c1375a7d403d3c1afaf73d7c2e0b47
Extracted duration measurement functionality into BootTimingTraceLog.
It is now shared between system_server and zygote.
Log the following metrics to tron:
- boot_zygote_init - Time in milliseconds to boot into Zygote init stage.
- boot_android_init - Time in milliseconds to boot into Android init stage.
Test: manual - device boots, metrics are logged to system/event log
Bug: 32780225
Bug: 31115337
Change-Id: I600ac7fc83d35fa226ac92c37cc4b19192b25f59
