Add Android front end - #1763

Thank you @RainbowC0

This is very interesting. Porting to Android has been discussed many times during the years but (I guess) there was never an Android developer interested in implementing it.

I have a few questions:

• Is this a human implementation or was it prompted/vibe coded?
• Is using Java necessary? I know that it (and Kotlin?) is the main language on android, but I thought the SDK supported C++ only/native applications?
• If C++ only is possible is there an advantage to using some Java?

(Even though I've never developed for Android and have last written in Java in 2001) I'll go through the code later and add some specific comments (if I have any).

@RainbowC0 First off thanks! This look interesting. There is currently AFAICT no comparable CAD option available on Android (meaning native, local, 3D). But you dropped a review bomb on us so my initial response is probably going to be scattered.

This is going to take some time, but for starters is the image above the result of doing the tutorial on Android, or just showing that it can open a file? I ask because I don't see evidence of incorporating touchscreen gestures in the PR, so I'm not sure how you could even make that model without a mouse.

There are some invasive changes like #ifdef ANDROID in export.cpp and mouse.cpp

The GZIP stuff:
There are calls to LoadStringFromGzip replaced with LoadString scattered around but ALSO an #ifdef around that function in resource.cpp.

1. Why not use gzip?
2. If it can't be used, replace the function LoadStringFromGzip with an android specific function that strips the ".gz" in just one place. Or relocate the additon of ".gz" into the function and have that one line skipped for android. The goal here is to minimize platform specific #defines outside the /platform folder. I'm not sure there are any such defines today but I'm probably wrong.
3. The following change is completely unnecessary and should not have been mixed in with a big PR like this.

    if(SS.showToolbar) {
        if(ToolbarMouseDown((int)mx, (int)my)) return;

changed to:

    if(SS.showToolbar && ToolbarMouseDown((int)mx, (int)my)) {
        return;
    }

In solvespace.cpp
Why this change, which will likely affect something

                GW.window->SetTitle(saveFile.raw.substr(saveFile.raw.find_last_of("/\\") + 1));

                GW.window->SetTitle(saveFile.FileName());

Changes in toolbar.cpp
Is this change needed, or fixing a latent bug?

--    return withinToolbar;

++    return withinToolbar || toolbarPressed != Command::NONE;

Renaming hitCommand to commandHit was completely unnecessary.
Why the new distinction between toolbarHovered and toolbarPressed?
Why was ToolbarMouseup() function added? It's called at the end of MouseLeftUp() what is that all about?

Dependencies
Why not zlib? pixman? cairo?
By removing cairo I think you removed the ability to output .pdf files

My guess is that these are non-trivail to build for Android?

@ruevs should we push this to a branch? It's certainly not ready to be in master and I'd rather it get worked on on a branch rather than in a single PR.

@ruevs :

• Most of this is human implementation.
• Java is necessary, though it's okay to use pure C++ for Android development but that's mainly used in game development without system components. To access components in pure C++, we have to call java functions via JNI reflection, thus complicating the work.

@phkahler :

• LoadStringFromGzip is only used to load unifonts and threejs from resources. Due to the behaviour of AAPT (automatically unziping .gz files when packaging), I have to remove the .gz extension and use LoadFromString.
• It's okay to redefine LoadStringFromGzip as LoadString, but all calls to the function use a literal .gz extension, so if it's okay to remove the .gz extension from LoadStringFromGzip and define a macro to append the extension so that it compat the parameters for LoadString and the concating operation could be optimized when compiling as well?
• Android platform mainly uses touchscreen instead of mouse for input. If touching up, all hover states should be cleared.
• General behaviour of a gui button is to get triggered when mouse up and the target button not changed since mouse down rather than only mouse down. toolbarPressed is just for recording the down command. Especially on Android, if mouse down triggers it, a message box will appear instantly and intercept the following mouse events, making the received mouse events not completed.
• I use SAF to access files on android to avoid storage permissions needed, but the returned path is a url with content:// scheme, and the file path is all in percent-encoding. I've modified the Path::Filename for android to use %2F as separator to get the file name.
• I searched the project and found that cairo and pixman are only used for cli, and zlib is for LoadStringFromGzip. And this project generates pdf manually in bytes (in exportvector.cpp:845-)

fprintf(f,
"%%PDF-1.1\r\n"
"%%%c%c%c%c\r\n",
        0xe2, 0xe3, 0xcf, 0xd3);

    xref[1] = (uint32_t)ftell(f);
    fprintf(f,
"1 0 obj\r\n"
"  << /Type /Catalog\r\n"
"     /Outlines 2 0 R\r\n"
"     /Pages 3 0 R\r\n"
"  >>\r\n"
"endobj\r\n");

    xref[2] = (uint32_t)ftell(f);
    fprintf(f,
"2 0 obj\r\n"
"  << /Type /Outlines\r\n"
"     /Count 0\r\n"
"  >>\r\n"
"endobj\r\n");

This is still bugly when I test with mouse input and I have to fix severe bugs for merge.

@phkahler With the help of vibe coding, there are some 3d parametic cad apps on Android today and you can have a comparison:

• Digit 3D
• Materializer

This is the built apks for tests:

• app-arm64_v8a.zip
• app-x86_64.zip

And how about add a CI/CD workflow to build the apks?

My following plains:

• [short-term] Publish the Android port on F-Droid if no severe bugs.
• [long-term] More accessible touchscreen operations to select, move, scale and orbit. Android devices often recognize three-pointer sliding to capture screen, and the operation is also mapped to middle-button operation on the current version. This is also necessary on any other devices with touchscreen like Surface Go, Matebook and my Lenovo Yoga 14c. There's also news that Macbook Pro would support touchscreen this year. But till now solvespace has not support trackpad well enough (Trackpad gestures on Linux #1507, Support trackpad gestures #68)
• [long-term] Single window on both phone and tablet screens. I prefer a foldable bottom window for the text window on portrait phone screen and a right side window on landscape or large screen.
• [long-term] Fully asynchronous callbacks support. An Android's app process has a main ui looper to process input events and ui callbacks. If any events spans over 5s for foreground or 20s for background on main thread, Application No Response (ANR) would occur and cause crashes. I temporarily take over the main looper when waiting for result to achieve synchronous callbacks, however which is dangerous.

I rebased and made this PR into a branch on our main repository. At this time it's 7 commits ahead of master.

Shoud we close the PR or mark it documentation since it's got some todo stuff in the comments?

I would leave it open. This way if @RainbowC0 continues working on his branch we will be notified.