5 ms·

For every new release of android there is only one thing I care about, how will this affect termux? So I did a google and looks promising ( https://www.reddit.

by tjoff 5y ago

For every new release of android there is only one thing I care about, how will this affect termux? So I did a google and looks promising ( https://www.reddit.com/r/termux/comments/nyayhq/comment/h1j9jmj/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/termux/comments/nyayhq/comment/h1j9... ).

NotPractical 5y ago
Me too, haha. I like the new UI and privacy controls, but this is always the most important consideration. By the way, as far as I know, Termux (at least as we know it) is for sure eventually doomed, which is really sad. Here's a brief explanation for those uninitiated: * Android 10 introduced a restriction that apps targeting API version 29+ can no longer invoke exec() on files within the app's home directory, which breaks Termux [1]. * An app can target any API version. There is a hardcoded "min_supported_target_sdk" in the Android source code (23 as of Android 12) [2], but as of now targeting a lower version only produces a warning, and it will likely take quite a long time before it reaches 29 anyway [3]. The main problem is that the Play Store won't allow new app updates targeting <29. For now, the Play Store Termux build is very out of date and it's recommended to get Termux from F-Droid. But for some reason, the developer of Termux has decided that they want to make Termux API 29 compatible [4]. (Perhaps to ensure long-term compatibility if the "min_supported_target_sdk" ever increases past 28 AND starts to actually be enforced, or maybe just because they want to distribute Termux in the Play Store, even though most of its users would be perfectly comfortable getting it from F-Droid?) * Making Termux API 29 compatible will make it a lot less fun and a lot less practical to use. All executables will have to be distributed inside separate APK files which must be individually installed, since exec() can now only be called on files in the read-only /data/app directory [5]. Say goodbye to `apt install <name>`. * Google continues to further restrict the OS in ways that break certain functionality within Termux. * Termux still works mostly normally for now in Android 10 and 11 (and 12, it seems), but its developer is already at work on the weird APK packaging system. [1] https://github.com/termux/termux-packages/wiki/Termux-and-Android-10 https://github.com/termux/termux-packages/wiki/Termux-and-An... [2] https://android.googlesource.com/platform/prebuilts/fullsdk/platforms/android-31/+/refs/heads/master/build.prop#40 https://android.googlesource.com/platform/prebuilts/fullsdk/... [3] https://github.com/termux/termux-app/issues/1072#issuecomment-473965266 https://github.com/termux/termux-app/issues/1072#issuecommen... [4] https://github.com/termux/termux-app/issues/1072#issuecomment-755013204 https://github.com/termux/termux-app/issues/1072#issuecommen... [5] https://github.com/termux/termux-app/issues/1072#issuecomment-671910224 https://github.com/termux/termux-app/issues/1072#issuecommen... === EDIT === According to the README, the current plan is actually to continue targeting API 28 for now: > There is currently no work being done to solve android 10 issues and working updates will not be resumed on Google Play Store any time soon. We will continue targeting sdk 28 for now. They are looking for contributors to help make an API 29 compatible version though: > @termux is looking for Termux Application maintainers for implementing new features, fixing bugs and reviewing pull requests since the current one (@fornwall) is inactive. Issue https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/1072 needs extra attention. https://github.com/termux/termux-app/blob/master/README.md#google-play-store-deprecated https://github.com/termux/termux-app/blob/master/README.md#g...
- pjmlp 5y ago
  Good luck with that plan, https://developer.android.com/distribute/best-practices/develop/target-sdk#pre11 https://developer.android.com/distribute/best-practices/deve... > Starting in November 2021, app updates will be required to target API level 30 or above and adjust for behavioral changes in Android 11. Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Wear OS apps must continue to target API level 28 or higher. Android is not a POSIX OS, apis like exec() where never part of the public APIs, time to embrace the Java ways of the platform. https://developer.android.com/ndk/guides/stable_apis#c_library https://developer.android.com/ndk/guides/stable_apis#c_libra...
  - NotPractical 5y ago
    This is Play Store policy, not Android policy. As I said, the Android OS currently doesn't enforce the minimum API level, and this probably won't become a problem for a long time, as long as you are distributing outside the Play Store (e.g. through F-Droid).
    - pjmlp 5y ago
      That isn't the Android version that most people get to use.
      - NotPractical 5y ago
        When I say "Android OS" here, I don't mean AOSP, I mean most (or all) manufacturer-customized Android ROMs, including Samsung, Pixel, etc. I don't think any of them further restrict this.
  - osmarks 5y ago
    Even if it's technically possible to work around it, it would be a ridiculous amount of effort for not particularly good reasons.
pjmlp 5y ago
Termux folks need to accept Android main APIs are Java based and POSIX is not an official NDK API. https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Whatever cannot be done with ISO C and ISO C++ standard libraries, GL ES or Vulkan for the UI, needs to drop into JNI or Android IPC, period.
- NotPractical 5y ago
  I just want to be able to run Python scripts and whatnot on my phone; I don't care much about how it's implemented. I'm sure it's possible to have this without compromising security. As far as I know, the Android sandbox already provides pretty great protection against any programs running inside Termux, so there's not much reason to block exec()? It would at least be nice if they made W^X exec() into a permission (probably not toggleable from the Settings UI, perhaps only grantable through `adb shell pm grant`, if they want to make sure only powerusers can do this). For example, some poweruser apps like Tasker can be granted "WRITE_SECURE_SETTINGS" permission through adb to unlock more features. This permission is very powerful so it can't be granted through the Settings UI.
  - pjmlp 5y ago
    Using adb is a feature only in developer mode, plugged into SDK tools. You can enjoy PyDroid for the time being, https://play.google.com/store/apps/details?id=ru.iiec.pydroid3 https://play.google.com/store/apps/details?id=ru.iiec.pydroi... But it might not be around for long, https://www.theregister.com/2021/07/29/google_play_python_javascript/ https://www.theregister.com/2021/07/29/google_play_python_ja...
    - NotPractical 5y ago
      > Using adb is a feature only in developer mode, plugged into SDK tools. I'm aware. The difficulty in this process would act as a filter ensuring only powerusers can do it. It would certainly not be ideal to have to do this just to use Termux, but if Google wants to eventually enforce W^X exec(), it would be better than nothing. I'm honestly curious as to what the security implications of allowing exec() in writable directories really is. For example, GrapheneOS' top priority is security and it hardens the Android sandbox even beyond AOSP, and yet it still supports Termux (and I doubt its users would accept if it dropped support for this, even if in exchange for a little extra security). If anyone knows about this, I would appreciate your input.

by tjoff 5y ago

NotPractical 5y ago

Me too, haha. I like the new UI and privacy controls, but this is always the most important consideration. By the way, as far as I know, Termux (at least as we know it) is for sure eventually doomed, which is really sad. Here's a brief explanation for those uninitiated: * Android 10 introduced a restriction that apps targeting API version 29+ can no longer invoke exec() on files within the app's home directory, which breaks Termux [1]. * An app can target any API version. There is a hardcoded "min_supported_target_sdk" in the Android source code (23 as of Android 12) [2], but as of now targeting a lower version only produces a warning, and it will likely take quite a long time before it reaches 29 anyway [3]. The main problem is that the Play Store won't allow new app updates targeting <29. For now, the Play Store Termux build is very out of date and it's recommended to get Termux from F-Droid. But for some reason, the developer of Termux has decided that they want to make Termux API 29 compatible [4]. (Perhaps to ensure long-term compatibility if the "min_supported_target_sdk" ever increases past 28 AND starts to actually be enforced, or maybe just because they want to distribute Termux in the Play Store, even though most of its users would be perfectly comfortable getting it from F-Droid?) * Making Termux API 29 compatible will make it a lot less fun and a lot less practical to use. All executables will have to be distributed inside separate APK files which must be individually installed, since exec() can now only be called on files in the read-only /data/app directory [5]. Say goodbye to `apt install <name>`. * Google continues to further restrict the OS in ways that break certain functionality within Termux. * Termux still works mostly normally for now in Android 10 and 11 (and 12, it seems), but its developer is already at work on the weird APK packaging system. [1] https://github.com/termux/termux-packages/wiki/Termux-and-Android-10 https://github.com/termux/termux-packages/wiki/Termux-and-An... [2] https://android.googlesource.com/platform/prebuilts/fullsdk/platforms/android-31/+/refs/heads/master/build.prop#40 https://android.googlesource.com/platform/prebuilts/fullsdk/... [3] https://github.com/termux/termux-app/issues/1072#issuecomment-473965266 https://github.com/termux/termux-app/issues/1072#issuecommen... [4] https://github.com/termux/termux-app/issues/1072#issuecomment-755013204 https://github.com/termux/termux-app/issues/1072#issuecommen... [5] https://github.com/termux/termux-app/issues/1072#issuecomment-671910224 https://github.com/termux/termux-app/issues/1072#issuecommen... === EDIT === According to the README, the current plan is actually to continue targeting API 28 for now: > There is currently no work being done to solve android 10 issues and working updates will not be resumed on Google Play Store any time soon. We will continue targeting sdk 28 for now. They are looking for contributors to help make an API 29 compatible version though: > @termux is looking for Termux Application maintainers for implementing new features, fixing bugs and reviewing pull requests since the current one (@fornwall) is inactive. Issue https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/1072 needs extra attention. https://github.com/termux/termux-app/blob/master/README.md#google-play-store-deprecated https://github.com/termux/termux-app/blob/master/README.md#g...

pjmlp 5y ago
Good luck with that plan, https://developer.android.com/distribute/best-practices/develop/target-sdk#pre11 https://developer.android.com/distribute/best-practices/deve... > Starting in November 2021, app updates will be required to target API level 30 or above and adjust for behavioral changes in Android 11. Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Wear OS apps must continue to target API level 28 or higher. Android is not a POSIX OS, apis like exec() where never part of the public APIs, time to embrace the Java ways of the platform. https://developer.android.com/ndk/guides/stable_apis#c_library https://developer.android.com/ndk/guides/stable_apis#c_libra...
- NotPractical 5y ago
  This is Play Store policy, not Android policy. As I said, the Android OS currently doesn't enforce the minimum API level, and this probably won't become a problem for a long time, as long as you are distributing outside the Play Store (e.g. through F-Droid).
  - pjmlp 5y ago
    That isn't the Android version that most people get to use.
    - NotPractical 5y ago
      When I say "Android OS" here, I don't mean AOSP, I mean most (or all) manufacturer-customized Android ROMs, including Samsung, Pixel, etc. I don't think any of them further restrict this.
- osmarks 5y ago
  Even if it's technically possible to work around it, it would be a ridiculous amount of effort for not particularly good reasons.

pjmlp 5y ago

Termux folks need to accept Android main APIs are Java based and POSIX is not an official NDK API. https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Whatever cannot be done with ISO C and ISO C++ standard libraries, GL ES or Vulkan for the UI, needs to drop into JNI or Android IPC, period.

NotPractical 5y ago
I just want to be able to run Python scripts and whatnot on my phone; I don't care much about how it's implemented. I'm sure it's possible to have this without compromising security. As far as I know, the Android sandbox already provides pretty great protection against any programs running inside Termux, so there's not much reason to block exec()? It would at least be nice if they made W^X exec() into a permission (probably not toggleable from the Settings UI, perhaps only grantable through `adb shell pm grant`, if they want to make sure only powerusers can do this). For example, some poweruser apps like Tasker can be granted "WRITE_SECURE_SETTINGS" permission through adb to unlock more features. This permission is very powerful so it can't be granted through the Settings UI.
- pjmlp 5y ago
  Using adb is a feature only in developer mode, plugged into SDK tools. You can enjoy PyDroid for the time being, https://play.google.com/store/apps/details?id=ru.iiec.pydroid3 https://play.google.com/store/apps/details?id=ru.iiec.pydroi... But it might not be around for long, https://www.theregister.com/2021/07/29/google_play_python_javascript/ https://www.theregister.com/2021/07/29/google_play_python_ja...
  - NotPractical 5y ago
    > Using adb is a feature only in developer mode, plugged into SDK tools. I'm aware. The difficulty in this process would act as a filter ensuring only powerusers can do it. It would certainly not be ideal to have to do this just to use Termux, but if Google wants to eventually enforce W^X exec(), it would be better than nothing. I'm honestly curious as to what the security implications of allowing exec() in writable directories really is. For example, GrapheneOS' top priority is security and it hardens the Android sandbox even beyond AOSP, and yet it still supports Termux (and I doubt its users would accept if it dropped support for this, even if in exchange for a little extra security). If anyone knows about this, I would appreciate your input.