Servo on Android doesn't terminate with the -x or -o flags

[rzambre]

On the laptop we can auto-terminate Servo after page-load using the -x or -o out.png flags.
I'm not observing the same behavior with Servo on Android. Is this expected?

How to terminate the Servo app after page-load on Android?

Might be related to #12303

[larsbergstrom]

Yes, I suspect that since all of the layout threads are panicing, we're unable to properly shut down and emit an output file.

[rzambre]

This problem still occurs even after the fix for #12303. It seems like Servo is trying to close down after the "Shutting down constellation..." message but is not able to communicate well with Android to do so without hanging up:

./mach run --android -w -p /sdcard/servo/out.tsv -o /sdcard/servo/out.png https://www.twitter.com

results in a blank screen (stalled) after getting the "Shutting down constellation.." message. Once I tap the screen, I get a thread panic. Here is the backtrace for that panic from ndk-gdb on the release version:

Thread 11 "m.mozilla.servo" hit Breakpoint 1, 0xdcedf218 in rust_panic ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
(gdb) bt
#0 0xdcedf218 in rust_panic ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#1 0xdceca1d8 in std::panicking::rust_panic_with_hook::h983af77c1a2e581b ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#2 0xdcf011b0 in std::panicking::begin_panic::he426e15a3766089a ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#3 0xdcecbff8 in std::panicking::begin_panic_fmt::hdddb415186c241e7 ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#4 0xdcf00fa8 in rust_begin_unwind ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#5 0xdcf4f8e4 in core::panicking::panic_fmt::hf4e16cb7f0d41a25 ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#6 0xdb40f1d0 in core::result::unwrap_failed::h17b9816f6848c2ea ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#7 0xdb40ef14 in android_glue::send_event::he323459323cb36a5 ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/loc---Type to continue, or q to quit---
al/armeabi/libmain.so
#8 0xdb415610 in android_glue::inputs_callback::h1dd173040d5c4a97 ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#9 0xdafbd448 in process_input ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#10 0xdaea59e4 in android_main ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#11 0xdafbd638 in android_app_entry ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/libmain.so
#12 0xf6fc2884 in __pthread_start(void*) ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/system/lib/libc.so
#13 0xf6f9cf76 in __start_thread ()
from /Users/rzambre/Documents/servo/servo-android/support/android/apk/obj/local/armeabi/system/lib/libc.so
#14 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[rzambre]

BTW, the out.png and out.tsv files are being generated on the device which tells me that Servo is shutting down internally but is not somehow not able to terminate its process on Android OS.

[larsbergstrom]

It occurs to me that one, possibly much cleaner, way to do this is to instead use android instrumentation/testing: https://developer.android.com/studio/test/command-line.html

So, the idea would be that we'd have another small java wrapper, say alongside this one:
https://github.com/servo/servo/tree/master/support/android/apk/src/com/mozilla/servo

And like that one, it would call in to servo with the proper arguments. The difference here is that instead of what we do today (where we are doing a "start" of the application, which assumes the full app and event lifecycle), the unit test framework assumes that we are just executing a portion of code in the app and then exiting. This might also reduce many of the bits of instability we're encountering around startup/shutdown/eventing!