Android support

[marcprux]

This PR adds the minor changed needed to build and run on Android, as well as adds a CI that uses swift-android-action to run the test cases.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.99%. Comparing base (604df92) to head (c3318d7).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #75   +/-   ##
=======================================
  Coverage   83.99%   83.99%           
=======================================
  Files          82       82           
  Lines        7322     7322           
=======================================
  Hits         6150     6150           
  Misses       1172     1172           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[swhitty]

Thank you @marcprux 🙏

Glad that it actually compiled on Android quite easily. Current Linux support is limited to parsing SVGs no rendering yet — If we were to add Rendering to Android which API would you recommend — Canvas maybe?

I haven't really used skip.tools yet but am excited to try it out and see its potential.

[marcprux]

The Canvas API would probably the best way to go, since it most closely matches CoreGraphics, but it does require JNI bridging from native code out to the Java SDK. This is an area we are currently working on, so we hope to have some nice solution for drawing that doesn't require a lot of manual JNI binding creation.

Another alternative could be to use a purely native method like the NDK's ANativeWindow to draw on a surface without the overhead of JNI bridging, but that is limit to just sending an array of pixels over to the surface, so you would wind up needing to re-create a CoreGraphics-style API yourself, which wouldn't be fun.