This reverts commit 2ac7fd1e56.
Do not use `upload-release-action` for uploading artifacts and generating checksum and instead keep using standard `sha256sum` and internal github tools. `upload-release-action` also generates checksum in the wrong format, check https://github.com/termux/termux-app/pull/3241#discussion_r1106019790.
The `TermuxBootstrap` class has been added that defines the `PackageManager` and `PackageVariant` classes for the supported package manager configurations for the app. The variant is defined by the `project.ext.packageVariant` value in the `app/build.gradle` and its value is used by the `build.gradle` to pack its respective bootstrap zips in the app APK at build time and the value is used to set `TermuxBootstrap.TERMUX_APP_PACKAGE_MANAGER` and `TermuxBootstrap.TERMUX_APP_PACKAGE_VARIANT` static values that are used at runtime by the app to run variant specific code. The manager is automatically extracted from the variant as the substring before first dash `-`.
The default variant is `apt-android-7` and it can either be replaced in `app/build.gradle` manually or the `TERMUX_PACKAGE_VARIANT` env variable can be exported in which the build command is run.
The `TERMUX_APP_PACKAGE_MANAGER` and `TERMUX_APP_PACKAGE_VARIANT` environmental variables will be exported by the app and they will also be added in Termux app info in about page and reports, allowing users and devs to know which variant is currently installed.
Bootstrap of a different variant must not be manually installed by the user after app installation by replacing `$PREFIX` since app code is dependant on the variant used to build the APK.
Currently, `apt-android-7` and `apt-android-5` variants will be built for by the workflows but they will fail for `apt-android-5` since `build.gradle` support is currently not enabled and will be enabled by a pull request that adds support for Android 5. The workflow needs to try to build the `apt-android-5` variant so that pull request builds are generated.
The `versionName` will now follow semantic version `2.0.0` spec in the format `major.minor.patch(-prerelease)(+buildmetadata)`. This will make versioning the prerelease and github debug builds versions easier and follow a spec. The @termux devs should make sure that when bumping `versionName` in `build.gradle` files and when creating a tag for new releases on github that they include the patch number as well, like `v0.1.0` instead of just `v0.1`. The `build.gradle` files and `attach_debug_apks_to_release` workflow will now validate the version as well and the build/attachment will fail if `versionName` does not follow the spec. https://semver.org/spec/v2.0.0.html
APKs released on github for debug build workflows and releases are now referred as `Github` releases as per 7b10a35f and 94e01d68, so APK filenames have been modified to include `github` in the filename. The APKs are still debuggable, so that tag remains too.
For github workflows the apk filename format will be `termux-app_<current_version>+<last_commit_hash>-github-debug_<arch>.apk`, like `termux-app_v0.1.0+xxxxxxxx-github-debug_arm64-v8a.apk` and for github releases it will be `termux-app_<release_version>+github-debug_<arch>.apk`, like `termux-app_v0.1+github-debug_arm64-v8a.apk`. The `last_commit_hash` will be the first `8` characters of the commit hash. The `<last_commit_hash>-github-debug` will act as `buildmetadata` and will not affect versioning precedence.
For github workflows triggered by `push` and `pull_request` triggers, `<current_version>+<last_commit_hash>` will be used as new `versionName`, like `v0.1.0+xxxxxxxx`. This will make tracking which build a user is using easier and help in resolving issues as well.
Note that users using github releases and termux devs using `$TERMUX_VERSION` environment variables in scripts should take commit hash into consideration and possibly use something like `dpkg --compare-versions "$TERMUX_VERSION" ge 0.1` where appropriate instead of mathematical comparisons.
The `app/build.gradle` now also supports following `TERMUX_` scoped environmental variables and `RELEASE_TAG` variable will not be used anymore since it may conflict with possibly other variables used by users. They will also allow enabling split APKs for both debug and release builds.
- `TERMUX_APP_VERSION_NAME` will be used as `versionName` if its set.
- `TERMUX_APK_VERSION_TAG` will be used as `termux-app_<TERMUX_APK_VERSION_TAG>_<arch>.apk` if its set. The `_<arch>` will only exist for split APKs.
- `TERMUX_SPLIT_APKS_FOR_DEBUG_BUILDS` will define whether split APKs should be enabled for debug builds. Default value is `1`.
- `TERMUX_SPLIT_APKS_FOR_RELEASE_BUILDS` will define whether split APKs should be enabled for release builds. Default value is `0` since F-Droid does not support split APKs, check #1904.
So based on above, if in future github releases are to be converted to `release` builds instead of `debug` builds, something like following can be done and even a workflow can be created for it. Users can also build split APKs release builds for themselves if they want.
```
export TERMUX_SPLIT_APKS_FOR_RELEASE_BUILDS=1
./gradlew assembleRelease -Pandroid.injected.signing.store.file="$(pwd)/app/dev_keystore.jks" -Pandroid.injected.signing.store.password=xrj45yWGLbsO7W0v -Pandroid.injected.signing.key.alias=alias -Pandroid.injected.signing.key.password=xrj45yWGLbsO7W0v
```
The APK will be found at `./app/build/outputs/apk/release/termux-app_<version>_<arch>.apk`
The `TERMUX_SPLIT_APKS_FOR_DEBUG_BUILDS` can be set to `0` to disable building split APKs which may be helpful for users building termux on device considering they will extra space and build time. Instructions for building are at https://github.com/termux/termux-packages/pull/7227#issuecomment-893022283.
```
export TERMUX_SPLIT_APKS_FOR_DEBUG_BUILDS=0
./gradlew assembleDebug
```
The APK will be found at `./app/build/outputs/apk/debug/termux-app_debug_universal.apk`
Note that F-Droid uses algorithm at https://gitlab.com/fdroid/fdroidserver/-/blob/2.1a0/fdroidserver/build.py#L746 to automatically detect built APKs, so ensure any modifications to location or file name are compliant. Current updates should be.
Auto updates are detected by checkupdates bot at https://gitlab.com/fdroid/fdroidserver/-/blob/master/fdroidserver/checkupdates.py
APKs for each architecture and a universal APK that is compatible for all architectures will now be available from Github Actions page from the workflow runs labeled `Build`. The APKs will be available as zips under the Artifact section named `termux-app-*`.
Architecture specific APKs can be used by users with low disk space since F-Droid releases are universal (since it doesn't support split APKs #1904) and their install+bootstrap installation size is ~180MB instead of ~120MB if an architecture specific APK is used.
This should also reduce bandwidth usage and download time for debug builds users if they download an architecture specific zip instead of the universal one.
Related #2153
Github Package hosting is considered a private repository since it requires github APIs keys if a hosted library needs to be imported as a dependency. Importing from private repositories is not allowed as per F-Droid policy so termux plugin apps can't import termux libraries as dependencies so hence we move to Jitpack. Check https://github.com/termux/termux-app/issues/2011#issuecomment-824837387.
Version number of all published libraries from termux-app must be the same.
Importing can be done with the following way.
Add to root level build.gradle
```
allprojects {
repositories {
google()
mavenCentral()
//mavenLocal()
maven { url "https://jitpack.io" }
}
}
```
Add to app module level build.gradle if you want to import `termux-shared`
```
dependencies {
implementation 'com.github.termux:termux-shared:0.115'
}
```
Check https://github.com/jitpack/jitpack.io#building-with-jitpack for other details, like including commit or branch level import.
If you are updating the libraries as well and want to test locally, run `./gradlew publishReleasePublicationToMavenLocal` from root directory of termux-app to publish library to local maven repository. You may need to rebuild project before it, library files will be published at `~/.m2/repository/com/github/termux/termux-shared/0.115`. If you want to import the updated library in a project, then uncomment the `mavenLocal()` line in the build.gradle and run sync gradle with project files.
Making changes to library after dependencies have already been cached without incrementing version number may need deleting gradle cache if syncing gradle files doesn't work after publishing changes. Open gradle right sidebar in android studio, then right click on top level entry, then select "Refresh Gradle Dependencies", which will redownload/refresh all dependencies and will take a lot of time. Instead running `find ~/.gradle/caches/ -type d -name "*com.github.termux*" -prune -exec rm -rf "{}" \; -print` and then running gradle sync should be enough.
Using "com.termux" instead of "com.github.termux" will require a DNS TXT record to be added from git.termux.com to https://github.com/termux at termux.com
https://jitpack.io/docs/#custom-domain-name
dependabot[bot]
agnostic-apollo
Yaksh Bariya
Lucy Phipps
daywalk3r666
Sushrut1101
Henrik Grimler
agnostic-apollo
Leonid Pliushch
hannesa2
Leonid Plyushch