Main Issue

[iyxan23]

I forgot to post this issue on github, but this is the current main problem that stops me from continuing blokkok. I prefer to just stop early rather than doing work that'll become worthless in the future since this is a quite of a big project of me and TheClashFruit. If anybody could propose a great working solution that follows with the current module system, I'll happily consider continuing this.

Main problem: In android 10< you can't run binaries that are inside the app's private storage or simply "external binaries" (binaries that are downloaded or binaries that doesn't come with the app itself), this restricts blokkok modules from shipping their own binaries.

Current Ideas we have sorted by favor-ability:

• By using a wasm to run "native programs"
  Pro: No need any changes to the current module system, it will fit to a module without any internal changes

  Cons:

  • There isn't any wasm-compiled aapt2 or zipalign, I will need to port them myself, and I have no idea how to do it
  • Is slower than native

• Use hidden android apps (apps that doesn't show in launchers) instead of plain JARs as blokkok modules
  Modules can then access include binaries inside them and android will allow them to use them. Also, communication will be done using broadcasts.

  Credit: Hemanth & Jbk0

  Pro: Can't figure out any pros :(

  Cons:

  • Much more resource heavy
  • Will need a complete overhaul of the module system
  • More hoops for the user to delete a module (finding the hidden app in settings and uninstalling it)

• Blokkok will ship its own binaries (what we're currently doing)
  Binaries like aapt2 and zipalign will be shipped in blokkok by default

  Pro: Very straightforward and simple

  Con: Breaks the modular principle of blokkok, modules couldn't add or update the binaries and users will have to update the app to update the binaries (will be better if binaries were packaged inside a module)

• Lower down the target API to android 10>
  Allows us to bypass the restriction. This has been suggested by many people to me, but all I can say is that this is not a good idea for blokkok in long-term. The problem with this approach is that minimum API levels will always rise, and when it got past android 9 or 10, blokkok will just die. This does not solve the issue, but rather just delaying it.

• Virtualization
  Yeah, virtualizing a Linux distro to run binaries..

  Credit: Tarochino

  Pro: Binaries can run flawlessly

  Con: VERY Resource heavy

If anyone has any new and interesting approaches or have any pros/cons you want to add to this list, please comment on this issue.

[PranavPurwar]

: (

[TheClashFruit]

conclusion: remove modules

[iyxan23]

conclusion: remove modules

then there is no point in making blokkok, just use codeassist if you don't care about modularity, it has better and serious features

[TheClashFruit]

eh, ain't blokkok was going to have a scratch like editor, codeassits is just a code editor (with auto complete)...

[iyxan23]

eh, ain't blokkok was going to have a scratch like editor, codeassits is just a code editor (with auto complete)...

still, modularity is the main selling point of blokkok. I'd prefer making a separate app for that or just use sketchware pro

[lahds16]

well, the end?

[iyxan23]

I would say so

[Zestski]

I wanted this project to continue but there's just no way to solve it, as there is no intention to add binary embedded in the application (inbuilt, I mean: jniLibs etc), so sad to see this :/

But guys, do you intend to publish that app on Google Play? I know it's stupid idea but why not set the targetSdk to 28?

[ryenyuku]

@Hakalle It's already in point 4, I already suggested @iyxan23 to decrease the targetSdk just like what the people in Termux did while they're finding a better solution but he refuses to do it with that reason. Currently @TheClashFruit is making a different IDE (@WoidIDE) because he said he can't maintain current project codes (which is mostly written by @iyxan23 while the former is actually the owner of this project too lol)

[JavkhlanK]

Google Play wants apps to have a targetSdk of Android versions newer than Android 9. You can't publish an app targeting Android 9 anymore, not even updates. That's also why Termux from Google Play was discontinued - no updates were and still are possible.

[ryenyuku]

Well that's also one of the reason, but publishing Blokkok to Play Store wasn't our best intention (since none of us have a GPlay Dev account)

[ryenyuku]

Well that's also one of the reason, but publishing Blokkok to Play Store wasn't our best intention (since none of us have a GPlay Dev account)

[iyxan23]

I felt like I've already sent a comment long time ago before all this lol. welp here it is:

I wanted this project to continue but there's just no way to solve it, as there is no intention to add binary embedded in the application (inbuilt, I mean: jniLibs etc), so sad to see this :/

But guys, do you intend to publish that app on Google Play? I know it's stupid idea but why not set the targetSdk to 28?

I never really had the intention of publishing blokkok to the google play store because they tend to not like apps that could dynamically load external code (which is the entire selling point of blokkok). They also have a policy in place that states:

"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)."

From here microsoft/react-native-code-push#1364 (comment), I can't find the exact source

Lowering down the targetSdk works, sure, but it doesn't fix the issue. It's just delaying it from the inevitable future of minSdk getting to android 9+.