+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Discussion (https://forum.cuberite.org/forum-5.html)
+--- Thread: Android App (/thread-2381.html)
Pages:
1
2
Android App - Schwertspize - 02-23-2016
Hello everybody.
As I am trying to run Cuberite on my Android phone, I run into a few troubles unrelated to running Cuberite. For my troubles related to running Cuberite, see this thread basically from this post on.
(actually we assume not to require root access)
Firstly, how we handle read/write access.
By default, android has a directory called /sdcard (also referred to external storage). Although this directory is often not on an actual sdcard, it's always there and refers to the world writable storage all apps share (basically this means, that the user has access. Normally music, pictures and so on are saved there but also obb files or other stuff apps want to store). Currently I am not entirely sure if we can place and execute the Cuberite binary there.
Next possible location would be /data/data/<package name>/files which has the name internal storage. This refers to the storage which is only accessible for the app and neither public read or writable nor read/writable by the user (which would be a problem for plugins/config. Basically Cuberite is executable there but it seems to have problems with writing files if we use native binaries (not confirmed)
I would prefer placing the Server dir in /sdcard/cuberite (<- just an example) and keep the cuberite executables as well as the libraries in /data/data/<package name>/files just because 1. Execute public writable binary?!? Remember that thread about security 2. Running native code may be rather trivial, but running native Pre-built binaries is definitely not. Just to make sure the user can't kill us through replacing/modifying the binary.
Secondly, the part about code signing, app store and keys
I talked a bit with @sphinxc0re on IRC, but here are the things
1. We need to choose a package name. This is final, we want to prevent changing it under any circumstances. @sphinxc0re And me: org.cuberite.android
2. We need to have a key for the app. You need to sign your app, this makes sure updates can only come from you, etc. I thought about generating a keystore and a key with both random passwords and handing both to the core-team eg via PGP email. I could use my own yubikey but that would bind it to myself as person, I don't recommend that. Or we could buy am opengpg smartcard (PKCS#11)(someone else would have to sign the apk, the one in the core-team. If he leaves, he has to send the card via good old hard mail) (if we loose the key or it expires, we have to change package name and make user install the new app and so on. Very bad).
3. Play store. Needed is an email, this (https://play.google.com/about/developer-distribution-agreement.html) and 25$. Good would be a simple privacy policy stating that we don't collect any data. I would handle it the same was as the key (you set it up, maybe I or you upload the signed apk and handle it. ANYWAY, translations welcome
) Additional note to keys: if our key is secret that means data security for our users. No user can actually "hack" the app through downloading the source code, modifying it so it drops him a shell as that user and use the update, they would have to use another package name and hence get a separated "internal memory". Of course, if the user has root, but we don't talk about that.
Thirdly: Plugins, Configs and the other stuff
So, we basically have everything setup, how do users get plugins. Either we implement it together with the "normal" version in the webadmin, or we use our own way in the app. For webadmin part, I refer to this thread in general about plugins and updating them. If we want to use our own method, I would suggest using either JGit (https://git-scm.com/book/be/v2/Embedding-Git-in-your-Applications-JGit) or download a zip/tarball. Anyway we would have to provide a convenient way for users to do that, not relying on them to go into /sdcard/cuberite
Config would be in the same directory as the world's and plugins are, I would strongly recommend /sdcard hence that is the only location the user can modify without us implementing everything.
For further convince we may want to dig a bit into minecraft pe, apparently it saves it worlds to /sdcard/games/com.mojang/minecraftWorlds/ (source: http://gaming.stackexchange.com/a/227250). Creepy cool would be if we provide a way to import pe worlds just by tapping a button.
Appendix: a quick note on permissions
Basically, as we want to use the /sdcard we have to ask the user for permission for that, I think it will be at installation time but I will dig into that a bit deeper. A pop-up is the alternative (new version). However, the Internet permission cant be revoked, so as I understood it, we can always run the server if we use only internal storage, but another time, I don't recommend that. Anything other than that is not required I think. (I don't know if we need a permission for permanent notifications, I don't think so).
Edit: as always in the forum, opinion welcome
RE: Android App - NiLSPACE - 02-23-2016
When @xoft's HTTP parser is merged I'd be willing to create a plugin that downloads plugins. There is a problem though, I can't unzip downloaded .zip files easily in Lua. I think there is a way to fix this in general by using the Github API instead to download every file individually. That way I don't have to unzip anything.
RE: Android App - Schwertspize - 02-24-2016
@NiLSPACE whats with luagit? That way you have compression too, even got an updating system via git and no problems.
RE: Android App - NiLSPACE - 02-24-2016
I'm trying to use as less libraries as possible. Otherwise if a platform doesn't support the library it would mean you couldn't use the plugin.
RE: Android App - Schwertspize - 02-24-2016
Of course, but I thought it was just a bunch of code without dependencies
RE: Android App - xoft - 02-24-2016
We basically have ZIP support in Cuberite already, the zlib library should be able to handle the compression, we just need to add some housekeeping around it. Not sure how much work it would be, or whether we should add a 3rd party lib to Cuberite itself to handle that.
RE: Android App - Schwertspize - 02-28-2016
@bearbin @xoft ( @Mathias ?) any other opinions? This is pretty important -.-
RE: Android App - tigerw - 02-29-2016
Perhaps you could consider working on https://github.com/cuberite/cuberite/pull/2526 . It already has all the work done and runs without root. Tycho was just complaining about some minor details.
RE: Android App - Schwertspize - 02-29-2016
Firstly, that is partially the wrong thread. Anyway, I already looked at the android dir in the code. But if you look in the other thread (what we are doing I think) I already stated why I don't want to do it like this. Basically it would mean that we tie cuberite and the app together (which is not good). Although I said above "Running native code may be rather trivial, but running native Pre-built binaries is definitely not." I know that integrating cuberite into an android app with the usage of the NDK is almost impossible (if not much too much work). What you have done is only the tip of the iceberg. Additionally said that we would have the normal issues regarding deployment if we tie app and cuberite together (we can't deploy them seperated from each other). Besides, if you look at what I wrote in the other thread, "runs without root" doesn't matter here because what I found out root is not related to using a processbuilder and a process.
RE: Android App - tigerw - 03-01-2016
The referenced pull request is intended to place the Android files in a separate repository, where they compile the main source through submodule.
I think Google doesn't allow apps to update themselves outside of the Store; see this document (§"Dangerous Products", subsection 4).