<feed xmlns='http://www.w3.org/2005/Atom'>
<title>platform_external_modp_b64/Android.bp, branch android10-s3-release</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.replicant.us/mirrors/AOSP/platform_external_modp_b64/'/>
<entry>
<title>Add an NDK library variant</title>
<updated>2019-02-05T17:29:08+00:00</updated>
<author>
<name>Emilian Peev</name>
<email>epeev@google.com</email>
</author>
<published>2019-01-29T19:06:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.replicant.us/mirrors/AOSP/platform_external_modp_b64/commit/?id=57d75ecd5bc1c94c4483cff98aa9fb28a05f2ea5'/>
<id>57d75ecd5bc1c94c4483cff98aa9fb28a05f2ea5</id>
<content type='text'>
An NDK built static variant is needed for
clients that build against the NDK.
The new library will not be part of the
NDK public interface.

Bug: 123237859
Test: Camera CTS
Change-Id: I379ce9c27c34d54048f4a0f1c3d0b4fadb6abc7e
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
An NDK built static variant is needed for
clients that build against the NDK.
The new library will not be part of the
NDK public interface.

Bug: 123237859
Test: Camera CTS
Change-Id: I379ce9c27c34d54048f4a0f1c3d0b4fadb6abc7e
</pre>
</div>
</content>
</entry>
<entry>
<title>Mark libmodpb64 as recovery_available for update_engine_sideload</title>
<updated>2018-10-23T21:08:14+00:00</updated>
<author>
<name>Dan Willemsen</name>
<email>dwillemsen@google.com</email>
</author>
<published>2018-10-23T21:08:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.replicant.us/mirrors/AOSP/platform_external_modp_b64/commit/?id=df5b9e2d80b310a9d084ba20929a1848297f63f4'/>
<id>df5b9e2d80b310a9d084ba20929a1848297f63f4</id>
<content type='text'>
Test: build update_engine_sideload
Change-Id: Ibdf0d789f9cbdfe4c4f8583ee74e835ad2609ee9
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Test: build update_engine_sideload
Change-Id: Ibdf0d789f9cbdfe4c4f8583ee74e835ad2609ee9
</pre>
</div>
</content>
</entry>
<entry>
<title>Mark as vendor_available</title>
<updated>2017-04-11T04:27:29+00:00</updated>
<author>
<name>Dan Willemsen</name>
<email>dwillemsen@google.com</email>
</author>
<published>2017-04-07T21:13:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.replicant.us/mirrors/AOSP/platform_external_modp_b64/commit/?id=68d0b5790fff5243aab59ae8108d7e69506ac4c4'/>
<id>68d0b5790fff5243aab59ae8108d7e69506ac4c4</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>Convert Android.mk to Android.bp</title>
<updated>2016-07-14T06:56:38+00:00</updated>
<author>
<name>Dan Willemsen</name>
<email>dwillemsen@google.com</email>
</author>
<published>2016-07-14T06:56:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.replicant.us/mirrors/AOSP/platform_external_modp_b64/commit/?id=a088d39af5bb8fb31e4397943f6380a3747c61ea'/>
<id>a088d39af5bb8fb31e4397943f6380a3747c61ea</id>
<content type='text'>
Change-Id: I75cf1cc4fe6abe0967aebefc3c62aad86555a6e3
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change-Id: I75cf1cc4fe6abe0967aebefc3c62aad86555a6e3
</pre>
</div>
</content>
</entry>
</feed>
