Auto merge of #8288 - larsbergstrom:new_android_build, r=mbrubeck

New Android suppport

r/f? @mbrubeck

No need to r+ urgently; I want to do a little bit more testing of the release build, but I'm hoping to land this bit (moving to a more sane build process) next week.

The new version of building an APK:
1) Removes the glutin-based APK builder from the link step
2) Adds a build.rs step to the build of the final Servo library that adds the native code required by glutin's android_rs_glue (e.g., `ANativeActivity_onCreate` definition)
3) Replaces the link step with a `fake-ld.sh` script that instead creates a libservo.so
4) Adds a new mach `package` step to build the APK that has some Rust code that builds the library from a set of in-tree build files

This setup fixes a number of problems:
1) We can use gdb, because we use `ndk-build`, which adds the .gdbserver info, plus we keep around all of the build files (also required by the ndk gdb)
2) We can add more Java code & hooks to handle Android intents
3) We no longer have any git submodules or the awkward two-step build with android-rs-glue

Many other setups were tried (and failed). The most obvious ones is building a libservo.so from a `dylib` target from the servo build on Android. This doesn't work because you can't have a different default lib target on one platform than others in Cargo, and you also can't pass it in from the commandline (e.g., --lib does not have a dylib arg). Additionally, if you don't go through the intermediate libservo.rlib step (which removes unused symbols), then you end up with a TON of missing symbols because our -sys crates are super sloppy about that. I spent a few weeks beginning to clean them up, but since it's something we can't easily enforce (and new -sys packages will have this problem, too, since it's only an issue with the Android loader), it made more sense to me to just have the build set up to discard those unused bits of code before they ever get to the linker, much less the loader.

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8288)
<!-- Reviewable:end -->

components/servo/main.rs

@@ -23,6 +23,8 @@ extern crate android_glue;
 // The window backed by glutin
 extern crate glutin_app as app;
 extern crate env_logger;
+#[cfg(target_os = "android")]
+extern crate libc;
 #[macro_use]
 extern crate log;
 // The Servo engine
@@ -187,6 +189,16 @@ fn args() -> Vec<String> {
     env::args().collect()
 }
 
+
+// This extern definition ensures that the linker will not discard
+// the static native lib bits, which are brought in from the NDK libraries
+// we link in from build.rs.
+#[cfg(target_os = "android")]
+extern {
+    fn app_dummy() -> libc::c_void;
+}
+
+
 // This macro must be used at toplevel because it defines a nested
 // module, but macros can only accept identifiers - not paths -
 // preventing the expansion of this macro within the android module
@@ -209,6 +221,8 @@ mod android {
         //env::set_var("RUST_LOG", "servo,gfx,msg,util,layers,js,std,rt,extra");
         redirect_output(STDERR_FILENO);
         redirect_output(STDOUT_FILENO);
+
+        unsafe { super::app_dummy(); }
     }
 
     struct FilePtr(*mut self::libc::types::common::c95::FILE);