Test: build with BOARD_VNDK_VERSION := current
Merged-In: Iccc3a0301a28de52fc17102d251ce728d372ba5c
Change-Id: Iccc3a0301a28de52fc17102d251ce728d372ba5c
(cherry picked from commit 477e5978ac)
Provide configuration support to set sid on the subscriber side sync and
discovery beacons as part of NAN enable and config request.
(cherry-pick of commit b2c4b3825a5b1ef4713417538755b04225b2b53d)
Bug: 35195516
Test: integrated (sl4a) tests pass
Change-Id: I20548928a9ad81e8d3154eb5b982fd19add7659c
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
Bug: 37343006
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
Test: attempt to compile with BOARD_VNDK_VERSION := current
(cherry picked from commit 703e783e28)
Merged-In: I3f1e4986c5920b4a64768636cb0bc37fa602c7a7
Change-Id: I3f1e4986c5920b4a64768636cb0bc37fa602c7a7
Test: builds with BOARD_VNDK_VERSION := current
Test: (sanity) Boots and works on internal marlin.
Bug: 33241851
Bug: 29915755
Change-Id: Ic355174a67860afa13377bc9d8f0a140f59ec34e
(cherry picked from commit 4d4047b7e9)
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
Bug: 37343006
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
Test: attempt to compile with BOARD_VNDK_VERSION := current
Merged-In: I3f1e4986c5920b4a64768636cb0bc37fa602c7a7
Change-Id: I3f1e4986c5920b4a64768636cb0bc37fa602c7a7
Test: builds with BOARD_VNDK_VERSION := current
Test: (sanity) Boots and works on internal marlin.
Bug: 33241851
Bug: 29915755
Change-Id: Ic355174a67860afa13377bc9d8f0a140f59ec34e
This doesn't need utils/Log.h, only log/log.h (and liblog)
Bug: 33241851
Test: m -j libpower
Merged-In: I21b08203fad51902d4a0f6172b4321b8b701ec47
Change-Id: I21b08203fad51902d4a0f6172b4321b8b701ec47
