system/core/include is included in the global include path using
-isystem, which hides all warnings. Fix warnings in
system/core/include/system in preparation for moving from -isystem to -I.
- Fix invalid doxygen syntax in graphics.h
- Use a pragma to hide a C99 extension warning on the flexible length
array in graphics.h
- Make static functions in radio.h static inline
- Fix size_t printf and size_t vs. ssize_t comparision in qemu_pipe.h
- Fix old style cast in window.h
Test: m -j native
Bug: 31492149
Change-Id: I857f289e4c8e303494831873282bbb69de155c10
system/core/include is included in the global include path using
-isystem, which hides all warnings. cutils/trace.h has an ignored
return value warning, move the implementation to trace-dev.c so it
doesn't cause warnings in every module that includes it in preparation
for moving from -isystem to -I.
Test: m -j native
Bug: 31492149
Change-Id: If8b3fe13059c9e59c2d5208294d427d84fa6e588
system/core/include is included in the global include path using
-isystem, which hides all warnings. zlib.h is included through
system/core/include/ziparchive/zip_archive.h, which was hiding warnings
in it. Use a #pragma around the call to deflateInit2, it is a macro
that expands to an old-style cast, in preparation for moving from
-isystem to -I. Also move the ZipString constructor to zip_archive.cc
so it can assert on the length of the string parameter and fix an
implicit conversion from size_t to uint16_t.
Test: m -j native
Bug: 31492149
Change-Id: I74cdad7fe9c723859b5cfbea73c8f27d9d9ca265
system/core/include is included in the global include path using
-isystem, which hides all warnings. Fix warnings in log/log.h
in preparation for moving from -isystem to -I.
log/log.h uses gnu extensions for zero-argument variadic macro token
pasting, which clang warns about with -Weverything. Hide the warnings
using pragmas.
Test: m -j native
Bug: 31492149
Change-Id: Ib2113f877d811a6ecc0e91c035640b506f04bd86
It was probably the LOCAL_EXPORT_C_INCLUDE_DIRS that made me miss this on the
original code review...
Change-Id: I55bc0b0698604338cd206bf5f336798929b6d8f9
system/core/include is included in the global include path using
-isystem, which hides all warnings. Fix warnings in cutils/atomic.h in
preparation for moving from -isystem to -I.
Test: m -j native
Bug: 31492149
Change-Id: I2a212f192309090a16d507e9ab6acf0fd7cac02d
The android_color_mode_t defines the color modes supported
by a display. A display can support multiple different
color modes.
sRGB mode and AdobeRGB are deliberately placed at 7 and 8
so that they match mode ID's used on prior devices.
bug: http://b/27926012
Change-Id: I9ab41b56ec0b495c02539665da5be158ffddf843
If the underlying local map changes, it's possible for multiple
threads to try and modify the map data associated with the UnwindLocalMap
object. Add a lock when generating the local map to avoid this problem.
In addition, add a read lock whenever any caller gets the maps iterator.
Updated all iterator callers to make this lock.
Bug: 29387050
Bug: 31067025
(cherry picked from commit 3a14004c7f)
Change-Id: Id00116f156a24b36085c0d5dfc3dde4d2ac55194
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
Test: ran libutils_tests
Bug: 29250543
Change-Id: I6115e3357141ed245c63c6eb25fc0fd0a9a7a2bb
(cherry picked from commit c4966a363e)
String16(const char *utf8) now returns the empty string in case
a string ends halfway throw a utf8 character.
Bug: 29267949
Clean cherry-pick from 1dcc0c8239
Change-Id: I5223caa7d42f4582a982609a898a02043265c6d3
- check hdr_size to make sure it is in the expected range
from sizeof entry_v1 to entry (entry_v4).
- alter msg() method to report NULL on invalid hdr_size
- alter all users of msg() method.
Bug: 30947841
Change-Id: I9bc1740d7aa9f37df5be966c18de1fb9de63d5dd
Modify FrameworkListener to ignore commands that exceed the maximum
buffer length and send an error message.
Bug: 29831647
Change-Id: I9e57d1648d55af2ca0191bb47868e375ecc26950
Signed-off-by: Connor O'Brien <connoro@google.com>
(cherry picked from commit baa126dc15)
This prevents two different kinds of client errors from causing
undetected memory corruption, and helps with the detection of others:
1. We no longer deallocate objects when the weak count goes to zero
and there have been no strong references. This otherwise causes
us to return a garbage object from a constructor if the constructor
allocates and deallocates a weak pointer to this. And we do know
that clients allocate such weak pointers in constructors and their
lifetime is hard to trace.
2. We abort if a RefBase object is explicitly destroyed while
the weak count is nonzero. Otherwise a subsequent decrement
would cause a write to potentially reallocated memory.
3. We check counter values returned by atomic decrements for
plausibility, and fail immediately if they are not plausible.
We unconditionally log any cases in which 1 changes behavior
from before. We abort in cases in which 2 changes behavior, since
those reflect clear bugs.
In case 1, a log message now indicates a possible leak. We have
not seen such a message in practice.
The third point introduces a small amount of overhead into the
reference count decrement path. But this should be negligible
compared to the actual decrement cost.
Add a test for promote/attemptIncStrong that tries to check for
both (1) above and concurrent operation of attemptIncStrong.
Add some additional warnings and explanations to the RefBase
documentation.
Bug: 30503444
Bug: 30292291
Bug: 30292538
Change-Id: Ida92b9a2e247f543a948a75d221fbc0038dea66c
Add basic interface documentation to RefBase.h.
Much, but not all, of this is cut-and-pasted from an email message
from Mathias Agopian. The rest is reconstructed from the code.
Delete some, now redundant, text from Refbase.cpp, and add a bit
more about the implementation strategy.
Some minor fixes to internal comments.
Bug: 30292291
Change-Id: I56518ae5553bc6de0cc2331778e7fcf2e6c4fd87
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
(cherry picked from commit c4966a363e)
Change-Id: Idfb0eb29b305678608586d25c2f372146569ad39
Bug: 29250543
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
Test: ran libutils_tests
Bug: 29250543
Change-Id: I6115e3357141ed245c63c6eb25fc0fd0a9a7a2bb
(cherry picked from commit c4966a363e)
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
(cherry picked from commit c4966a363e)
Change-Id: Idfb0eb29b305678608586d25c2f372146569ad39
Bug: 29250543
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
Test: ran libutils_tests
Bug: 29250543
Change-Id: I6115e3357141ed245c63c6eb25fc0fd0a9a7a2bb
(cherry picked from commit c4966a363e)
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
(cherry picked from commit c4966a363e)
Bug: 29250543
Change-Id: Ia2d6a550f5594280505fb0835c752e53898700ed
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
(cherry picked from commit c4966a363e)
(changed code for safetynet logging due to lack of sstream and string in klp)
Change-Id: If50d59a91a13fddbff9a8fff0d3eebe57c711e93
Bug: 29250543
We comment out the names of the parameters we're intentionally
not using.
(cherrypick of 44a0eb4d8cdf4ab881f5d5a1acc1155266a46f6a.)
Change-Id: I0a92d9200ca26cdc4700d2ff9e3ab33c102520d5
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
Test: ran libutils_tests
Bug: 29250543
Change-Id: I6115e3357141ed245c63c6eb25fc0fd0a9a7a2bb
Adds two new enums to enable querying the duration of the last
dequeue or queue operations to a Surface/ANativeWindow.
Bug: 29413700
Change-Id: Ifa16755911c4a3c013a7128dd4038d328109c32d
I'll come back and remove klog_init when I've removed other calls to it.
Change-Id: Iad7fd26d853b4ddc54e9abd44516b6f138cbbfcb
Test: booted N9, looked at "adb shell dmesg" output.
The android_color_mode_t defines the color modes supported
by a display. A display can support multiple different
color modes.
sRGB mode and AdobeRGB are deliberately placed at 7 and 8
so that they match mode ID's used on prior devices.
bug: http://b/27926012
Change-Id: I9ab41b56ec0b495c02539665da5be158ffddf843
The <hardware/qemu_pipe.h> header isn't related to any loadable
hardware module, this patch thus relocates it to <system/qemu_pipe.h>
which is a much more logical location.
Note the following changes:
- The pipe name must begin with the 'pipe:' prefix to avoid an
un-necessary snprintf() and buffer copy.
- Does not probe for the obsolete /dev/goldfish_pipe device, i.e.
only use /dev/qemu_pipe instead.
- Use QEMU_PIPE_DEBUG() instead of D() as the debugging macro.
+ Update ADB to use the newest <system/qemu_pipe.h>
+ Add qemu_pipe_frame_send() and qemu_pipe_frame_recv() utility
functions which replace the obsolete qemud_channel_send() and
qemud_channel_recv() from the defunct <hardware/qemud.h>
header.
BUG=25875346
Change-Id: Ic290a5b79d466c2af64b49bd9134643277c11bfd
If the underlying local map changes, it's possible for multiple
threads to try and modify the map data associated with the UnwindLocalMap
object. Add a lock when generating the local map to avoid this problem.
In addition, add a read lock whenever any caller gets the maps iterator.
Updated all iterator callers to make this lock.
Bug: 29387050
Change-Id: Ie34822c3d8fd3bdb3dd126aeeb399969c36508c1
clang doesn't do the frontend inlining/dead code elimination needed for
the fortified implementation to work. Therefore, turn it off.
Bug: http://b/28381737
Change-Id: Ie8dd970e3908b1daaa587ad2bd041e8f6e2089db
am: 6a29fe931d
* commit '6a29fe931d9fd3bf7f2aad3713dc70c080970763':
Add utility to prepare files in a similar way to directories
Change-Id: I288024d55e8cead1c902950938b03bfa8dcc3df3
Add comment that SharedBuffer is deprecated.
Both aref and SharedBuffer had memory ordering bugs. Aref has no
clients.
SharedBuffer had several bugs, which are fixed here:
mRefs was declared neither volatile, not atomic, allowing the
compiler to, for example, reuse a stale previously loaded value.
It used the default android_atomic release memory ordering, which
is insufficient for reference count decrements.
It used an ordinary memory read in onlyOwner() to check whether
an object is safe to deallocate, without any attempt to ensure
memory ordering.
Comments claimed that SharedBuffer was exactly 16 bytes, but
this was neither checked, nor correct on 64-bit platforms.
This turns mRef into a std::atomic and removes the android_atomic
dependency.
Bug: 28826227
Change-Id: I39fa0b4f70ac0471b14ad274806fc4e0c0802e78
(cherry picked from commit 3e4c076ef2)
Add comment that SharedBuffer is deprecated.
Both aref and SharedBuffer had memory ordering bugs. Aref has no
clients.
SharedBuffer had several bugs, which are fixed here:
mRefs was declared neither volatile, not atomic, allowing the
compiler to, for example, reuse a stale previously loaded value.
It used the default android_atomic release memory ordering, which
is insufficient for reference count decrements.
It used an ordinary memory read in onlyOwner() to check whether
an object is safe to deallocate, without any attempt to ensure
memory ordering.
Comments claimed that SharedBuffer was exactly 16 bytes, but
this was neither checked, nor correct on 64-bit platforms.
This turns mRef into a std::atomic and removes the android_atomic
dependency.
Bug: 28826227
Change-Id: I39fa0b4f70ac0471b14ad274806fc4e0c0802e78
Convert to use std::atomic directly.
Consistently use relaxed ordering for increments, release ordering
for decrements, and an added acquire fence when the count goes to
zero.
Fix what looks like another race in attemptIncStrong:
It seems entirely possible that the final adjustment for
INITIAL_STRONG_VALUE would see e.g. INITIAL_STRONG_VALUE + 1,
since we could be running in the middle of another initial
increment.
Attempt to somewhat document what this actually does, and
what's expected from the client. Hide the documentation in
the .cpp file for now.
Remove a confusing redundant test in decWeak. OBJECT_LIFETIME_STRONG
and OBJECT_LIFETIME_WEAK are the only options, in spite of some
of the original comments.
It's conceivable that either of these issues has resulted in
actual crashes, though I would guess the probability is small.
It's hard enough to reason about this code without the bugs.
Bug: 28705989
Change-Id: I4107a56c3fc0fdb7ee17fc8a8f0dd7fb128af9d8
(cherry picked from commit e263e6c633)
Convert to use std::atomic directly.
Consistently use relaxed ordering for increments, release ordering
for decrements, and an added acquire fence when the count goes to
zero.
Fix what looks like another race in attemptIncStrong:
It seems entirely possible that the final adjustment for
INITIAL_STRONG_VALUE would see e.g. INITIAL_STRONG_VALUE + 1,
since we could be running in the middle of another initial
increment.
Attempt to somewhat document what this actually does, and
what's expected from the client. Hide the documentation in
the .cpp file for now.
Remove a confusing redundant test in decWeak. OBJECT_LIFETIME_STRONG
and OBJECT_LIFETIME_WEAK are the only options, in spite of some
of the original comments.
It's conceivable that either of these issues has resulted in
actual crashes, though I would guess the probability is small.
It's hard enough to reason about this code without the bugs.
Bug: 28705989
Change-Id: I4107a56c3fc0fdb7ee17fc8a8f0dd7fb128af9d8
It's no longer specific to make_ext4fs, will be used for mksquashfs as
well.
BUG: 27467028
Change-Id: I41b8c2b168ada45c8378dee522391edfb8f6b9a6
Signed-off-by: Mohamad Ayyash <mkayyash@google.com>
BUG: 28704419
These are needed for aapt to find javadoc comments that contain
"@removed" in order to skip them when printing styleable docs.
Bug: 28663748
Change-Id: I8866d2167c41e11d6c2586da369560d5815fd13e
Not to be confused with <cutils/ashmem.h> or <linux/ashmem.h>, one or other
of which is what you should be using instead.
Change-Id: Ie158530591b28b94c2cda9e2686cae56b7aeb1a3
Most of the system/core/include/log/log.h file uses the C99 syntax of
variadic macros (that is, '...' in parameter list and __VA_ARGS__
in arguments). Except for andoid_printLog and android_printAssert
which still uses GCC custom extension syntax.
Switched the remaining macros to use C99 syntax. GCC extension syntax
makes my editor's code parser puke.
BUG: None
Change-Id: Ia6ebc0f2044b64182c425b179da0229c7046be4a
Disambiguate between base and android::base namespaces. This matters
when headers from libbase are indirectly included.
Bug: 27804373
Test: Compiles in that referenced situation.
Change-Id: Icb26595bb0013733aa8c03971c9f4a950c8b2ab1
It's no longer specific to make_ext4fs, will be used for mksquashfs as
well.
BUG: 27467028
Change-Id: I41b8c2b168ada45c8378dee522391edfb8f6b9a6
Signed-off-by: Mohamad Ayyash <mkayyash@google.com>
Adds android_hdr_t, which specifies different types of high dynamic
range encodings to be used throughout the system.
Bug: 25684127
Change-Id: Ic92bb5dc64494e643b828a8e24af8760e74e2360
am: a30a626
* commit 'a30a6263d632a7d2dedc4f09c6707ab20df3fb1a':
Mutex: Note that STL is generally prefered
Change-Id: I69eec173bf9679dc592987bd78cc8edcc81a1fbb
This class was designed prior to Android having usable C++11
support. With that support now in place, we prefer people to
start using the STL threading classes, unless the code needs
to build on Win32.
Change-Id: If1b4d9bdfcb1e65824909376f022842bab9653d6
HAVE_PTHREAD_COND_TIMEDWAIT_RELATIVE has never been defined for LP64,
so let's have everyone use the same code path.
Also fix the possible overflow.
Bug: http://b/26944282
Bug: http://b/27918161
Change-Id: I51fc0ebb1f6b860dc62d721f8ebfbcf724ce66e7
Adds android_color_transform_t, which specifies a range of color
transforms which may be applied to the whole display.
Bug: 22767098
Change-Id: Iaf03915c09ac0bdd18512b5f78c39da1705bda08
Treehugger Robot