This adds an `inactive` field to a `RemoteTabRecord` with the default
value being `false`. The intent is for the mobile platforms to start
populating this, then all platforms can choose how to handle such
tabs (eg, they may not show them by default and instead add a button
which shows them).
Prior to this commit, the `build.gradle` for each individual
project contained copy-pasted logic for configuring Android
and protobuf. Some of them were even using slightly different
versions of the same dependencies.
With this commit, there are two new gradle scripts that encapsulate
this shared logic:
* ./build-scripts/component-common.gradle, for basic Android
and Kotlin setup.
* ./build-scripts/protobuf-common.gradle, for configuration specific
to the protobuf plugin.
Hopefully this will make the logic easier to maintain going forward.
Prior to this commit, each of our individual components had its
own copy of gradle logic for depending on the megazord, including
a couple of lengthy comments about fiddling around with JNA for
the Android Studio test runner.
I've moved all that logic into a helper function in `publish.gradle`
so that we can maintain it in a single location from here out.
There may be a cleaner or more idiomatic way to achieve this kind
of code-sharing in gradle, but I figure this *has* to be better
than our current copy-paste-based approach.
I've manually confirmed that a local `./gradlew test` completes
successfully, as well as testing via Android Studio.
This fixes the "Cannot inline bytecode built with JVM target 1.8 into
bytecode that is being built with JVM target 1.6. Please specify proper
'-jvm-target' option" problem.
Our docs currently recommend two ways of building consuming apps against
local changes to this repo: an automated-but-perpetually-buggy composite build
workflow, and a reliable-but-tedious manual workflow of publishing to a local
maven repo.
This commit removes them both and replaces them with something similar to
the workflow used by android-components: some scripting to automate publishing
to and consuming from a local maven repo.
There where two issues. The most obvious is that the task name that
merges JNI libraries has evolved; it's now `merge{...}JniLibFolders`.
The second, which really caught me out, is that when both
`main.jniLibs.srcDirs` and `debug.jniLibs.srcDirs` contain the same
path, then the Android source set merger silently fails. I don't
really understand what's happening here, I just know that using only
`main.jniLibs.srcDirs` solves the issue.
Fixes#2659.
Ben Dean-Kawamura
Ryan VanderMeulen
Mark Hammond
Sammy Khamis
Tarik Eshaq
lougeniaC64
Ryan Kelly
Ryan Kelly
Alessio Placitelli
Thom Chiovoloni
Edouard Oger
Nick Alexander