Closed AndroidDeveloperLB closed 4 years ago
That's right! However it's a conscious decision on my part to keep this a simple desktop command line program (with it being possible to easily port to android if necessary) - purely because I feel like I shouldn't be encouraging the use of this format and this is just a tool to convert these into a more standard open format that everyone else uses.
Please feel free to fork it into an android version if you really want to make a new APKMirror Installer app, but one exists already...
It doesn't have to be an APKMirror installer, and even if it will, it can be much better than what we have now.
Can I fork and make a pull request, and then you could just make a new module for PC ? Sadly I have no idea how to test on PC via Android Studio. I think something is wrong on my Java environment, as I couldn't even make a Hell-world PC app on IntelliJ, no matter how much time and effort I've put into it. I don't know why it is this way. Back in the Eclipse days, sure it was a bit complex, but I always succeeded making Java PC apps work fine.
Seems all the difference from making it running is:
which will be replaced to :
Perhaps you could make an interface for its usages, and wrap it from outside. According to the usage, the interface should have the functions
cryptoPwHash
,cryptoSecretStreamInitPull
, andcryptoSecretStreamPull
.So, there would be a main library module that has nothing that's related to
LazySodiumJava
and nothing that's related toLazySodiumAndroid
. Instead, it would use your own interfaceLazySodiumInterface
(or whatever name you wish, I'm bad with names), and there would be 2 tiny sample modules in the project. One for Java that provides the implementation viaLazySodiumJava
, and another for Android that provides the implementation viaLazySodiumAndroid
.If you want, a working sample on Android is attached here, with minimal change to the UnApkm file: ApkmTest.zip
If you do this, I suggest to also add annotations of
@WorkerThread
,@AnyThread
, and@UiThread
for the functions, based on the thread that it's supposed to run on. My guess is that all are on@WorkerThread