Revisit the Android W^X problem

[iamahuman]

Feature description Termux should circumvent Play Store policy of restricting execution of arbitrary code from third parties, by imitating what Google Chrome does. Bundling packages into APKs is certainly not the way to go.

1. Consult Firefox and Chrome as to how it executes external code (e.g. JavaScript) while still managing to comply with Play Store policy.
2. Run user code in a sandbox (isolated_app?), emulating forbidden system calls as needed. (Note that we already do this with execve to handle #!/usr/bin/... shebangs).
   • Additional permissions to control system can be granted through some kind of broker, which user code can communicate to via IPC.
   • Don't rely exclusively on ptrace through; rather, approach the problem with a mix of ptrace+seccomp+recompilation.
3. Circumvent W^X restriction by using a custom binary loader (instead of e.g. /system/bin/linker).

Reference implementation

N/A

Related

• 655

• 1072

[iamahuman]

On the one hand, we need to think about how we can still give the sandboxed code access to storage files. /storage is implemented via FUSE (filesystem in userspace), so perhaps we can just steal some hints from there.

On the other hand, we can use this opportunity to explore support for containers and containerized applications (e.g. Docker, Flatpak, ...), possibly after figuring out how to resolve complications made by the SE Android policies.

[Grimler91]

Termux should circumvent Play Store policy of restricting execution of arbitrary code

We would definitely risk being suddenly removed from play store if we try to circumvent the policy, but as you said I guess it is theoretically possible to comply in the same way as browsers with javascript.

I think what we need is some people to feel strong enough about this "issue" to actually develop and experiment with possible solutions. The apk route has been shown to be possible, but needs much more work.

Alternative ideas are great, but an idea is not really worth anything before it is implemented (as business people like to say). Leaving the issue open for discussion, but please understand that basically only xeffyr and fornwall has looked into android-11 support so far, and I doubt they would take the lead to implement new ideas now that we have a proof-of-concept of the apk solution.

[RalfWerner]

Bundling packages into APKs is certainly not the way to go.

Yes and No! I studied the use of a boot loops concept and made good experiences. pkg will be preserved but the *.apk will be individualized/customized. Thus, target=29+ and sdcard access are no more problems.

[suhan-paradkar]

I agree with @iamahuman .. @xeffyr If we just use proot to solve this, it may become easier.. but it has its own problems...

1- This is a known fact- performance issues...

2- Usual termux users love the fact that these packages are run directly under the android system.. That's why most users ask for packages natively that adjust without them with proot The presence of proot would render having no difference between termux's packages and other proot distros

3- Any bugs or issues with proot upstream would also be an issue with Termux....

4- The Build script would have to be modified.. I don't know to what extent....

The best approach, I think would be to modify termux-exec, which currently is a wrapper only for shebangs around execv(). This would mean more work.. but has its benefits... This would mean that termux-exec, after modification, would be included with termux-app, like the bootstrap packages.. but would be executed by the app , which then executes these packages....

[ghost]

@suhan-paradkar We have only 3 variants of resolving the issue:

1. Leaving everything as-is and continuting with SDK 28.
2. Packaging everything as "native libs" of APK. - Look branch android-10.
3. Using a custom ELF loader: proot or something else.
4. System emulation.

Variant 1 is current one, 3 - against Play Store policy.

This would mean that termux-exec, after modification, would be included with termux-app, like the bootstrap packages.. but would be executed by the app , which then executes these packages....

To do so you need to inject a LD_PRELOAD into Dalvik/ART startup. This is not possible and therefore you can't use shared library approach. It also works on function level and not the system call - will cause troubles with non-C/C++ programs.

You need a program which takes ELF executable, load its sections into memory and passes execution flow. A bare variant of proot. ptrace() there would be required anyway, to be able handle execve calls recursively.

[ghost]

The Build script would have to be modified.. I don't know to what extent....

What is that build script? It won't be hard to make Termux app build proot and bundle into APK.

If you are talking about package scripts, then there no issues at all. It even possible to get rid of most of our packages with proot, they won't be needed in case of use of normal distribution.

---

IMO, impact on user experience is inevitable. You can't keep quality, functionality, performance or application store availability on high level at same time. Even now this isn't possible, not saying about what will be after fixing execve issue. Solution shouldn't bring more problems than fixing. If there is something that can fix more Termux issues than just execve, you should consider it instead.

[RalfWerner]

2. Packaging everything as "native libs" of APK. - Look branch android-10.
3. Using a custom ELF loader: proot or something else. - against Play Store policy.

@xeffyr I've a question: Is the existence of proot in the termux.apk (bootstrap*) already a violation of the Play Store Directive? The insert would only be done/used after the package update/install TERMUX_ANDROID10 or when proot-distro is used and Google should not be interested. In my bootloop concept, the extension of the elf-splits (not everything) is also outside the control of Google. And the app version update does not change to $PREFIX.

What is that build script? It won't be hard to make Termux app build proot and bundle into APK.

Agree! My current build script support also: "1. Leaving everything as-is and continuting with SDK 28."

[ghost]

Is the existence of proot in the termux.apk (bootstrap*) already a violation of the Play Store Directive?

https://support.google.com/googleplay/android-developer/answer/9888379:

An app distributed via Google Play may not modify, replace, or update itself using any method other than
Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so
files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual
machine and has limited access to Android APIs (such as JavaScript in a webview or browser). 

Proot by itself doesn't violate anything. But it lets application to continue violate policy through downloadable packages. Yes, Termux already violates the policy and it doesn't matter whether proot is added or not. It still exists in Play Store, but there are risks.

[RalfWerner]

Yes, Termux already violates the policy

OK - very juristic formulation. Thus, play store as a distributor no longer suitable for a developing app like termux, when Google does not change that. In the bootloop, after the first version are always local dev-*.apk used. For 29+, only the question of whether this level has advantages over 28, on which one should not do without?

[ghost]

The only "advantage" is being able to submit updates to Play Store. Not so many. Termux works on Android 11 and even on 12 beta. That's expected, because Android currently preserves backwards compatibility. Problems will be only if with specific update Google decides to drop it.

[StarkZhidian]

It's there any possibility to change target sdk version value at run time?

[agnostic-apollo]

It's there any possibility to change target sdk version value at run time?

No, that's stored in AndroidManifest.xml and used as is since install time by android. Changing it would require rebuilding and reinstalling APK. However, apt and apk system should be selectable at install time if designed right.

[xloem]

These solutions wouldn't have to overall reduce usability: for example, if binaries could be installed to sdcard storage, that would be a huge plus elsewhere.

[Vixeliz]

Sorry for the dumb question but with the packaging everything into the apk does that mean it is no longer possible for users to compile and run programs? That would be unfortunate.

[ghost]

@Vixeliz PRoot can be used to workaround that but:

a. Any custom executable loader is technically against Play Store app publishing policy. - Matters only if we decide to continue Play Store updates. b. PRoot does modifications to program execution flow, adds performance penalty and not stable on some devices. c. It is unknown how exactly this (Android W^X) issue is going to be solved: we may choose a different solution, use other executable loader or not use it at all.

[Vixeliz]

@xeffyr I see, if you were to try and get back on play store is it feasable to have two versions one with proot and one without? My main use case for termux is developing applications and im very worried it won't be possible going forward.

[ghost]

@xeffyr I see, if you were to try and get back on play store is it feasable to have two versions one with proot and one without? My main use case for termux is developing applications and im very worried it won't be possible going forward.

I don't think 2 termux versions with and without proot would be a good idea. because it needs to maintain one for non-proot-ed termux app for target level 29 (assuming in-APK's for example) and for proot-ed termux app it also needs to maintain existing package implementation which is apt and would probably need much maintenance so preferably one choice is a choice

[Vixeliz]

I see well personally i am crossing my fingers for proot then.

[RalfWerner]

In the android-10 branch, proot is part of the bootstrap (W^X violation) and all executables (ELF) outside the Termux-APK (with n=~/../../lib) are usable through the loader (TERMUX_ANDROID10) with the losses described above. Disadvantage of the branch is, that the well-known pkg administration was abolished and everything is in APK. I've studied an alternative that is based on the ELF transfer/split from $PREFIX to $n. This advances an APK build with variable bootstrap (loop) but pkg would stay as it is.

The more ELF in $n are, the more effective Termux works with API>28. I suspect PlayStore would not refuse the installation and many of the discord kids would never notice any difference as they work with proot-distro. A bigger problem is the withdrawal of @fornwall (currently has other priorities), which was the only one to do/able the PlayStore updates. So it would have to be found a person with the necessary knowledge and time that can replace him or he returns.

[iamahuman]

I suppose withdrawing from Play Store has one big problem: funding.

[ghost]

Play Store is a just one of ways for funding and no one of maintainers except Fornwall shares it (both account & funding) anyway.

While Termux can dance for follow its policies for app publishing, there no guarantees that they would not be more strict in future. Relying on it for publishing in-APK bundled packages potentially creates a point of failure that is beyond our control: every submitted apk goes through moderation, there could be delays and chance that apk will be rejected for (un)known reason. This creates a possibility that something may become broken as publishing of specific dependency version failed.

[Manu99it]

As an user, I think the best approach is the current one: don't use play store for publishing the app. Other ways to overcome this issue seem to have too many disadvantages and in future Google could tighten PS policies even more. There are already too much problems caused by wrong choices made by Google on Android done on the assumption that users are stupid, or for the sake of privacy and security (when instead those should be in a compromise with usability and comfort). You get two advantages by don't publishing the app to PS:

• app is used mainly by who wants really use it and at least is ok with learning HOW to do it, so you potentially get less management problems on GitHub, reviews, already reported issues, etc
• you don't need to refactor the app in a way that may be frustrating for established users, at least until android isn't going to drop backwards compatibility

[falhumai96]

Feature description Termux should circumvent Play Store policy of restricting execution of arbitrary code from third parties, by imitating what Google Chrome does. Bundling packages into APKs is certainly not the way to go.

1. Consult Firefox and Chrome as to how it executes external code (e.g. JavaScript) while still managing to comply with Play Store policy.

2. Run user code in a sandbox (isolated_app?), emulating forbidden system calls as needed. (Note that we already do this with execve to handle #!/usr/bin/... shebangs).

   • Additional permissions to control system can be granted through some kind of broker, which user code can communicate to via IPC.
   • Don't rely exclusively on ptrace through; rather, approach the problem with a mix of ptrace+seccomp+recompilation.
3. Circumvent W^X restriction by using a custom binary loader (instead of e.g. /system/bin/linker).

Reference implementation

N/A

Related

• Play Store now forbids downloading executable code #655
• No more exec from data folder on targetAPI >= Android Q #1072

In regards to the first point, Google and Mozilla use JIT to run custom code in Chrome and Firefox, respectively, so that the emulated code is as fast as native code. That is why also Chrome and Firefox in iOS are basically Safari clones, because iOS apps are restricted from using JIT unless it is through Apple's WebKit (at least not until recently when Apple allowed using JIT through their sandbox in iOS 14.4 I think). I thought about this problem, and I believe a way to circumvent the current Termux issue, which is addressed in the first point by @iamahuman, is that we can use a software like QEMU static to emulate same CPU binaries on execution restricted drives such as /sdcard and now /data/data, on the cost of slow startup to binaries. At the very least, on long running binaries, it would be as fast as native combined applications since QEMU static (assuming it is compiled without using interpretation only) use JIT as well.

[erwin]

Android's Write/Execute restriction is just intolerable. Same for unconditionally denying apps to read/write access to common locations... These our OUR DEVICES.

For me, Termux was a huge part of what made Android an actually tolerable platform, as opposed to the iOS Digital Prison. Now, Android is almost as bad as iOS when I threw away my iPhone 3GS and got a Samsung S III...

But where do we go from here?

Can we get back control by migrating to something like LineageOS or one of the other custom Android distributions?

Is Android bearable if we just focus on rooting and ignoring Google's irritating policies?

Besides rooting or installing a different distro, is there something else we can do?

Or is it game over for Termux and we need to move to something like Purism to actually re-assert control over my own device?

[Vixeliz]

While I agree these problems are annoying I don't see any reason why android should be considered as bad as ios. And personally I still don't see much to rooting. Technically apps can still do what they did before for termux and the w^x issue the solution is being in some sort of container or virtualization or something yes this is slower but to be fair on our mobile devices w^x could be a security concern. As for file locations I'm assuming you mean scoped storage. If that's the case that's up to the apps to implement things like document providers if they use their own data directory for their files or in the case of file managers there is still the MANAGE_EXTERNAL_STORAGE permission. I have a feeling as long as chromebooks exist and consumers care about sideloading android won't be restricted to the point of not still being able to be used as a computer.

(Sorry for formatting I'm on mobile currently and not as my samsung dex setup)

[erwin]

I agree these problems are annoying

That's exactly the beginning and the end of it.

Why do we have these devices? If the device you OWN is annoying, why waste our money on it?

What other choices do we have or what can we hack together?

be fair on our mobile devices w^x could be a security concern

That's exactly the point. If I know what software I'm running. It's my responsibility.

I don't see any reason why android should be considered as bad as ios

I'm saying that Android in 2022 is about as awful as iOS already was by 2012...

sort of container or virtualization or something yes this is slower but to be fair on our mobile devices

I want to use my terminal to control and script my device.

My feeling is that the Android trajectory is becoming clear. Maybe I'm wrong, but it seems' like their plan is to make an idiot proof OS, yet there will always be new idiots. I would like to figure out how to get out ahead of it, instead of finding out what else I CAN'T DO with my phone each an update is force installed.

Maybe another Termux user already has a solution.

I don't think just accept it is a solution.

[Vixeliz]

I don't know how to respond to each problem on mobile however I'll number.

1) their aren't many other choices for some people with devices that can't be rooted or even if they can may be missing features

2) you are correct you can choose which software to run via apks however if an app could just install any executable without you knowing and run it that would be a problem which is what w^x prevents. So instead you are forced to run that code in a sandbox which in my opinion makes sense. They aren't preventing people from running what they want apks can still be installed without limitations

3) it is no where near as bad we have so much more customizablity even without rooting. We can sideload apps which is huge compared to ios. For example I develop android applications on my phone with no problem.

4) you should still be able to do that even if they use something like proot. And I don't think the trajectory is clear you have to remember google is working on built in desktop mode for android and they have chromebooks. I want to give Google the benefit of the doubt and say they are making these changes for legitimate security concerns which in my mind isn't an issue cause as of rn they aren't limiting what apps can do. I cannot personally think of an app that would cease to work with these changes as long as the devs worked to figure out a solution. Termux is a great example of that point. In fact UserLand is using the latest api level which is based off of termux and let's you run Linux distros.

[ghost]

At the very least, on long running binaries, it would be as fast as native combined applications since QEMU static (assuming it is compiled without using interpretation only) use JIT as well.

It won't be same fast. QEMU with jit is 10-20 times slower than host. Without JIT up to 50 times. QEMU package with JIT enabled is available in Termux. You can try running some OSes (system-mode) or binaries (user-mode).

QEMU "static" mode simply do not exist.

Android's Write/Execute restriction is just intolerable. Same for unconditionally denying apps to read/write access to common locations... These our OUR DEVICES.

For me, Termux was a huge part of what made Android an actually tolerable platform, as opposed to the iOS Digital Prison. Now, Android is almost as bad as iOS when I threw away my iPhone 3GS and got a Samsung S III...

Is Android bearable if we just focus on rooting and ignoring Google's irritating policies?

Could we stop discussions from being going political and be productive on the solution, right @erwin ? Reminding about locked #1072.

Android is not your product. If you disagree with OS developer decisions, start your own project. No one restricts you from running Linux software, just follow the f*cking development guidelines and avoid use of legacy/undocumented interfaces, your app will be ok in long term.

---

Current summary on the available solutions:

• Bundling native executables inside the APK. - Good, but has impact on user experience from package management side.
• Using proot for running executables, leaving everything else same. - Possible issues with Play Store policy. On user side there is performance and stability impact.
• Custom executable loader. - This solution could be better than proot from performance & stability side. Though it needs some effort from our side to develop suitable ELF loader not depending on execve, if we won't use proot code base.
• QEMU system mode. - Great possibilities (it would be separate OS with own kernel), but significant impact on user experience due to performance issues. This will also turn Termux into system emulator rather than terminal emulator for Android OS.
• QEMU user mode. - In theory can be used as custom executable loader. On practice it is unknown how it would work as it seem to require working execve(). If it would work, issues same as proot. Doesn't support emulation of certain system calls.
• Recompiling binaries to WASM. - Won'tfix.

[ghost]

In fact UserLand is using the latest api level which is based off of termux and let's you run Linux distros.

Is that variant is published on Play Store? I don't use UserLAnd, but if it really passed Play Store moderation with proot, then Termux can do same.

[Vixeliz]

@xeffyr yes they are on the Google play store using proot and the api level was either 30 or 31 I don't recall exactly.

[ghost]

Yes. UserLAnd uses latest API and still on Google Play. but i don't know if the app will stay in Google Play indefinitely. last update of an app was probably October 2021

[Vixeliz]

I have a quick question if termux ends up going the built in packages route would nodejs still work(assuming it was included) since it is an interpreter?

[agnostic-apollo]

I have a quick question if termux ends up going the built in packages route would nodejs still work(assuming it was included) since it is an interpreter?

Assuming interpreter shells like bash, python and node are included in the apk, users would have to run bash script.sh, python script.py and node script.js. Direct execution like ./script.sh will not work.

[ilyapashuk]

solution with in apk embedding is very inconvenient. a lot of apks in moderated play store, may be late updates, no dependency management, no user's own code and package file customization. termux will lose a lot of it's power. and play store admins will be able to block individual apps. they may forbid to have hundreds of apks.

this is the only solution which is not a hack, but it is really ugly!

termux is already not updating in play store, and it is alive despite of this. is it really nesasery to present in play store?

[Grimler91]

solution with in apk embedding is very inconvenient.

Agreed.

a lot of apks in moderated play store, may be late updates, no dependency management

Dependency management might be solveable. Late updates is not really a unique problem to the apk solution.

no user's own code and package file customization.

Stay on ~android 10 apps from fdroid if apk solution for google play doesn't fit your needs

and play store admins will be able to block individual apps. they may forbid to have hundreds of apks.

We'll probably go for bundles containing multiple packages instead of one apk per package.

termux is already not updating in play store, and it is alive despite of this. is it really nesasery to present in play store?

Not everyone can install apps from fdroid and similar, for example people using a company phone. And who knows, maybe from android 13 or 14 (or 15 or ..) termux as packaged for fdroid might not work at all. Having a working apk-solution would decrease the implication of that

Probably we will maintain both an android 7 - 9 app (at fdroid) and an android >= 10 app at google play for quite some time, if we ever get a somewhat working apk-based solution.

[ghost]

Probably we will maintain both an android 7 - 9 app (at fdroid) and an android >= 10 app at google play for quite some time, if we ever get a somewhat working apk-based solution.

That would mean more maintenance having a separate branches for pre and post-android q versions of Termux app. maybe we should stick the current solution right now at the moment, as long as it still works, who knows how far Termux would continue to work properly on newer android releases ¯\_(ツ)_/¯

[Grimler91]

That would mean more maintenance having a separate branches for pre and post-android q versions of Termux app

Yes, for sure.

maybe we should stick the current solution right now at the moment

Yeah, I think so too, but would be cool to have a small proof-of-concept app that mostly works, containing a (very) limited set of packages. It could then be released through github

[RalfWerner]

Yeah, I think so too, but would be cool to have a small proof-of-concept app that mostly work ...

I would like that too! My (init) TargetSDK>=29 version contains p="proot aapt android-tools" and of course pkg. Thus, all subsequently installed packets can also be performed without bootloop at least with proot.

In the current Termux, is alias s='find $PREFIX -type f|wc -l' 3017 is after bootstrap+pkg up and with pkg in $p the result of s is 3318 on an Android-12 AVD (x86_64). So a basic-universal-TargetSDK=32 version would not be much larger than the current.

Addendum: to aapt and android-tools in $p and ELF-check

aapt (for APK analysis) is corrected agaib and android-tools I use only because of a bug in pm . If @agnostic-apollo has solved this as announced via env, only proot is necessary. The numbers above must be corrected with bootstrap *02.13-r1 and with s/ with $p/du -hd 0 ../usr are: 6588/6645/173M and *-r4 are: 3315/3322/88M .

ELF-Split/Check is based on an idea of ​​@xeffyr, but the @fornwall did not take over in its branches. In my bootloop this action takes place in Termux (u ec) to $PREFIX, requires the package zip (3335/89M) and after the bootstrap action is only one additional symlink: ln -s $PREFIX/nl $(realpath $nl) with nl=~/../../lib. Examle (u is an alias to script):

[~]$ s;u ec usr
3335
SYMLINKS.txt (2) check (update/##) start ...
finish with 0 old nl of 1099 ELF check start ...
327,1426 in 482 usr/(bin lib libex*)
update nl and libnl ...
-rwxr-xr-x 1 26M Jan  1  1981 /data/data/com.termux/lib/libtermux-bootstrap.so
-rw------- 1 37M Feb 14 15:13 bootstrap-x86_64.zip

Here (check) 327 files (47M) are identified, which would have to be included in SDK>28 in $nl. With parameter usr, this could be used to created boot*.zip for the next loop build (here init loop - needed 15 sec). If TargetSDK=28 continue to be used, libnl can continue to stay in $PREFIX and the build needs 1-3 minutes depending on the PC power and number of arch. The entire process Inclusive installation can be done by script.

The debian package policy is quite complex and not designed for bundling files in APKs .. (next commit @agnostic-apollo)

I think you're right, but this is not relevant in boot-loop see small example of it below

[agnostic-apollo]

That would mean more maintenance having a separate branches for pre and post-android q versions of Termux app.

There is no need for separate branches or even releases (other than optionally different targetSdkVersion for F-Droid and Play Store). If designed right, it can be managed in the same app/branch. User can be asked at install time for the method they want to use. Bootstrap/package installation is just a module for termux-app. Users on android 10+ who are rooted can also use legacy method if selinux policy is patched to disable exec restrictions. No need to force all android 10+ users to apk design.

https://github.com/termux/termux-app/issues/2445#issuecomment-985484952

And apk design itself has issues for replicating apk updates and I am not really in support for it either, other than singular app without package updates for termux forks.

The debian package policy is quite complex and not designed for bundling files in APKs and symlinking them. Maintainer scripts (postinst, preinst, etc) are used by tonne of packages and they may fail with symlinks, considering simple checks like test -f will fail. So packages may need to be continuously manually reviewed by maintainers which is not really possible with the amount of maintainers we have. Package source code may not be expecting symlinks either, so those may need to be reviewed too, with patches added. Conffiles (like sshd_config) is another thing handled while installing with apt with a keep maintainer version or local version prompt. That will also have to be replicated in android app source code somehow. Other config files exist in deb too. There are likely other issues as well, in addition to the ones already mentioned above. As far as I know, mass testing of apk design with random packages has not been done either by anyone, so there are likely issues that we are not seeing yet. Replicating apt which has been developed over multiple decades in an android app is bound to have problems, if at all possible easily, specially with time constraints for maintainers. Even the current updated-flavor branch requires lot of work, its not doing everything correctly, although understandable, since its a POC.

Keep buying devices that can be bootloader unlocked/rooted would be my recommendations for power users who want to remain safe from future android restrictions. Android 12 already broke termux (#2366) and user friendly and safe fix won't be available to users until Android 12L or 13, if their devices even gets the update. Who knows what changes are made in future and if they would even be solvable without root by termux or not, especially in regards to how android is going hard against background execution since last few versions. APK packaging and other solutions won't solve such restrictions.

[ilyapashuk]

the problem globally may be solved by the following way: add an other flag to disable this restriction to the manifest specification. this flag may require special play store moderation. the most apps will be restricted but some apps may be allowed.

why not ask about this on the official android resources?

it is very unlikely that it will be satisfied but why don't try?

[falhumai96]

a-Shell on iOS is been accepted on the Appstore: https://holzschu.github.io/a-Shell_iOS/, and for running custom binaries, the clang toolchain that comes with it compiles to web assembly and JIT run it using WASM3. I personally believe that for termux to be back on the store and have an efficient solution, while still maintaining the usability of the original termux, is to create a JIT launcher for custom binaries like JVM for Java classes, for instance, or WASM3, so it runs in near native speed. Just my two cents. Bundling executables, while allowing for running at full speed, it will be a huge inconvenience for the user to have to install APKs so they can run their binaries.

[Vixeliz]

a-Shell on iOS is been accepted on the Appstore: https://holzschu.github.io/a-Shell_iOS/, and for running custom binaries, the clang toolchain that comes with it compiles to web assembly and JIT run it using WASM3. I personally believe that for termux to be back on the store and have an efficient solution, while still maintaining the usability of the original termux, is to create a JIT launcher for custom binaries like JVM for Java classes, for instance, or WASM3, so it runs in near native speed. Just my two cents. Bundling executables, while allowing for running at full speed, it will be a huge inconvenience for the user to have to install APKs so they can run their binaries.

That's interesting, to me it seems more future proof then proot but we will see the tradeoffs for maintenance and such between the options proposed so far. But honestly personally I would love to see wasm used I feel like it honestly might be a really good solution but that's just my two cents.

[falhumai96]

a-Shell on iOS is been accepted on the Appstore: https://holzschu.github.io/a-Shell_iOS/, and for running custom binaries, the clang toolchain that comes with it compiles to web assembly and JIT run it using WASM3. I personally believe that for termux to be back on the store and have an efficient solution, while still maintaining the usability of the original termux, is to create a JIT launcher for custom binaries like JVM for Java classes, for instance, or WASM3, so it runs in near native speed. Just my two cents. Bundling executables, while allowing for running at full speed, it will be a huge inconvenience for the user to have to install APKs so they can run their binaries.

That's interesting, to me it seems more future proof then proot but we will see the tradeoffs for maintenance and such between the options proposed so far. But honestly personally I would love to see wasm used I feel like it honestly might be a really good solution but that's just my two cents.

Yes, WASM is th future. If Apple allows such app to be on the Appstore, I highly doubt Google is stricter than Apple, if not otherwise, and therefore we can ship Termux that comes bundled with wasm launcher.

[RalfWerner]

There is no need for separate branches ... APK packaging and won't solve such other solutions restrictions.

@agnostic-apollo With everything I agree here, except with other solutions and:

As far as I know, mass testing of apk design with random packages has not been done either by anyone

I have successfully managed with my boot-loop method package collections of almost 100T files ($PREFIX>2Gb) and ELF-split in APK. Since you do not want to support the build with local bootstraps in master, I've put aside the investigations some time ago - there is currently no need.

[leap0x7b]

That is why also Chrome and Firefox in iOS are basically Safari clones, because iOS apps are restricted from using JIT unless it is through Apple's WebKit (at least not until recently when Apple allowed using JIT through their sandbox in iOS 14.4 I think).

@falhumai96 This is how iSH managed to get through App Store. It doesn't use direct unsigned code execution, which Apple also doesn't allow, instead it emulates x86 usermode and syscalls, and it emulates it with a unique way:

It's not actually a JIT since it doesn't target machine code. Instead it generates an array of pointers to functions called gadgets, and each gadget ends with a tailcall to the next function; like the threaded code technique used by some Forth interpreters. The result is a speedup of roughly 3-5x compared to pure emulation. — iSH GitHub Readme

This emulation makes it both as fast as JIT and able to be accepted to App Store.

[leap0x7b]

Since Google doesn't really disallow JIT (their Chrome app themselves use JIT), maybe we can use iSH's approach, but with actual JIT (or maybe even AOT)

[agnostic-apollo]

Seems to have required lot of changes to the handful of packages it supplies, at least for ios. Termux provides 1000s of packages, would require tonne of patches.

https://github.com/holzschu/ios_system

We have the limitations of WebAssembly: no sockets, no forks, no interactive user input (piping input from other commands with command | wasm program.wasm works fine).

https://github.com/holzschu/a-Shell#programming--add-more-commands

make sure your code doesn't use commands that don't work in a sandbox: fork, exec, system, popen, isExecutableFileAtPath, access... (some of these fail at compile time, others fail silently at run time).

https://github.com/holzschu/ios_system/#adding-more-commands

Not sure how something like that would be usable for any reasonable termux or terminal usage.

p.s I don't have any experience with WASM.

[falhumai96]

You know what, UserLAnd app is currently working on supporting Android 10 and above using PRoot inside lib folder: https://github.com/CypherpunkArmory/UserLAnd/issues/827. It is also currently in available in PlayStore with the update, and Google did not pull it out because of the PRoot support (I reckon Termux won't be pulled out too with PRoot support). I am with continuing further to PRoot, since PRoot internally is just a JIT using QEMU user mode, without too much penalty on performance.

Another slight suggestion is to merge the Termux project with UserLAnd, and make Termux Just an alternative shell inside UserLAnd, since really Termux will be just another shell running inside PRoot, but this one on another app (that's if Termux don't merge with UserLAnd). This is just my opinion.

[falhumai96]

You know what, UserLAnd app is currently working on supporting Android 10 and above using PRoot inside lib folder: CypherpunkArmory/UserLAnd#827. It is also currently in available in PlayStore with the update, and Google did not pull it out because of the PRoot support (I reckon Termux won't be pulled out too with PRoot support). I am with continuing further to PRoot, since PRoot internally is just a JIT using QEMU user mode, without too much penalty on performance.

Another slight suggestion is to merge the Termux project with UserLAnd, and make Termux Just an alternative shell inside UserLAnd, since really Termux will be just another shell running inside PRoot, but this one on another app (that's if Termux don't merge with UserLAnd). This is just my opinion.

The update to Android Q wasn't as smooth on UserLAnd's side. Reading/writing data from/to /sdcard is now a bit more inconvenient. This is the message you get when you run the app:

[RalfWerner]

Example continued of a "boot loop": In March 2021 I made the last ELF check on my SM-P610 (315 EFL files), in between several pkg * actions made and have currently 38549/1.4GB for $PREFIX. If I repeat now u ec, remain unchanged from the ELF files 58 (e.g., zip, Xwayland). The boot*.zip at 540MB would have to incorporate as the minimum version above in the build of the next version. If the package set for all arch would be used the APK>2GB and even with a single arch are the installed data before the Init bootstrap action (2x*.zip) from Termux>1GB and after >2.5GB. with a correspondingly long installation duration. I would prefer another process where prefix is ​​preserved if it still exists and only nl->libnl is replaced, that's only 203MB. If then the currently double storage of these boot data would be reduced to one, TERMUX would need less storage than now.

When I first met Termux (v0.73) it took about 200KB. Bootstrap was made like pkg via the servers, and has been predominantly installed by the Play Store. As far as storage efficiency is concerned, you should take this as a _model. Even the last Play Store version (v0.101) contains bootstrap only once and only thedevice arch. That's before/after bootstrap 19/82MB. The opposite is the current (v0.118) minimum requires 216MB at Universal (all arch) and currently only 5MB more in the bootstrap.