opened project in android studio to build it and got this error:

`Could not determine the dependencies of task ':app:mergeDebugAssets'.

Could not resolve all task dependencies for configuration ':app:debugRuntimeClasspath'. Could not resolve project :module-system. Required by: project :app > No matching configuration of project :module-system was found. The consumer was configured to find a runtime of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm' but: - None of the consumable configurations have attributes.

• Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

`

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.

I've been thinking of using the binary tools used in the build tools to be called directly using NDK so we don't need to store it in assets + extracting it (which literally doubles the storage usage), and this would allow us to not have pain with two "legacy" and "new method" execution methods.

I don't have a lot of knowledge in NDK / Native, so I might need to do some research

For some reason, aapt2 got stuck on linking and compiling big libraries like appcompat, material. It works fine on compiling smaller resources like the core library. The emulator I tested in on doesn't show a significant CPU usage after waiting for about 15 minutes, means that the device is not doing any work at all.

It might be a quirk of aapt2 in android. Compiling those libraries works fine on PC