platform_external_modp_b64, branch pie-r2-release

Mark as vendor_available am: 84a0dad630

2017-04-13T02:04:26+00:00

am: 3df5466891

Change-Id: I5ffdcdc73430c90215f2462ea8966460ab437d58

Mark as vendor_available

2017-04-13T01:58:26+00:00

am: 84a0dad630

Change-Id: I02cdc7c13b9ade5303c194212ae67ffa7c066d77

Mark as vendor_available am: 68d0b5790f am: 006fdf8790 am: a76824d27a

2017-04-12T22:49:32+00:00

am: 6c661f4fb8

Change-Id: I6f3779c396f28925e59b225c2b01706d3c55859f

Mark as vendor_available am: 68d0b5790f am: 006fdf8790

2017-04-12T22:17:17+00:00

am: a76824d27a

Change-Id: Iff6090d8a67e47938ad3f50ff327ddea4431132d

Mark as vendor_available am: 68d0b5790f

2017-04-12T22:11:51+00:00

am: 006fdf8790

Change-Id: I478190359f8713c91268d1df5c10782693a71463

Mark as vendor_available

2017-04-12T22:05:49+00:00

am: 68d0b5790f

Change-Id: I2acdde83830ee1f83fee862e682e920010b523a6

Mark as vendor_available

2017-04-11T18:23:46+00:00

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
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: Ia48408aa590eb357337c42453939ff43e5d0f42e
Change-Id: Ia48408aa590eb357337c42453939ff43e5d0f42e

Mark as vendor_available

2017-04-11T04:27:29+00:00

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
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
Change-Id: Ia48408aa590eb357337c42453939ff43e5d0f42e

Convert Android.mk to Android.bp am: a088d39af5 am: ca8a085abe am: fcc2940e96

2016-07-18T19:37:23+00:00

am: 7d25406b60

Change-Id: I1b664e3d7d3fb2b157e6e68d4fb6cca8fa477a91

Convert Android.mk to Android.bp am: a088d39af5 am: ca8a085abe

2016-07-18T19:33:52+00:00

am: fcc2940e96

Change-Id: I3e6cca84ead325f5ad9959b5ffa59b6af33c29e2