this shrinks the window where a publish may leave the versioning out of sync
Related #8219 - still a tiny window where a merge within 10mins or so of a publish
may cause problems
This is required for it to work on Java 11, and the old version in use without
this change is obsolete (because it does not work on java11)
Note that GitHub macos-latest - which is used by the workflow that runs this script
as well as normal development environments - has this installed, verified in:
https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md#android
(command line tools 4.x is sufficient, it is current "latest" and is installed)
According to https://support.crowdin.com/api/update-file/ , currently, if a string is changed in english, it'll be
marked as needing review everywhere. This is a problem because we either want to add meta-clarification (for translator)
or correct typo. This change ensure that we have the behaviour we want; strings as never seen as changed. If we want to
really change a string, it'll be a new id
This can't be tested until it is actually merged in github.
With the addition of amazon publishing, and another 'applicationId'
in build.gradle, the search for the original app name broke so parallel
rename was not working
There is no need to scan for those values dynamically though, they are fixed
deeply in order to preserve application contintuity on the app stores, so
we can just hard-code them
Previous change meant we never had universal APKs but they are useful
This enables them again if you send a command-line toggle in, and then
uses the toggle to upload builds to github
This reduces built APK to 7.5MB vs 10.4MB
Careful consideration was taken to version range space so we won't exhaust it
Manual downloads (github attachments, mostly) are configured as armv7 since no
one uses x86 in real devices anymore - and armv8 devices can run armv7 code
There was an expectation in the importer script that all
language codes had a 2-letter root, but many valid codes that Android
accepts have 3-letter codes *and* collide with the 2-letter codes (fi vs fil)
There was the expectation in the LanguageUtil object that languages
all had 2-letter roots as well, it was altered to split on '-' instead
of on specific character indices, with associated unit testing to verify
Additionally, the 'yu' (Cantonese) custom code needed to map to 'yue'
Not sure exactly why it is mac dependent but it seems to be now,
so I made the one search that was failing not be a hard-fail and
gave it a notice for any developers using it to scan
Not sure why I didn't notice before but we have a lot more languages
enabled than we were importing and allowing.
No not all of them are translated but they were all user requests, and
if we don't put them in the UI, why would a translator bother?
This was primarily in response to a user request for Sorani (Kurdish),
which is now enabled (locale code ckb)
This enforces that the public changelog is up to date as it
becomes the source for the changelog shipped with the app
Checks that all the necessary release tools exist and that the changelog
actually contains the information for the current version too
Fixes#6197
