Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds on #483 and #482 .
"Prefab" is the way to go these days for native libraries in Android build systems. Switching to prefab here gives us a few advantages, including simplified build scripts, and build dependencies that actually work (
./gradlew hellocardboard-android:installDebug
in a fresh clone actually works properly.)There are a few quirks. I had to switch to the shared C++ runtime for the SDK so it would be acceptable to use in a shared library linked to another C++ project, per the rules of the AGP. This is actually overkill, since the cardboard SDK only exports C symbols, but I didn't see a way in AGP to override the exposed STL in the prefab metadata. (Ideally we would build against the static and have the prefab report "NONE", because of only exporting C symbols, but I couldn't figure out how to do that in Gradle. In another project I maintain, I make the prefab metadata files manually, building with CMake and packing with a bash script rather than gradle to get this working.)
So the prefab isn't ideal for use outside the project, but within a single project (e.g. as a submodule) it appears to work great!