These includes are included transitively by liblog, but not by the VNDK
version of liblog.
Bug: 33241851
Test: links with BOARD_VNDK_VERSION := current
Change-Id: Ide4aee3cacad2a2bf6bd0cbdf0254c6c245f4020
This is used in CallStack.h.
Test: m -j libutils
Test: links
Test: trying to compile with BOARD_VNDK_VERSION := current
Bug: 33241851
Change-Id: If7258e7b38000a72fd520f725030fb0038f90167
vendor + vendor_available modules built with BOARD_VNDK_VERSION :=
current aren't allowed to use global headers. Since libutils uses
system headers itself, it should export them as well.
Also added some items into windows-deprecated.h. This file is supposed
to be in sync with the libnativewindow variant until all dependencies on
it can be fixed. However, it is missing some updates. This matters when
including libsystem_headers adds system headers before libnativewindow
headers in the lookup paths.
Bug: 33241851
Test: building with BOARD_VNDK_VERSION := current produces many fewer
errors.
Change-Id: I950821f1dae3ddc110db50869247913d5b1aa638
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 36426473
Bug: 36079834
Test: m -j libutils
Test: attempt to compile with BOARD_VNDK_VERSION := current
Merged-In: I6c1279a74ef071851401e38bbdd377f13827694c
Change-Id: I6c1279a74ef071851401e38bbdd377f13827694c
A mixture of fixes and cleanup for LogKlog.cpp and friends.
- sscanf calls strlen. Check if the string is missing a nul
terminator, if it is, do not call sscanf.
- replace NULL with nullptr for stronger typechecking.
- pass by reference for simpler code.
- Use ssize_t where possible to check for negative values.
- fix FastCmp to add some validity checking since ASAN reports that
callers are not making sure pre-conditions are met.
- add fasticmp templates for completeness.
- if the buffer is too small to contain a meaningful time, do not
call down to log_time::strptime() because it does not limit its
accesses to the buffer boundaries, instead stopping at a
terminating nul or invalid match.
- move strnstr to LogUtils.h, drop size checking of needle and
clearly report the list of needles used with android::strnstr
- replace 'sizeof(static const char[]) - 1' with strlen.
Test: gTest liblog-unit-test, logd-unit-tests & logcat-unit-tests
Bug: 30792935
Bug: 36536248
Bug: 35468874
Bug: 34949125
Bug: 34606909
Bug: 36075298
Bug: 36608728
Change-Id: I161bf03ba029050e809b31cceef03f729d318866
This CL blacklists some vector functions (construct, copy, splat,
move) that use reinterpret_cast on freshly allocated memory (where the
object doesn't exist yet). This is technically correct, but not
friendly for CFI, which enforces stricter checking to catch type
confusion errors. Blacklisting these specific functions from CFI does
not cause an appreciable coverage loss though, so this should be fine.
Bug: 36219323
Test: Builds and boots, and the reinterpret error goes away on CFI builds.
Test: All 98 libutils_tests pass
Change-Id: I4944b179116bb1e1608d92697e95e182d8c0ac9f
Force assignment to read the old pointer value twice, and check
that it didn't change in the interim. Previous experience with
Skia suggests that this has a high probability of correctly detecting
a data race when it occurs, instead of potentially letting the
count associated with the old pointer value get decremented twice,
and corrupting the heap.
This does increase the size of sp assignments, which seem to
commonly get inlined. For the general case, we add a third
comparison and function call.
Some code reformatting to make this consistent with modern conventions
and pass automated checks.
Test: Booted aosp build. Ran libutils tests. Looked at generated code.
Bug: 31227650
Change-Id: Id93a05c6bf10f01ee15ff1bb409611f2058f988f
This CL nukes all spurious whitespace in the two files.
Bug: 36219323
Test: Device builds and boots.
Test: All 98 libutils_tests pass
Change-Id: I8054a0f0ba5df95f5115dc06597eb9fd539da942
It had 3 clients
- one in vendor/google_athome which was disabled
- one in a device specific folder, which will die out
- and one in frameworks/base
This reverts commit 6c942304ed.
Test: compile/run
Bug: treble cleanup
Change-Id: Ia76009d550c294198c083cf89718bc498b5c9e3e
This method is still used by prebuilts, but making it private to start
the process of removing it from everywhere.
Test: pass
Bug: 35363681
Change-Id: I4d53f68d10c9abcca32023c4d930e99912afa697
Includes are transitively imported by <string> in String8.h + String16.h
but that include is being removed.
Test: pass
Change-Id: Ide5c011b40b4a4f031dd26ead08b5c8d5d299693
moved Foo.h as first include of Foo.cpp, and
removed redundant includes.
Made NativeHandle non virtual.
Test: run & compile
Bug: n/a
Change-Id: I37fa746cd42c9ba23aba181f84cb6c619386406a
Also, remove the clarification that Condition::signal() wakes exactly
one thread as in the presence of spurious wake ups, this clarification
does not provide a safe guarantee to developers.
Bug: 34592766
Test: Build
Change-Id: I34df02e44a70a18fe04ceda858d002ef129c1fd9
Test accessing a singleton from two libraries, the second of which
depends on the first but is dlopen'd after the first is already
loaded.
Bug: 35674422
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
Change-Id: I975ba933a19b941a52bdb6e9c221a6910ffb8081
Reapply of Icd5f39ae71b57167e9b2fe7ec09c5400bcb90e78 with
RefBase_test.cpp and Looper_test.cpp removed from mac builds.
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
Test: out/host/darwin-x86/nativetest64/libutils_tests/libutils_tests
Change-Id: I5979b296a8500b5697d94d64fc441363047adcea
StrongPointer_test.cpp's Foo was colliding with RefBase_test.cpp's
Foo.
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
from later CL
Change-Id: I2a4e956c88a07cec72d7ce734cf06c58134a4235
I385a05a3ca01258e44fe3b37ef77e4aaff547b26 broke Singleton in the
same way that 544e3e3606 had already
fixed once. Fix it again, the next CL will add tests.
This affected cases where two libraries referenced the same singleton,
the one that was supposed to define the singleton was already loaded,
and then the second library was dlopen'd.
Bug: 35674422
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
from later CL
Change-Id: I87c64f95ed294a887e67a6c11be3072299789f01
Changes to the REALTIME clock can cause Condition::waitRelative() to
timeout early or delayed. This behavior is undesired and new since
https://android-review.googlesource.com/#/c/181058/ moved the
underlying pthread_cond_timedwait() implementation to use absolute
timeouts rather than relative ones. Having Condition use
CLOCK_MONOTONIC prevents these timeout issues.
Bug: 34592766
Bug: 35678943
Test: Boot bullhead
Test: Ensure time changes do not cause Condition::waitRelative() to
timeout early or delayed
Change-Id: I3a8d7a48f9b42fe990c3c7331313b6d85aa546f9
TreeHugger Robot