Move existing fast<str*cmp> templates for general use, pulled from
the implementation used in logd that dealt with speed through cache
locality and subroutine call mitigation. Rename to fastcmp.
Test: logd-benchmarks and based on manual profiling from the past
Bug: 31456426
Change-Id: Ic62f4a437fc3e06ffdeaae73a6f34e197957a6b0
Point to log/log.h where necessary, define LOG_TAG where necessary.
Accept that private/android_logger.h is suitable replacement for
log/logger.h and android/log.h.
Correct liblog/README
Effectively a cleanup and controlled select revert of
'system/core: drop or replace log/logger.h' and
'system/core: Replace log/log.h with android/log.h'.
Test: compile
Bug: 30465923
Change-Id: Ic2ad157bad6f5efe2c6af293a73bb753300b17a2
Should use android/log.h instead of cutils/log.h as a good example
to all others. Adjust header order to comply with Android Coding
standards.
Test: Compile
Bug: 26552300
Bug: 31289077
Change-Id: I2c9cbbbd64d8dccf2d44356361d9742e4a9b9031
The warnings in these files were hidden by -isystem
framework/native/include.
Bug: 31752268
Test: m -j
Change-Id: I2a54376aea380ee24e6483fb7d35fdfe8991c490
FlattenableUtils read() and write() currently use assignment to copy
bytes. However, by casting the void* buffer to type T, the compiler is
allowed to assume that buffer obeys the alignment requirements of T,
which is not necessarily the case during serialization. On some
architectures, we can get SIGBUS when this alignment is violated.
We don't want the users of these routines to have to worry about
alignment when packing structures, so use memcpy() instead which should
always be safe since the compiler won't assume any alignment for the
void* buffer.
On architectures that can handle unaligned direct read/write of type T,
the compiler should be smart enough to optimize this code back to a
direct read/write anyway, but architectures that can't handle it will
fall back to memcpy; this means that this change shouldn't have any
impact on current Android devices. See the linked bug for more details.
Bug: http://b/31671510
Test: libgui Sensor serialization no longer gives SIGBUS.
Test: libgui.so unchanged on Shamu before and after this CL.
Change-Id: I2197127e8cbfb43f4f553bda6464f6ebe087febd
system/core/include is included in the global include path using
-isystem, which hides all warnings. Fix warnings in libutils
headers in preparation for moving from -isystem to -I.
- Fix implicit cast from int64_t to long in Condition.h. Remove
the __LP64__ check and always compare against LONG_MAX before
casting.
- Fix implicit cast from size_t to ssize_t in KeyedVector.h
- Fix -Wshadow-field-in-constructor warnings in Looper.h and RefBase.h
- Move destructors for MessageHandler and LooperCallback to Looper.cpp
and ReferenceRenamer and VirtualLightRefBase to RefBase.cpp to prevent
vtables in every compilation unit.
- Declare template variables in Singleton.h
- Fix old-style casts in StrongPointer.h and TypeHelpers.h
- Use template metaprogramming in TypeHelpers.h to avoid warnings on
memmove on non-trivial types.
- Add an assignment operator to key_value_pair_t to complete
rule-of-three
- Use memcpy instead of dereferencing a reinterpret_casted pointer to
treat the bits of a float or double as int32_t or int64_t
- Escape unicode sequences inside doxygen comments between \code and
\endcode
- Remove WIN32 ZD definition in Compat.h, %zd works fine with mingw
- Fix WIN32 printf warnings in Filemap.cpp
- Initialize mNullValue with 0 in LruCache.h, some of the tests use a
non-pointer type for TValue.
Test: m -j native
Bug: 31492149
Change-Id: I385a05a3ca01258e44fe3b37ef77e4aaff547b26
Vector<T> objects are a dynamic type with a vtable, which is not
trivially moveable.
Impact on aapt for frameworks-res is negligible, ~3%.
Bug: 31595853
Test: m -j framework-res
Change-Id: I8a3269c35d95affb6e86d60588bcfca46db7f445
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
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.
Test: ran libutils_tests
Bug: 29250543
Change-Id: I6115e3357141ed245c63c6eb25fc0fd0a9a7a2bb
(cherry picked from commit c4966a363e)
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
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
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
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
