Allow Android apps to specify their own list of libraries

[freakboy3742]

beeware/toga#2346 has raised the prospect that we might need to add an extra library to the list in the app template. Rather than make a special case of that one library for Toga, this PR adds a general feature, and includes the extra library as part of the Toga bootstrap.

Any existing project will inherit the list of requirements that was present in the Briefcase 0.3.16 Android template.

Requires the use of beeware/briefcase-android-gradle-template#82

Refs #485.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

It just occurred to me that dependencies clashes with the PEP621 name, so we probably want to pick a different name for Android configuration.

Possible options:

• android_dependencies
• gradle_dependences
• system_runtime_requires (for symmetry with Linux?)

[mhsmith]

Shouldn't this be app.dependencies? Maybe this is why you couldn't import the navigation bar class.

[mhsmith]

It just occurred to me that dependencies clashes with the PEP621 name

system_runtime_requires seems like a good replacement, since it's conceptually doing the same kind of thing.

[freakboy3742]

I wasn't using this branch when I was getting the import failure; I was manually modifying the build.gradle after calling create.

But yes - this should be app.dependencies (or whatever name we land on).

I agree that this is conceptually similar to system_runtime_requires; however, all the variables we've added recently map as closely as possible to the "native platform naming". The benefit here is that we don't need to answer questions about how a Briefcase name maps to a platform specific name (e.g., explaining that "system_runtime_requires maps to build.gradle dependencies) - the naming of the Android-specific customizations is at least slightly intuitive to Android users. My inclination is to go with gradle_dependencies on that basis.

[freakboy3742]

Scratch that - for consistency with existing Android options, it should be build_gradle_dependencies.

[mhsmith]

Yes, that makes sense.

[mhsmith]

Since we won't be using any of the other dependency types in the foreseeable future, adding an extra implementation layer seems unnecessary, and loses the simplicity of having the cookiecutter context match directly with the pyproject.toml structure.

[freakboy3742]

Unfortunately, it is needed. Cookiecutter doesn't let you pass a list as a context value - if you do, it's interpreted as a choice, and it gives you the "default" (the first item). Passing a dictionary with a single key is how you work around this; in this case, it just happens that there is a convenient name available for that key, even if we're not going to use any of the alternative key values.

[freakboy3742]

The dependency list gets a lot simpler under material, because appcompat and constraintlayout are both dependencies of material.

[mhsmith]

I think it would be better to keep pinning the version of appcompat, because we use that directly in MainActivity and in toga_android, so allowing it to default to the newest version could cause unpredictable behavior changes.

On the other hand, we don't actually use constraintlayout at all. Its only reference is in the Android template at app/src/main/res/layout/activity_main.xml, but that's just an example layout which we don't use anywhere. So to avoid confusion, I suggest updating beeware/briefcase-android-gradle-template#82 to remove it.