The APIs that are tagged with # vndk are actually for LLNDK libraries.
Although LLNDK is part of VNDK, calling those APIs 'vndk' has given
users a wrong perception that the APIs don't need to be kept stable
because that's the norm for most of the VNDK libraries that are not
LLNDK.
In order to eliminate the misunderstanding, rename the tag to 'llndk' so
that people introducing new such API will realize what they are signing
themselves up for.
Bug: 143765505
Test: m
Merged-In: I56e49876410bd43723a80d0204a9aef21d20fca9
(cherry picked from commit 3e2cd44aa4)
Change-Id: I56e49876410bd43723a80d0204a9aef21d20fca9
This library was previously being statically linked into both libraries as a
consequence of the relocation to __aeabi_unwind_cpp_prX present in most object
files. However, after LLVM commit 1549b469, we no longer emit these relocations
on Android, so we need to link the library explicitly with --whole-archive. The
intent is to eventually stop linking libgcc into these libraries altogether,
but for now, we need to keep linking them in order to avoid breaking the build.
Change-Id: I275109527b7cbd6c4247b3fe348975d720626273
Right now, when we read a system property, we first (assuming we've
already looked up the property's prop_info) read the property's serial
number; if we find that the low bit (the dirty bit) in the serial
number is set, we futex-wait for that serial number to become
non-dirty. By doing so, we spare readers from seeing partially-updated
property values if they race with the property service's non-atomic
memcpy to the property value slot. (The futex-wait here isn't
essential to the algorithm: spinning while dirty would suffice,
although it'd be somewhat less efficient.)
The problem with this approach is that readers can wait on the
property service process, potentially causing delays due to scheduling
variance. Property reads are not guaranteed to complete in finite time
right now.
This change makes property reads wait-free and ensures that they
complete in finite time in all cases. In the new approach, we prevent
value tearing by backing up each property we're about to modify and
directing readers to the backup copy if they try to read a property
with the dirty bit set.
(The wait freedom is limited to the case of readers racing against
*one* property update. A writer can still delay readers by rapidly
updating a property --- but after this change, readers can't hang due
to PID 1 scheduling delays.)
I considered adding explicit atomic access to short property values,
but between binary compatibility with the existing property database
and the need to carefully handle transitions of property values
between "short" (compatible with atomics) and "long" (incompatible
with atomics) length domains, I figured the complexity wasn't worth it
and that making property reads wait-free would be adequate.
Test: boots
Bug: 143561649
Change-Id: Ifd3108aedba5a4b157b66af6ca0a4ed084bd5982
aosp/144287300 set it to a global cppflag.
The compiler upgrade can now check for this warning in C code.
This patch should be reverted once the BSD sources with instances of
-Wimplicit-fallthrough have been fixed.
Remove it from cflags, so that it's not re-enabled for C code until
fixed.
Bug: 139945549
Bug: 144287300
Test: mm
Change-Id: Ieca0d5b41634636477392e5209a41807f9b44bd4
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
libc++ poisons `__out` because it's #defined on Windows. Rather than
hack libc++, let's just avoid that name. "src" and "dst" are far more
widely used than "in" and "out" for this purpose anyway.
Test: treehugger
Change-Id: I0db9997fd5f06f626dbf0ee967b52145395466b4
I have no idea why I used the iterate name internally which is
completely unlike every other function name. Change this to match
everyone else so that it's now malloc_iterate everywhere.
This is probably the last chance to change this before mainline
modules begin, so make everything consistent.
Test: Compiles, unit tests passes.
Change-Id: I56d293377fa0fe1a3dc3dd85d6432f877cc2003c
This reverts commit d7e11b8853.
Reason for revert: Droidcop-triggered revert due to breakage android-build.googleplex.com/builds/submitted/5992686/aosp_x86_64-eng/latest/view/logs/build_error.log, bug b/144081298
Change-Id: Ic6a492c4fcf2ea1bb324c44fb615a898bbc9a9b7
This reverts commit d7e11b8853.
Reason for revert: Breaks aosp_x86_64-eng. Will look into it and
unbreak when it's not almost midnight. :)
Change-Id: I21f76efe4d19c70d0b14630e441376d359a45b49
