The Google w^x security policy

[green-green-avk]

A long time ago in a galaxy far, far a Milky Way.... Google forces...

From August 2020, new apps must target at least Android 10 (API level 29).
From November 2020, app updates must target Android 10 (API level 29).

The preliminary plan is to split the application into two:

• Still targeted API 28 and published here.
• Targeted API 29 and has a built-in PRoot.

[green-green-avk]

It seems reasonable to upgrade the current application green_green_avk.anotherterm to API 29 and preserve the API 28 version as green_green_avk.anotherterm.oldgood.
Embedding either the whole PRoot or just some kind of loader / execve() wrapper is still TBD.
Please, post any objections here.

[guillaume-d]

If the application ID changes, app catalogues (like F-Droid over the IzzyOnFroid F-Droid Repo already) will be unable to suggest/perform upgrades to devices from Android < 10 (API <= 28) to Android >= 10 (API >= 29).

The only downside in enabling this is that you will permanently lose at least one versionCode bit to keep the versions in order, and even preferably a few more bits to plan for more such API compatibility breaks in the future.

See for instance the example code at https://developer.android.com/studio/build/build-variants#flavor-dimensions and the rationale at https://developer.android.com/google/play/publishing/multiple-apks.

It all depends of course if you want to maintain both flavors or not.

Also in any case you might want to set maxSdkVersion on the API < 29 APKs to avoid frustrated users...

[green-green-avk]

Just to avoid misunderstanding:

1. It's purely a Google policy to cull all the applications targeting API < 29 from the Google Play platform.
2. Targeting API >= 29 will effectively disable the ability to run binaries from writable by the application disk locations by execve() system call on Androids >= 10.
3. Targeting API < 29 does not mean lost compatibility with Androids >= 10 but preserve the aforementioned ability.

BTW, a different application id means a different application with independent versionCodes.

[guillaume-d]

I am aware of all of the above and think I have understood it correctly, but I am not sure I understood your plan, so let me rephrase it from a user's perspective:

• only as soon as this bug is fixed users of older devices (Android < 10) will need to uninstall the current app (with the current application ID) and install the oldgood app instead to get updates
• users of Android 10+ devices could technically do the same as the above users (just not from Google Play anymore in November 2020 and later), but for the moment / before this bug is fixed and also after it has been fixed they can simply just update normally and will get a working app
• four APKs per unique version number will be available for download: oldgood/normal in release/debug mode (or will oldgood and normal diverge, if only by their version number?)

Is that correct?

[green-green-avk]

• only as soon as this bug is fixed users of older devices (Android < 10) will need to uninstall the current app (with the current application ID) and install the oldgood app instead to get updates

No. Increasing targetSdkVersion to 29 will not affect any Android < 10 users at all.

• users of Android 10+ devices could technically do the same as the above users (just not from Google Play anymore in November 2020 and later), but for the moment / before this bug is fixed and also after it has been fixed they can simply just update normally and will get a working app.

Yes. It turned out, it's even possible to pack minitar / PRoot / some execve() replacing launcher into a separate plugin APK (to still be able to use Google Play).

[guillaume-d]

OK, forget all what I wrote here, I was thinking it was about minSdkVersion the whole time, whereas it really was about targetSdkVersion.
Now it makes sense, sorry for the confusion.

[green-green-avk]

26b36c7

[green-green-avk]

green-green-avk/AnotherTermShellPlugin-Android10Essentials@84cc62e

[green-green-avk]

green-green-avk/AnotherTerm-scripts@b895382

[green-green-avk]

Uh, huh... See https://green-green-avk.github.io/AnotherTerm-docs/local-shell-w-x.html#main_content.

But... Successfully done.

[IzzySoft]

As @guillaume-d wrote in October:

If the application ID changes, app catalogues (like F-Droid over the IzzyOnFroid F-Droid Repo already) will be unable to suggest/perform upgrades

I shorten this as it applies to ALL devices/users – now that no APK available here has the "original" packageName. So which variant would you like to be kept with my repo now? I'm not bound to Google's rules.

Further, what speaks against sticking to the (non-suffixed) packageName for release builds? I fully understand a suffix for debug builds (so one can install them in parallel to "test stuff") – but not for release builds one is unlikely to install in parallel. Sticking to the same packageName would also allow to switch between the two at-will without uninstalling.

I will now disable auto-updates in my repo as I don't know which version to establish – so before I start "confusing users" I better wait for your answer, @green-green-avk – on

• which variant to pick for my repo
• whether you will switch back to the original packageName

Thanks!

[IzzySoft]

@green-green-avk any word?

[green-green-avk]

Taking into account both:

• ability to downgrade;
• better compatibility with future Android versions / possible solution of the Bluetooth UART dongles issue in Android versions after 10;

I think, it's better to choose the .redist variant.

In this case, I recommend to include also https://github.com/green-green-avk/AnotherTermShellPlugin-Android10Essentials;
see https://green-green-avk.github.io/AnotherTerm-docs/local-shell-w-x.html#plugin.

PS: I'm sorry that I completely missed your previous message somehow.

[IzzySoft]

Thanks @green-green-avk – switching to the redist variant then (just done, effective with the next sync tomorrow around 7:45 pm CEST/UTC+2). Speaking of which: would you mind accepting PR #15 – so you get "full powers" over app description, screenshots etc as shown in my repo (and if you like also usable for Play Store)?

In this case, I recommend to include also

On it right now. Does that plugin require root?

PS: I'm sorry that I completely missed your previous message somehow.

Happens. Lots of works to do 😉 As I guess the same "missing" happened to my PR, I've mentioned it right along here 😄 I can offer the same PR for the plugin if you wish.

[green-green-avk]

Thanks @green-green-avk – switching to the redist variant then (just done, effective with the next sync tomorrow around 7:45 pm CEST/UTC+2). Speaking of which: would you mind accepting PR #15 – so you get "full powers" over app description, screenshots etc as shown in my repo (and if you like also usable for Play Store)?

• Thank you.
• PR add initial fastlane structures #15 was not missed, just postponed... I'll take some time to merge it.

In this case, I recommend to include also

On it right now. Does that plugin require root?

No. This plugin just provides a workaround to avoid root requirement on Android 10 and higher
(I think, it's better to install / upgrade PRoot and minitar independently of the main application).

[IzzySoft]

Sorry for the late response – both apps are listed in my repo now. If you want to link there:

• Essentials
• Terminal
• Badge 😃