Make it easier to see reference to usage documentation, as requested in
review.
Bug: 184190315
Test: libutils_test
Change-Id: If9056e35b1c7a779dd78f2b986ad10d02f25eaf3
This API was tested before, but it wasn't used until it is needed in
libbinder. Previously it passed the tests because wp::operator==
compares weak_ptrs which are never deleted, but it doesn't check the
value of m_ptr as well. This assumes that the RefBase implementation is
self-consistent.
Future considerations:
- add additional CHECK (perf?)
- add an additional optional CHECK?
- update all refbase tests to use an embellished form of this operator
Bug: 184190315
Test: libutils_test, boot and kill process when libbinder is using this
API
Change-Id: I66c97386d769529d5efae48e06775d4b4a344025
If you need to do a case transformation for a Unicode string, you need
to use icu4c. This only worked for ASCII, which is just silly. Luckily
it doesn't seem to be used anywhere.
Test: treehugger
Change-Id: I4a864823ec35a0b57b50909587cc3efac3f531a7
Merged-In: I4a864823ec35a0b57b50909587cc3efac3f531a7
Previously, sp::sp(T*) internally had a static cast, and people
frequently wrote code like this:
sp<A> a = ...;
sp<B> b(a.get()); // implicit static cast
Luckily, none of the other sp constructors have this implicit cast. So,
for explicit code, rather than making those use static_cast internally,
adding an sp::cast function.
Bug: 184190315
Test: use in libbinder
Change-Id: Id205c88d03e16cf85ccb8f493ce88b4bbc65a688
In form, inspired by ANDROID_BASE_UNIQUE_FD_DISABLE_IMPLICIT_CONVERSION.
We get occasional bugs about sp double-ownership. When this flag is
enabled, we have:
- you must construct RefBase objects using sp<>::make
- you must construct wp<> objects by converting them to sp<>
- if you want to convert a raw pointer to an sp<> object (this is
possible since the refcount is used internally, and is used commonly
on this*), then you must use 'assertStrongRefExists' semantics which
aborts if there is no strong ref held. That is, if a client uses
std::make_shared and then calls a function which internally used to
call `sp<T>(this)`, you would now call
`sp<T>::assertStrongRefExists(this)`, and the double ownership
problem would become a runtime error.
Bug: 184190315
Test: libutils_test
Change-Id: Ie18d3146420df1808e3733027070ec234dda4e9d
vendor_available modules were available to product modules.
However, not all vendor_available modules are required to be
available to product modules. Some modules want to be available only
to product modules but not vendor modules.
To cover the requirement, we separate product_available from
vendor_available.
vendor_available will not provide product available module.
Rename libcutils/include_vndk to libcutils/include_outside_system as
it provides the headers to the modules outside the system partition
including /product.
Bug: 150902910
Test: build
Change-Id: I791b5a6a1dc99442065debfce6fa0f54a335fcea
Restrucures this fuzzer to be far more robust and less brittle.
Fix: 163727995
Fix: 163449137
Test: libutils_fuzz_refbase clusterfuzz-testcase-minimized-libutils_fuzz_refbase-5674315436261376
Test: libutils_fuzz_refbase clusterfuzz-testcase-minimized-libutils_fuzz_refbase-5731662044069888
Test: libutils_fuzz_refbase clusterfuzz-testcase-minimized-libutils_fuzz_refbase-5081777218256896
Signed-off-by: Dylan Katz <dylan.katz@leviathansecurity.com>
Change-Id: I239298dc2895a06af5a126e9ca2ae452579e5cc0
* changes:
libprocessgroup_headers: make vendor_ramdisk_available.
libdebuggerd_handler_fallback: make vendor_ramdisk_available.
libcutils: make vendor_ramdisk_available.
libpropertyinfoparser: make vendor_ramdisk_available.
This requires a few other changes to support building libutils
properly. It does appear the windows versions of libutils is
referencing CallStack code, but it doesn't seem to cause any problems.
However, I removed those references completely for the windows build.
Also removed a few extra spaces that seem to have accumulated in the
RefBase.cpp.
Bug: 170465278
Test: Builds and libutils unit tests pass.
Change-Id: Ibeee7791b13636b34bdd592c5420fd91620f752a
Allocating the entire address space is sufficiently unreasonable that
hwasan blows you out of the water if you try to do that. Half the
address space feels like it's large enough to be guaranteed to fail
(which is all I think this intended to test) without being quite so
obviously incorrect that tools like hwasan are going to object...
...except hwasan actually has a 2GiB limit. So let's keep the cleanup,
but also just disable these tests if they're running under hwasan for
now.
Bug: https://issuetracker.google.com/171054277
Test: treehugger
Change-Id: I41f3def5c3a43aa7f9ca3a130b4306ebed659d6a
Missed a review point made, added the license header to FuzzFormatTypes
Test: Compiled code
Signed-off-by: Dylan Katz <dylan.katz@leviathansecurity.com>
Change-Id: Ib8f32b802ec207d0483772c38a0a741e0dd1f151
The class being fuzzed here was too simple for a fuzzer to be effective at finding crashes that were not working as intended.
To resolve the issue noted in 163775285 would require the fuzzer to simply use RWLock exactly as intended, defeating the point of fuzzing it.
Because of this, we have made the decision to remove this class. It should have a fairly small impact on coverage. In the future,
perhaps a better approach would be fuzzing pthread's rwlock methods directly.
Test: Made sure the project still builds without RWLock_fuzz.
Signed-off-by: Dylan Katz <dylan.katz@leviathansecurity.com>
Change-Id: Id5e77d053dc800a982176802dc506d26b54d810f
The input code is the only customer of PropertyMap. For easier
maintenance and eventual removal of it, move it to libinput.
Currently, the caller is responsible for managing the lifecycle of the
returned outMap when calling PropertyMap::load. However, the fact that
the function call allocates new memory is not obvious from the function
signature.
In a separate commit, I will refactor the function to return
Result<unique_ptr<>> to make it less errorprone.
In this commit, only move the files around to make code reviews easier.
Bug: 163171599
Test: atest inputflinger_tests
Change-Id: I316084886c3f09a1776fdb449d2f03d0563b66c1
In https://android-review.googlesource.com/c/platform/system/core/+/1224544
when we introduced a default argument to androidSetThreadPriority(),
we broke C compatibility with this API, and with the header file
in general.
We fix this up by instead introducing a new method that takes
three arguments. This gets this header file compiling for C again,
and keeps this particular API C compatible.
Any C++ callers of the three argument version of
androidSetThreadPriority() will need to switch to using
androidSetThreadPriorityAndPolicy(). Although since this was
a recent change, we believe there is only one such user, which
we are fixing at the same time.
Test: TreeHugger
Bug: 165009705
Merged-In: Iab0b7e6c91a8e32a17ba1b186fd0c2fe96b601e4
Change-Id: Iab0b7e6c91a8e32a17ba1b186fd0c2fe96b601e4
I stumbled across this because of the `#ifdef __cplusplus` inside an
unguarded `namespace`, but this whole file should be deprecated and
removed in favor of static_assert.
Test: treehugger
Change-Id: I2b65db67e694115e915f0cc9d762b0fd41a7d2af
For encoding errors, this function will return a negative value which
causes problems down the line. Check for an error and return. Also,
integer overflows are guarded.
Bug: 161894517
Test: fuzzer test case
Change-Id: Ia85067d4258bde4b875c832d6223db5dd26b8838
Merged-In: Ia85067d4258bde4b875c832d6223db5dd26b8838
(cherry picked from commit ee22384c54)
std::bitset<> doesn't have exact replacements for all of the
functionality of BitSet32/64, so there are still places we want to use
these classes.
Bug: 160010896
Test: test BitSet_test.cpp
Change-Id: Ica59a138e014d82139fb6dcea0597a207faecc2a
