Есть ли компилятор для Андроид в бинарный код?
Как я понял Java компилируются в байт-код, который потом кушает JVM.
Немного не так. В основе процесса приложения лежит не JVM, а Dalvik. Ни на что не смотря, резкие отличия от JVM есть.
Только Dalvik уже отжил свое, английская статья в вики повествует о так называемом Android Runtime (ART), который присутствует в Android начиная с версии 4.4, а с 5.0 и вовсе вытеснил Dalvik. Подробнее о принципах работы ART можно почитать снова в английской вики. Только не стоит думать что ELF может содержать исключительно и только инструкции для реальных процессоров. ELF - это просто контейнер исполняемого кода.
Теперь обратимся к коду.
https://android.googlesource.com/platform/art/+/ma...
Это код утилиты dex2oat, которая и производит преобразование из DEX в ELF. 
https://android.googlesource.com/platform/art/+/ma...
Вот тут есть некоторые пояснения самих данных и принципов их хранения в ELF формате.
Это всё не говорит о том, что после обработки DEX в ELF будут храниться исключительно инструкции реального процессора. Это все говорит только о том, что в ELF формате хранится уже подготовленный и оптимизированный код, не требующий докомпиляции и оптимизации во время своего запуска.
Так и зачем смущаться этого всего? Разницы мало, для виртуального там процессора инструкции или для реального. Все уже оптимально собрано.
Идем дальше.
https://android.googlesource.com/platform/art/+/ma...
Это описание главной функции процесса приложения.
https://android.googlesource.com/platform/art/+/ma...
Вот тут Dalvik создается безусловно, т.е. от него никуда не деться. Вот точное место.
Далее, касательно пресловутой Native activity.
https://github.com/android/platform_frameworks_bas...
Это исходный код NativeActivity, который зашит внутри стандартной библиотеки Android.
https://github.com/android/platform_frameworks_bas...
Чтобы NativeActivity смогла загрузить свой низкий уровень, в AndroidManifest.xml нужно описать мету вот с этим именем и именем .so файла в качестве значения.
https://github.com/android/platform_frameworks_bas...
Вот тут производится загрузка низкого уровня. Как видно, это делается из метода onCreate самой NativeActivity. То есть, это самое начало жизненного цикла Activity.spoilerУ NativeActivity есть много очень неприятных ограничений и очень неудобный интерфейс. Из за этого я еще в 2011 году для используемого в производстве игр движка был вынужден разработать альтернативу NativeActivity и некоторую обертку над JNI для увеличения удобства разработки.
Иными словами, непосредственно для Android нельзя создать пользовательское приложение без задействования кода высокого уровня.
NDK что-то дает, но далеко не все, буквально мелочи. Как только тебе понадобится обратиться к телефонной книжке, узнать громкость звука уведомлений или состояние беззвучности, как-либо опросить окружение устройства, тебе придется писать код на Java.
NDK не является инструментом разработки приложений. NDK - это средство реализации только критичных к производительности участков программы.Хочу начать разрабатывать моб. приложения, кроссплатформерность не интересует. Гонюсь за быстродействием.
Не спеши гнаться за быстродействием, по всей видимости тебе и C++, как инструмент разработки, не нужен, т.к. вообще не ясно для чего и зачем ты решил его использовать.
Инструменты выбирают исходя из целей. Цели пока не обозначены. Быстродействие не может быть целью, т.к. это только условие достижения лишь некоторых целей.
Во многих случаях в мобильной разработке максимальное быстродействие дает именно использование основного предлагаемого языка программирования. Лично я предлагаю тебе сперва уделить 5-6 месяцев (но лучше год и более) ежедневному чтению документаций, книг и исходного кода как открытых проектов, так и репозиториев разработчиков мобильных платформ.
В качестве эпилога.
https://developer.android.com/ndk/guides/index.htmlThe NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps.
Android NDK. Под него собираются нативные модули (на С/С++) к приложению, которые вызываются из Java приложения через JNI. 
Фактически любое приложение на Android не может быть без Java.
И в первую очередь все зависит о типа приложения
Например, это 3D игра - там нужно быстродействие (тем более без вмешательства сборщика мусора), и особо не нужны штуки из SDK (но к ним все равно можно обратиться). Для этого почти все можно сделать на NDK стороне
А если обычное приложение со списками, кнопками,.., то все это должно делаться на Java, и только отдельные ресурсоемкие части выносить на NDK, иначе процесс разработки может надолго затянуться, что просто бессмысленно при увеличении производительности на 10% (ну пускай там списки будут быстрее формироваться и рендериться) и увеличенном в разы времени на разработку
Замечания:
Java не интерпретируемый, так как компилируется в байт-код при сборке.