This creates a dependency edge between the ndk_library and its headers,
which should be a no-op in regular Soong builds. This dependency edge
will be used in the Multi-tree project to export the relevant .h files into a well
known location
Test: m nothing
Bug: 239044713
Change-Id: I374b1529456c4c71ac419b4684f2fd215c68e791
Currently, for an API symbol to be accessible to APEXes, it needs to be
marked as either # systemapi or # apex. It was originally just # apex,
but we added # systemapi to clearly identify the origin of the APIs.
The intended use is
* #apex is for APEX-visible symbols that are defined in an APEX
* #systemapi is for APEX-visible symbols that are defined in the
platform (the non-updatable part)
This intention is documented build/soong/docs/map_files.md, but isn't
enforced at all.
With b/239274367, this is now enforced and therefore the #apex tags in
the platform library are replaced with `#systemapi`
This change does not alter any functionality.
Bug: 239274367
Test: m
Change-Id: Ibdb9122c9969749e055404078bc2280edaa7346d
Remove the vestigial llndk_library modules and replace them with
properties in the llndk clause of the implementation cc_library.
Bug: 170784825
Test: m checkbuild
Test: compare out/soong/build.ninja
Change-Id: Ie3a1bffcf29bb1b6747f7f708826c61bd43ba5a1
__ANDROID_API__ guards are removed in favor of __INTRODUCED_IN macros.
Currently, __INTRODUCED_IN macro does nothing for these headers (it's
meaningful only to the headers processed by versioner which are limited
to binic headers). The plan is to make the macros to tag the declaration
with the availability attribute. Then, when the min_sdk_version of a
caller is set to an API level that is older than the API level of the
APIs, the compiler will provide them as weak symbols and enforce that
calling the APIs are guarded with a runtime check.
For now, these guards are preventing from making a build system change
to let __ANDROID_API__ track the min_sdk_version property instead of the
sdk_version property. With the build system change, __ANDROID_API__ will
suddenly drop for the native modules where min_sdk_version <
sdk_version, which is the case when the modules are included in APEXes.
As a result, some new APIs will be unavailable at build-time. Dropping
the hand-written guards fixes the problem.
Bug: 163288375
Test: m
Change-Id: If1cc6b9af410f536abe6d777c22711209fa76530
Instead of assuming a module with the .llndk suffix exists, add an
llndk_stubs property to every cc_library module that has a
corresponding llndk_library. Also rename the llndk_library to have
an explicit .llndk suffix.
Bug: 170784825
Test: no changes to build.ninja (excluding comments) or Android-${TARGET_PRODUCT}.mk
Change-Id: Ifba79a1ae64a67a9d7393dac2fb012cd8af8e149
libsync is an NDK/LLNDK library but it's missing "stubs" key. So, when
it is referenced by an APEX, it is bundled in APEX package.
By adding "stubs" property, we can make it a stubs library and APEXes
use it from the system instead of bundling it.
Note that the symbol(sync_wait) is exposed to APEX because it is used
by libui which is used by media APEXes again.
Bug: 158270824
Test: lunch mini_armv7a_neon # no VNDK
m com.andorid.media.swcodec
// see if libsync is not in the APEX
Change-Id: I39e682328acb5cc363a4242601e5bf1470938dac
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: Iae2acdf1ff4097a64a5c6280797c66abb1d5a5e6
(cherry picked from commit 0e957b82c8)
Change-Id: Iae2acdf1ff4097a64a5c6280797c66abb1d5a5e6
Android build system added support for building translated binaries
used on natively bridged targets (arm on x86 for example).
However in order to avoid building unnecessary binaries and libraries
for such architectures most modules do not support native bridge by default.
All needed modules have to explicitly indicate if they may be used as part
of translated binary build.
This change enabled native bridge support for libsync because it is a
public library.
Bug: http://b/77159578
Test: make
Change-Id: I993384469fa2b011a15a2ecb1fd2162184c74a47
Statically linking against libsync is no longer a concern, since libsync
has supported the modern sync ABI (which is frozen upstream) after the
recent cleanup works.
Test: `m dist` with aosp_taimen-userdebug
Change-Id: Ic162bc7ff7c9dd306658d11d4b71e2d18730a2ee
The legacy fence/pt info API has been deprecated for a while. This
change removes it from headers, so remaining users will have to switch
to the modern API when they're re-compiled. The functions are still
provided by libsync.so and tests remain, so existing binaries should
continue to work. Eventually these will be removed too, though, once
it's reasonable to expect those binaries to have been recompiled.
This reverts commit eed25df46a, which
reverted the previous attempt in commit
798ba95bda now that more users of the
legacy API have been converted.
Bug: 35326015
Test: make checkbuild
Test: adb shell dumpsys SurfaceFlinger --latency
The legacy fence/pt info API has been deprecated for a while. This
change removes it from headers, so remaining users will have to switch
to the modern API when they're re-compiled. The functions are still
provided by libsync.so and tests remain, so existing binaries should
continue to work. Eventually these will be removed too, though, once
it's reasonable to expect those binaries to have been recompiled.
Bug: 35326015
Test: make checkbuild
Test: adb shell dumpsys SurfaceFlinger --latency
Change-Id: Id086fafe37c2bc1cfdca4a21107bc9208ed61f89
Tests in this file depends on long out-of-date behavior of the sync
api. More current tests are in tests/sync_test.cpp.
Test: quis custodiet ipsos custodes?
Change-Id: Ia0a0970dde17c1ae4e1d79fac1a9fe3b54e8fcd6
This patch adds regression tests to check that the fence info returned
by libsync contains valid data.
Test: sync-unit-tests
Change-Id: I0c57c49b7be563efc9a43f12381059f20e0a4e52
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Fixes a bug with the signal time of devices using the
modern sync file interface. The bug only affects kernels running
an Android kernel 4.9 and later.
b/63395253
Test: tests/sync_test.cpp
Change-Id: I6fb00bcb8e16a3268c357153edd8e35a44546caa
libsync is used both by platform (e.g. libui.so) and by same-process
HALs (e.g. android.hardware.graphics.mapper@2.0-impl.so). Therefore it
is eligible for either VNDK-SP or LL-NDK. Among the two choices, LL-NDK
was selected because it is already an NDK and is just a thin wrapper
around a few kernel ioctls.
However, since libui (which is a vendor_available:true library) is using
more symbols that are not available to NDK clients, the extra symbols
are exposed as # vndk tag so that they are only available to VNDK
clients, but not to NDK clients.
Bug: 63866913
Test: BOARD_VNDK_VERSION=current m -j successful (2017 pixel)
Test: the built image is bootable
Merged-In: I60f883c049bd9b4562e6ce34d34ead47ba28af5f
Change-Id: I60f883c049bd9b4562e6ce34d34ead47ba28af5f
(cherry picked from commit 058e0919f6)
The header names were changed during review, but the library map file
wasn't updated.
Bug: 62229958
Test: CtsGraphicsTestCases:android.graphics.cts.SyncTest
Merged-In: Ie5955865667b35067f1ee209933f159f170419cd
Change-Id: Ie5955865667b35067f1ee209933f159f170419cd
(cherry picked from commit 59d9ee5d02)
sync_file_info, the only caller of legacy_fence_info_to_sync_file_info,
unconditionally frees legacy_info after
legacy_fence_info_to_sync_file_info is called. So, if this calloc
fails, we'll end up freeing legacy_info twice.
Bug: 27101951
Test: mma. Static analyzer complaint about double-free is gone.
Change-Id: I43bf820af9aadf30cb8eabce57416f69a8fccf89
clang is the default compiler since Android nougat
Test: mma & verified it´s still build with clang
Change-Id: I34adaeef2f6558a09f26027271222bad94780507
Signed-off-by: Lennart Wieboldt <lennart.1997@gmx.de>
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: 33241851
Test: build and flash internal marlin
Test: m -j libsync
Test: build with BOARD_VNDK_VERSION := current
(cherry picked from commit d0b26edf30)
Merged-In: I5b23d2c1f41b842e5a9b7ea257921133b80c3f98
Change-Id: I5b23d2c1f41b842e5a9b7ea257921133b80c3f98
Use of 'inline' without 'static' may allow the C compiler to uninline it
within the compilation unit, depending on the C standard level. Always
using 'static inline' avoids this problem.
Test: build + boot to launcher
Change-Id: Ifb6e1fa6b84286067ddc2daca4c8942c410e56ab
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: 33241851
Test: build and flash internal marlin
Test: m -j libsync
Test: build with BOARD_VNDK_VERSION := current
Change-Id: I5b23d2c1f41b842e5a9b7ea257921133b80c3f98
Soong handles these automatically now.
Bug: 33241851
Test: Android-aosp_arm.mk is the same before/after
Test: build.ninja is the same before/after
Test: build-aosp_arm.ninja is the same before/after
Change-Id: Ia039812817495c00e450eec7292447d5e8f93adb
Previously all libsync calls would try first the modern/mainline uapi
and if that failed try the legacy uapi, or vice versa. This is
inefficient, and confusing when looking at strace. With this change,
after the first successful syscall, libsync know's what uapi version
the kernel supports, and will only try that version in the future.
Test: sync-unit-tests on bullhead
Change-Id: I8b5de0194da0cfc6c080c0180318e16bb673d3c9
Leave a temporary symlink from the old name to avoid having to change
all dependencies simultaneously.
Bug: 1901466
Test: m
Change-Id: Id210f0091457e52e1a6e048d241a723bdbe8779b
Also modifies sync-unit-test to use sync_file_info instead of the
deprecated sync_fence_info, but check that they match in several tests.
Bug: 35138793
Test: sync-unit-tests on bullhead
Change-Id: Ic672d1c89798435a8b71469500e82c770a66bf4d
Split the sync_fence_info implementation into multiple functions. This
clarifies the logic, and allows the parts to be reused in the upcoming
sync_file_info function.
Test: sync-unit-tests on bullhead
Change-Id: I0ea37067dddf41b831670f08eb99e0b7fd52adce
The new header provides an updated interface to libsync appropriate
for the NDK. Clients use existing syscalls where possible (e.g. poll()
instead of sync_wait()), and the remaining functions return structures
used in mainline Linux kernels rather than the Android staging sync
framework.
Over time, framework clients will be migrated to using the NDK
interface, which will eventually replace the current internal
interface. The only difference is the header will be named
<android/sync.h> in the NDK and <sync/sync.h> internally.
Bug: 35138793
Test: sync-unit-tests on bullhead
Change-Id: Ieb3649b80565393e26b604416158438d32c2a256
The previous and current types are the same size, so this wouldn't
have caused a bug in practice, but it is confusing, and would have
been a problem in the unlikely event we changed the size of one of the
types.
Test: sync-unit-tests on bullhead
Change-Id: Ic43b81f3b4ff214af86b6b6d4d02c648f95d0c4b
Inserting tuple into unordered_map relies on non standard libc++ extension:
http://stackoverflow.com/a/21313229
This change removes this dependency.
Test: sync-unit-tests (on hikey with SW_SYNC_USER built into kernel)
On mainline if the sw_sync timeline is destroyed the fences doesn't not
signal or error. So change the test to check if the fence is still there
by polling the fence with timeout zero and asserting if it is not
signalled.
Test: Sync unit tests still passes.
Change-Id: Icb8e629018eef35074ae91d0f29ed1f12e90492b
The mainline Sync File implementation doesn't have wait ioctl anymore.
Only poll is supported now, and we already have a test for that.
Test: Sync unit tests still passes.
Change-Id: Iadde7b2173024af9b8d20316e640297cf214c645
Change libsync functions in a way that it can run dynamically on both
APIs.
v2: fix whitespace changes and poll return handling
v3: handle error cases on sync_wait()
Test: Sync unit tests still passes.
Change-Id: I743ab92ce39cbfa75dca41dd0a435efa9f2aab66
hange-Id: Ib56f2c6441b41028bc9f66998676790b7713988a
sw_sync file for debug was moved to debugfs. Try to open it and if it
fails try to open /dev/sw_sync.
Test: Sync unit tests still passes.
Change-Id: Ie078fbc2eb5294f28b916a9e65b7fcd3a18a8580
hange-Id: I216874964368d939bed2779d98cd89e527a57d45
