| Age | Commit message (Collapse) | Author |
|---|
|
am: 3df5466891
Change-Id: I5ffdcdc73430c90215f2462ea8966460ab437d58
|
|
am: 84a0dad630
Change-Id: I02cdc7c13b9ade5303c194212ae67ffa7c066d77
|
|
am: 6c661f4fb8
Change-Id: I6f3779c396f28925e59b225c2b01706d3c55859f
|
|
am: a76824d27a
Change-Id: Iff6090d8a67e47938ad3f50ff327ddea4431132d
|
|
am: 006fdf8790
Change-Id: I478190359f8713c91268d1df5c10782693a71463
|
|
am: 68d0b5790f
Change-Id: I2acdde83830ee1f83fee862e682e920010b523a6
|
|
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
|
|
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
|
|
am: 7d25406b60
Change-Id: I1b664e3d7d3fb2b157e6e68d4fb6cca8fa477a91
|
|
am: fcc2940e96
Change-Id: I3e6cca84ead325f5ad9959b5ffa59b6af33c29e2
|
|
am: ca8a085abe
Change-Id: I16cd7306bdd967bd9fc7defebdb5f8db2a2f51b4
|
|
am: a088d39af5
Change-Id: I71eb54196aeb25d04e1083c9eb518230bcce1b23
|
|
Change-Id: I75cf1cc4fe6abe0967aebefc3c62aad86555a6e3
|
|
8a6dfb4ec3 am: b0bff9549b am: c5eaf1bed0
am: fc053cb093
* commit 'fc053cb0934e451ddb3514ec0fb153760ac11853':
modp_b64: Fix BUILD.gn to be able to build the library with GN
Change-Id: Ie8dbe4404a8c9863bad81540842a2c560355ab69
|
|
8a6dfb4ec3 am: b0bff9549b
am: c5eaf1bed0
* commit 'c5eaf1bed04c7c31a719ec77bf5af2eaa7463534':
modp_b64: Fix BUILD.gn to be able to build the library with GN
Change-Id: I646a82ad63e4a33e21690e355b5c0556f5000d50
|
|
am: b0bff9549b
* commit 'b0bff9549b39f3a511c14e35a5a976b11709375e':
modp_b64: Fix BUILD.gn to be able to build the library with GN
Change-Id: I903776bdeb4ada7324d941ffc3b392f8a92d8dab
|
|
am: 8a6dfb4ec3
* commit '8a6dfb4ec3cb62e6ff4d1b863215463ad09095f7':
modp_b64: Fix BUILD.gn to be able to build the library with GN
Change-Id: I2763b1053b85354f5f1b717cedce89f9b6c0f780
|
|
Added missing config and fixed include paths.
BUG=None
Change-Id: I7066a2dfc45b169f1216cdf36addc80897917d15
|
|
After headers were moved to modp_b64 folder BUILD.gn file was
not updated to reflect the change.
Change-Id: I619d450193af3bf7256b10f6459ef5825ce12451
|
|
* commit '4f8ee97e89a08f25e55f04873a1abd129e0d47f2':
|
|
* commit 'b1e6e2024f4b05e9747556c0937d6770da74ba13':
Move header to modp_b64 subdir.
|
|
|
|
libchromeos imports modp_b64 via modp_b64/modp_b64.h. Moving it into a
subdirectory make the import cleaner.
(cherry-pick from b1e6e2024f4b05e9747556c0937d6770da74ba13)
Change-Id: Ib4b778bd103af1f75ea7ba5333e722a7699f91e7
|
|
libchromeos imports modp_b64 via modp_b64/modp_b64.h. Moving it into a
subdirectory make the import cleaner.
Change-Id: Ib4b778bd103af1f75ea7ba5333e722a7699f91e7
|
|
This is apparently the convention, and is easy to change before we grow
dependencies.
Bug: 22608897
Change-Id: I22c8b416fae9be49c9cd200f217b5853b8a29758
|
|
Bug: 22608897
Change-Id: I9074738f8cc0aeb75add85c0b22051b8187db197
|
|
|
|
We want to use this repo to build modp_b64 in Chromium OS. This CL adds
a Chromium OS style makefile to build modp_b64 as a static library.
Change-Id: I202eb2ddc046826872f69962739f3968efaad941
|
|
This makes it so that users of this library don't need to
explictly add external/modp_b64 to LOCAL_C_INCLUDES.
Bug: 22353299
Change-Id: If9170824c0eec9182434053689892860a66c3514
|
|
Added an Android.mk file that builds the package as a static library called
libmodpb64.
Bug: 22353299
Change-Id: I00dd9ceede22c30f8883a1a7b917d317f0b92b6d
|
|
Copy the unchanged source from
https://chromium.googlesource.com/chromium/src/third_party/modp_b64. The latest
commit in Chromium was 279ad18 while the latest commit that touched
third_party/modp_b64 was e9705fd.
Added MODULE_LICENSE_BSD and NOTICE. The latter is identical to the existing
LICENSE file.
Bug: 22382625
Change-Id: I0e5d00abb84f087d20529aa1d2bf47b5cb4c75b5
|
|
|
