>it dynamically downloads the programs using apt-get.

And then runs them as the Termux app. I didn't mean to imply that it put all of the apps into itself at build time.

>Android app for each binary is difficult to work with.

You could group multiple binaries that belong to a single conceptual app into a single android app. What do you think would make it difficult to work with? I think most of it could be automated away.

▲

zozbot234 a day ago | parent [-]

The principled way of doing this (while coping with the new post-Pie restrictions) would be to build a new "updated" .apk on-device with a new /usr/bin/ equivalent, then have the user explicitly "install" it and relaunch Termux. It would work no different than any live-CD install, or for that matter any other kind of "immutable" OS.

▲

jraph a day ago | parent | next [-]

But then, everything runs under the same Termux user app again, just with extra cumbersome steps. And I'm not sure it's possible to do this safely, you need the APK to be signed, and the only way to do this would be to share the private key. And likely to have a good chunk of the Android SDK bundled with Termux. A version that runs on Android anyway.

Not sure it would fly with Google's Play Store policies.

to your parent:

> And then runs them as the Termux app. I didn't mean to imply that it put all of the apps into itself at build time.

ok, got you

	▲	zozbot234 a day ago \| parent [-]
		Yes but you could just have a custom private key that's generated by a separate "apk builder" app and stored on-device.

▲

a day ago | parent | prev [-]

[deleted]