Ideas and todos

1. EMULATOR: enable a way to have the "sdk emulator" running

this is attempted in the emulator branch. Challenges comprise:

Xorg server must be forwarded (and other stuff like sound etc)
the emulator itself might need to have docker .... --device setup for /dev/kvm probably (and at that point it might be better to have it all run natively inside a VM anyways... (alternative would be nested virutalization)

2. BUILD and PACKAGENAME improvements

status quo: 2 Makefiles (gnu make) are involved,

a) one being the outer one that uses Makefile.apps as an include and then
b) an inner one located at ./apps/<app-name>/Makefile

the inner-one is not "parametrized" and at present has explicit nameing of the android app/ package (i.e. example.app), which comes with the additional negative that one has several files that need to be adjusted, this also being true because of the "fun that JAVA" naming conventions which basically means that the very least those files all have to be kept in sync

./apps/<app-name>/AndroidManifest.xml
./apps/<app-name>/Makefile
./apps/<app-name>/src/<package-name>/<activity-name>.java

goal: attempt to have the `<app-name>`, `<package-name>` and `<package-name>` be abstracted

Ideally make the inner Makefile superfluous

3. ALLOW KOTLIN

Since Java was apparently not "good/fancy" enough of maybe "bloated" the hippster did do what they like best re-invent to garnish personal "pride/achievement" and thus make a unhelpful thing (java) into now 2 unhelpful things (i.e. Kotlin and Java) super! However oftentimes now the undesired-yet-existing-kotlin is there and a goal could be to enable it being used. After all it appears to be a tiny bit less of a boilerplate annoyance...

4. ALLOW GRADLEBUILDS

GRADLE is often used as a building system for apps, it would be beneficial to have those build run also in this android-docker-app thing

1.9 KiB Raw Permalink Blame History