For Android, app requirements are not always updated when using -r/--update-requirements

[rmartin16]

Describe the bug

The use of -r/--update-requirements should force the build of a project to install the app's requirements. This is currently true for all output formats except Android Gradle. When a Gradle project is built, the step to install requirements only runs the first time an app is built or if the requirements.txt file changes.

Therefore, running briefcase build android -r is not guaranteed to update the requirements in the Gradle build unless requirements.txt file generated from the app's requirements is different from the last time it ran.

Steps to reproduce

1. Run briefcase build android
2. Run briefcase build android -r and see requirements are not installed again

Expected behavior

The app's requirements are installed whenever the -r/--update-requirements flag is used. As noted in #1719 (comment), any change to the content of requirements.txt will trigger the requirements to be re-installed during the next Gradle build; so, simply adding a timestamp to the file would achieve this, for instance.

Furthermore, this installation should effectively eagerly update the app's requirements and their requirements and so forth. While pip can be configured to do this with --upgrade-strategy=eager, Briefcase normally achieves this by not updating an existing installation of requirements but by removing all installed requirements and installing everything again.

Screenshots

No response

Environment

• Operating System: pop os 22.04
• Python version: 3.12.2
• Software versions:
  • Briefcase: 0.3.18.dev162+g9b284776

Logs

briefcase build android - briefcase.2024_04_05-11_46_02.build.log
briefcase build android -r - briefcase.2024_04_05-11_46_50.build.log

Additional context

No response

[mhsmith]

Briefcase normally achieves this by not updating an existing installation of requirements but by removing all installed requirements and installing everything again.

Chaquopy also does this.

[freakboy3742]

The potential edge case here is that Briefcase's direct installations will do this "false eager" update on every run with a -r update; whereas Chaquopy/Android only does the update if the contents of the requirements have changed. If a transitive dependency that isn't explicitly mentioned in the requirements has an update, a Briefcase-installed update would install the update, but Chaquopy wouldn't.

The catch is how "requirements have changed" is detected. Unless Chaquopy detects a change in requirements, it won't do a "false eager" update. Is Chaquopy's mechanism based on a file hash, or a comparison of the literal requirements?

[mhsmith]

A file hash, so including a comment with a timestamp would be enough to make it run pip again.