02-23-2016, 08:08 AM
(This post was last modified: 02-23-2016, 03:57 PM by Schwertspize.)
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-...ement.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...tions-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
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-...ement.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...tions-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