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
Since tolower/toupper take and return integer arguments, ascii chars in
the extended range will be converted from positive int values to
negative char values. In order to silence an error here, which was added
recently with integer sanitization here, casting explicitly.
Fixes: 160831549
Test: w/ libutils_fuzz_string8
Change-Id: Iedcd6643f95f84ce662a80e38931d918a200f508
Most of the built-in functions return signed values but BitSet deals
only in unsigned values. We can safely cast these away though as they're
always indices, which can't be negative.
Bug: 160010896
Test: atest inputflinger_tests, atest libinput_tests
Change-Id: I6e0b33972fabcd41ad1c269ea0e2a07b13b33c12
Use the new "data_libs:" to specify test library dependency. This is
like "data:" and it treats compiled libraries as test data files.
The result is libutils_test_singleton{1,2} is picked up by libutils_test
and installed next to the test binary.
Mark the test libs libutils_test_singleton{1,2} as uninstallable. This
prevents installing libutils_test_singleton{1,2} directly and only
permits installing via "data_libs:".
```
$ m libutils_test
testcases
└── libutils_test
├── arm
│ ├── libutils_test
│ ├── libutils_test_singleton1.so
│ └── libutils_test_singleton2.so
├── arm64
│ ├── libutils_test
│ ├── libutils_test_singleton1.so
│ └── libutils_test_singleton2.so
└── libutils_test.config
```
Bug: 124838889
Test: atest libutils_test
Change-Id: I432135e128fc9eedb1b8c18a331957e271d8b0f0
Instead of aborting when FileMap::create detects an overflow, detect the
overflow directly and fail the call.
Bug: 156997193
Test: Ran unit tests, including new unit test that aborted before.
Change-Id: Ie49975b8949fd12bbde14346ec9bbb774ef88a51
Adds fuzzers for BitSet, FileMap, String8, String16, and Vector.
Test: Ran fuzzers on Android Pixel 3a. Aggregate coverage was 1.2% (this is far lower than true coverage due to shared libraries being counted)
Change-Id: I739216fe88afa51dc2f73b857da91116853382f0
Removed unneeded cflags, moved libbase to defaults
Test: Built Android.bp successfully
Signed-off-by: Dylan Katz <dylan.katz@leviathansecurity.com>
Change-Id: I739216fe88afa51dc2f73b857da91116853382f0
If the policy has been changed already, we do not need to change
it again.
Bug: 139521784
Test: functionality verified
Change-Id: I251db1d3f874896ba9be68df87209e7e514b80f9
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 152655956
Test: m
Change-Id: Ida890adfe6dfac79267fc0e18b63d2330266438c
The code was using an off64_t but calling mmap. This caused the code
to abort on 32 bit.
Add a unit test that would abort on the previous version.
Bug: 155662887
Test: New unit test passes.
Change-Id: I7a6efbc0d4227403c3d08a08deea56f239382157
const parameters can't be moved but only get copied -
removed const
Bug: 153704006
Test: builds & boots
Change-Id: If7e2250325bf1bc498afd3539f60bcb075a1d43b
The marked library(ies) were available to the APEXes via the hand-written
whitelist in build/soong/apex/apex.go. Trying to remove the whitelist
by adding apex_available property to the Android.bp of the libraries.
In this change, following libs were made available to all apexes because
their usage is quite common and there is no reason to restrict them
to some APEXes.
* libbase_headers
* libcutils, libcutils_headers
* libutils_headers, libsystem_headers
* liblog_headers
* libbacktrace, libbacktrace_headers
* libcrypto_utils
Bug: 150999716
Test: m
Change-Id: If3d3652e6604ed4f6d7694fe7ac61ae496621026
This is in preparation of doing what we did for SharedRefBase (hiding
operator new) so that clients can't accidentally construct
shared_ptr/unique_ptr or any other alternative memory management scheme
which would conflict with RefBase. You can see what ultimately happened
to SharedRefBase in frameworks/native CL
10d9ddf2e3da3ba3a425fb8396aaaec728e5fbdb.
The goal for this:
- promote use of 'sp<T>::make' over 'sp<T> .. = new T'
- make 'operator new' a private member of RefBase
Bug: 138956784
Test: libutils_test
Change-Id: I47f4d28edbf7534730c7b6fb1de748dd60f34e11
Before, this was printing the pointer to the char16_t* because of an
automatic conversion. However, this is almost never intended.
Bug: N/A
Test: dumpsys_test
Change-Id: Iaafcb2145cf93028cf3271813c56b8b74948f943
If a thread priority is greater than or equal to
ANDROID_PRIORITY_BACKGROUND, and the new priority is less than
ANDROID_PRIORITY_BACKGROUND, set the sched policy to its parent process.
Bug: 139521784
Test: functionality verified
Change-Id: Ie6fe33e08e4fda0a119b9869e8dd1733c164d79e
Perhaps the better question is, why have I 100s of times, typed
"ASSERT_NE(nullptr, foo)" for sp<> foo, and got a compiler error and
then change it to "foo.get()". This CL so we can stop wasting cycles
with that error.
Fixes: 147842528
Test: libutils_test
Change-Id: Id63b29d2a1ff3077201a62b69d864c5a826c47e0
For clarity, when printint w/o delination, noticed in b/145776393.
Test: view output of statusToString from a dumpsys change
Change-Id: I5ea9f052c223f167dd58923e2470c852907c97b8
For the raw pointer constructor, check that the argument is not on the
stack. Passing a stack pointer as an sp<> parameter is dangerous,
since we will attempt to deallocate the object once the sp<> is no
longer needed. We approximate ste stack ccheck by testing whether it
is on the same page as the frame pointer.
Do the same for raw pointer assignment.
Bug: 138956784
Test: Boot AOSP
Change-Id: I2c2405be443389af7e6a713aadcb3ee1f372a85e
For libbinder, not having these statuses printed out causes never ending
problems for developers.
Bug: 144534032
Test: libhidl_test tests this, which is on TH here
Change-Id: I02f37fb1e5b743131598ddc95ef89ebdfbdff615
Bug: 141890807
Test: boot, check data is zero'd
Change-Id: I45aaeac369f4c5cf3eb44f61c233e00f870a5c79
(cherry picked from commit bf824f8fa5)
(cherry picked from commit e62a9d7669)
Imagine an AIDL file:
package android.foo;
interface IFoo {}
The AIDL C++ backend will generate classes like "::android::foo::IFoo".
In order to avoid ODR conflict, the NDK (Stable C) backend linking
against libbinder_ndk puts everything under the "::aidl" namespace. So,
we have "::aidl::android::foo::IFoo". When using ScopedTrace in a class
implementing a class from this backend, there is this problem.
Bug: 141828236
Test: works
Change-Id: Iafadea11788d4c011229657b4f53063bcf65f8d8
This class isn't used very much and it isn't supported by AIDL. In order
to recommend new users against this and recommend an alternative, added
a comment here.
Bug: 142282873
Test: N/A
Change-Id: If7c6c9fac6c868ed6a515e658de752092d25d5f9
Newly allocated SharedBuffer already has reference count 1, so we
should not call acquire().
Bug: 141764153
Test: Run String16Test.* with ASan that was able to detect the leak
without this change.
Change-Id: Ib8b1b707b028386d717414d8c5ec5ea7b4b59464
libcutils has trace implemented for host. In order to increase code
portability, opening that up for libutils Trace.h usage as well.
Bug: 124524556
Test: use Trace.h on host glinux
Change-Id: Ia873f88e7436a18f6c0f761000bf697c68ffea17
The Android framework, notably android.view.Choreographer, assumes
that System.nanoTime and SystemClock.uptimeMills return consistent
values. This was true on device, but not on host.
This commit makes those values consistent on host linux. The necessary
support should be in place in kernels 2.6.39 and newer, which have been
available since 2012.
Test: m -j libutils
Change-Id: I833a89a810ae9fb3e8c01f6095ee2aca893c284f
Elliott Hughes