The Log.setWtfHandler() provides a way to override
the default TerribleFailureHandler, so that we can
test that a piece of code reports as terrible
failure as expected.
Unfortunately, we can't actual use setWtfHandler()
at the moment. The problem is as follows:
1. The Log.setWtfHandler() method requires a
Log.TerribleFailureHandler instance.
2. The Log.TerribleFailureHandler interface requires
subclasses to implement a onTerribleFailure()
method. The method requires a Log.TerribleFailure
argument.
3. Log.TerribleFailure is a private inner class.
Given the above, classes outside of Log can't create
an appropriate argument to pass to Log.setWtfHandler().
To resolve this, we update the visibility of
Log.TerribleFailure to be the same as that of
Log.setWtfHandler(), and Log.TerribleFailureHandler.
Test: m -j32
Bug: 37425059
Change-Id: Ie646b931869582398d61495e367e0d36e767a3e3
There is no longer a name size limit to the properties, remove
illegalArgumentException if tag length is too large.
Test: build
Bug: 36696208
Change-Id: I4b4329c8c951082ed0d777cdd70ee3e773bed16c
This patch adds several utility methods to IntArray and LongArray to
make them more useful in the context of a Parcelable class.
More specifically, it is now possible to parcel and unparcel a
{Int, Long}Array with the following one liners:
- mIntArray = IntArray.wrap(parcel.createIntArray());
- parcel.writeIntArray(mIntArray.toArray());
This patch also
- adds unit tests for IntArray and LongArray.
- adds a method for setting a field at a given index.
- adds a method for changing the effective array length.
- adds missing bound checks for negative index values.
Test: added test coverage
Bug: 34901696
Change-Id: Ia0febf4dae048b0a45c75310b5d90b56499320da
Do not use Pattern.toString to construct complex patterns. Instead,
make the string literals explicit so they can be compile-time
allocated, thus ending up as clean memory in the image heap.
Bug: 34956610
Test: m
Test: Device boots
Change-Id: I20d45c31243af00168553c218f75fb0795b55149
If an Exception thrown by a Binder call implements the Parcelable
interface, then parcel it and rethrow back at the caller. There is
strict requirement that these Parcelable exceptions must be defined
by the system (as determined by checking the ClassLoader). We prefix
the Parcelable contents with a length so that native code can skip
over the blobs.
Define a new ParcelableException class that can be used to transport
exceptions that cannot be modified to add Parcelable behavior, and
switch ExceptionUtils to use this new class for sending IOExceptions.
Test: builds, boots, wrapped exceptions work
Bug: 33749182
Change-Id: I1352ea1566ddf01120d9d0e819ba6f70fc407e11
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
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
Fix a bug where the DisplayMetrics wouldn't be updated for a Resources
object on the default display. Since multi-window, we want to update
all Resources.
This didn't always manifest itself due to recreation of assets, which
would force an update of DisplayMetrics. Re-use of an AssetManager from
the cache would expose the bug.
Bug:32133693
Bug:31998629
Test: cts-tradefed run cts --module CtsServicesHostTestCases
Change-Id: Ic51ab82710517b87eb995ccf982085dba876ad58
