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
This CL has a companion CL to add the @HalfFloat annotation to the
support library.
Test: cts-tradefed run singleCommand cts-dev --module CtsUtilTestCases --test android.util.cts.HalfTest
Bug: 29940137
Change-Id: I4e1dc456687c1c026437150e9cc94a54f3264d4e
Half floats (often called fp16) are commonly used to store floating
point data efficiently without having to use lossy compression schemes.
Half floats are commonly used in the following cases:
- Wide gamut colors
- Meshes (OpenGL and Vulkan)
- HDR images/textures
- Lookup tables as textures (OpenGL and Vulkan), particularly
in physically-based renderers
- Maching learning/compute
OpenGL and Renderscript both provide Java language APIs that accept
half floats but the platform offers no support to create fp16 values
from fp32 data. The Half class is an IEEE 754 compliant implementation
of half floats that can be used to feed OpenGL and Renderscript properly
encoded values. A comprehensive series of test is also added to CTS.
Test: cts-tradefed run singleCommand cts-dev --module CtsUtilTestCases --test android.util.cts.HalfTest
Bug: 29940137
Change-Id: I908bde7b3c6f65f7a24e0ab5652be4d16cc0358d
Denormals are fully supported.
This will be useful to store wide-gamut colors in a compact form
(a full RGBA color can be stored in a long using half floats for
each component).
Test: cts-tradefed run singleCommand cts-dev --module CtsUtilTestCases --test android.util.cts.HalfTest
Change-Id: I7e071edd2b66fdf6b375ce0e3e1a72ec3fb635b5
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
The classes there add a way for the platform to write out
protocol buffers that doesn't require lots of small objects,
generate code, and extra copying.
Includes the plugin for protoc to generate the constants.
Test: proto cts tests
Change-Id: I6385c198cecda9ac6fa533151609e3ace341af01
This patch fixes the following issues in LocalLog:
- reverseDump() uses a descending iterator with linear complexity
instead of a quadratic loop using get(index) on a linked list.
- reverseDump() is added to ReadOnlyLocalLog.
- synchronized section in log() is restricted to mutation of internal
list.
- formatting of the log message does not create an internal
StringBuilder.
- the instance variable mNow is removed: it was only used inside log()
as a local variable.
- remaining instance variables are qualified with final.
- the linked list is replaced by a fixed capacity array-backed queue.
Test: added unit tests
Change-Id: I1a54f0ad26dd35448d3297ea24df1fd626d20ef3
Sync adapters without an account access cannot run until the
user approves the account access (for the case the account
access is not allowed by other policy such as being singed
with the same cert as the authenticator). If the sync adapter
does not have permission to access the account we ask the
user to grant access and take a note. This CL adds backup
for the explicit user grants.
bug:31162498
Change-Id: I31e3f3d010475352c7c54255ac2d3a2fed4d0c72
Sync adapters without an account access cannot run until the
user approves the account access (for the case the account
access is not allowed by other policy such as being singed
with the same cert as the authenticator). If the sync adapter
does not have permission to access the account we ask the
user to grant access and take a note. This CL adds backup
for the explicit user grants.
bug:31162498
Change-Id: I31e3f3d010475352c7c54255ac2d3a2fed4d0c72
Use ParcelFileDescriptor only as an IPC transport
to make sure MemoryIntArray manges its backing fd.
Bug:30310689
Change-Id: Ib3cc13ef4ae2a744e5f7a96099570e0431847bce
1. Add close guard
2. Adopt instead of clone the ahsmem fd to fix a dangling fd
3. Clear only the return flag when writing fd to parcel
4. Immediately destroy remote MemoryIntArray if stale
5. Throw Java exception if someone closed the fd under us
Change-Id: I85533fec336c40e3380e10d5448e18c9616ec341
Instead of crashing, log a wtf and recover. This is not a problem
in ArraySet, but caused by someone else using an ArraySet without
protecting access to it. So whoever is calling at this point is
not the cause, and it isn't worthwhile to let them crash.
Change-Id: Iaefa4315b620c9fe24b31507e4aa47a8525c8540
Clean up style issues in preparation to copying ArraySet
implementation to support library.
Fixed:
- Missing spaces around operators, casting
- Added curly braces around if statements that span multiple lines
- Renamed static variables to follow sFoo instead of mFoo
- Moved = to the previous line
Bug: 19109652
Change-Id: Id9a985723b158f51811b3cd796613d0e26fd7e61
Before the second thread canceled the call from the first thread as the
awaitedSequenceId was set to the second thread.
Change-Id: I7de709dee260a009761e0a3e73f3fe0695d2da2a
