Евгений Шатунов

Самым простым решением для разработки именно игры будет взять Cocos2d-x, Defold или Godot.
Это уже готовые решения для разработки игр на различные платформы, в том числе и на Android.
Все движки предоставляют инструменты именно для С++, в отличие от SDL.

SDL выполнен на языке C и не является подходящим в контексте разработки на C++.

Если есть желание заняться именно разработкой движка, а не игры, то вместо SDL стоит взять SFML, который выполнен уже на C++ и является довольно хорошим фреймворком. На базе SFML можно довольно быстро сделать небольшой движок для небольшой игры.

C++ не является полноценно "родным" языком для Android. Но для этой платформы можно вести разработку на C++.
Такие движки, как cocos2d-x [?], Urho 3D [?], Unreal Engine 4 [?], Godot Engine [?] и, буквально, море менее известных проектов, позволяют вести разработку игр с использованием языка C++.

Для старта своего проекта тебе потребуется среда разработки, рабочая и исходная части выбранного тобой движка и море времени чтобы читать необходимую литературу, без которой у тебя мало что получится. Требования к среде разработки у каждого движка разные, поэтому сперва стоит выбрать движок.

Если использование C++ для тебя является важным, о Unity можно забыть. Это взаимоисключающие инструменты.
И это не важно. Тот же Urho 3D позиционируется как Open Source Unity. Godot Engine обладает не меньшей свободой и гибкостью, но предлагает больше.

class rck{
public:
    unsigned short x,y;
    void show();
    int tm=0;
    uint8_t type=0;
};

У тебя объявлен, вроде бы, агрегатный тип с неявным конструктором по умолчанию, в котором выполняется инициализация только полей tm и type.

rock.push_back({(uint16_t)(x*64),(uint16_t)(y*64),0,0});

Тут перед обращением к push_back формируется фиктивный std::initializer_list<uint16_t> с двумя элементами внутри.
В общем смысле, до полного списка аргументов нужно указать еще два аргумента. Тогда эту запись можно будет считать агрегатной инициализацией временного объекта типа rck.

Такая форма агрегатной инициализации стандартизирована в C++11. До C++14 агрегатная инициализация отключается для типов, в которых присутствует инициализация полей по месту объявления (в коде это поля tm и type). Каждый следующий стандарт требования к агрегатной инициализации только ужесточает.

GCC давно славится своей слабой поддержкой стандарта языка. Это означает что если код проходит трансляцию g++, это далеко не факт что он соответствует стандарту.
NDK сегодня для сборки использует clang, который на данный момент считается максимально приближенным к стандарту транслятором.

Все это должно дать понять что данный код не соответствует стандарту языка и не должен компилироваться. Подходящего конструктора от двух аргументов для типа rck не определено и тип не является агрегатным.
То, что g++ смог собрать этот код, останется на совести g++.
Еще одним важным моментом будет точное понимание, какой именно стандарт языка выбран для трансляции твоего кода.

Через NDK доступна функция mkdir[?].
Ее поведение для Android ни чем не отличается от изложенного в официальной документации.

Для проверки существования папки можно использовать функцию stat[?], а можно опереться на код ошибки EEXIST из mkdir.

Как я понял 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.


Иными словами, непосредственно для Android нельзя создать пользовательское приложение без задействования кода высокого уровня.

NDK что-то дает, но далеко не все, буквально мелочи. Как только тебе понадобится обратиться к телефонной книжке, узнать громкость звука уведомлений или состояние беззвучности, как-либо опросить окружение устройства, тебе придется писать код на Java.
NDK не является инструментом разработки приложений. NDK - это средство реализации только критичных к производительности участков программы.

Хочу начать разрабатывать моб. приложения, кроссплатформерность не интересует. Гонюсь за быстродействием.

Не спеши гнаться за быстродействием, по всей видимости тебе и C++, как инструмент разработки, не нужен, т.к. вообще не ясно для чего и зачем ты решил его использовать.
Инструменты выбирают исходя из целей. Цели пока не обозначены. Быстродействие не может быть целью, т.к. это только условие достижения лишь некоторых целей.
Во многих случаях в мобильной разработке максимальное быстродействие дает именно использование основного предлагаемого языка программирования. Лично я предлагаю тебе сперва уделить 5-6 месяцев (но лучше год и более) ежедневному чтению документаций, книг и исходного кода как открытых проектов, так и репозиториев разработчиков мобильных платформ.

В качестве эпилога.
https://developer.android.com/ndk/guides/index.html

The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps.

cannot find -llz

Память мне подсказывает что не "-llz", а "-lz". :)

Версии Android API обратно совместимы в определенных пределах. Это буквально означает что можно собрать приложение для Android 4.4.2 (targetSdkVersion == 19) используя Android API с версией 22 (compileSdkVersion == 22). При этом, на твои руки полностью ложится ответственность за предотвращение вызовов новых функций из Android 5.1.1 на более древних платформах. Иначе приложение упадет, автозатычек ни кто не предоставляет.
Поэтому, да, можно пользоваться свежими версиями Android API для сборки под старые версии ОС Android.

Относительно предупреждений о разных версиях, у тебя compileSdkVersion указана строго, а вот пакет "com.android.support" имеет гибкую зависимость на повышение версии. Скорее всего ты уже закачал свежие API для Android 5/6, из которых теперь и берется пакет "com.android.support" при сборке.

Не стоит путать трансляцию, интерпретацию и компиляцию. Постановка вопроса неточна в целом.

Java является транслируемым языком, а не интерпретируемым. Трансляция идет в опкод Java LLVM (в обычном случае) или в опкод Dalvik LLVM (в случае сборки для Android). После трансляции, исполняемый DEX (Dalvik Executable) файл содержит предварительный (сырой) байткод. Это уже не текст, который надо интерпретировать, это уже код операционных команд виртуальной машины низкого уровня. В момент запуска на конкретном устройстве, DEX файл дополнительно обрабатывается (всего один раз, при запуске приложения): из него удаляются элементы совместимости, блоки типа "if( value )", где value - это "final bool == false" (и много еще чего); после чего подается на обработку процессору LLVM.

Поэтому можно не беспокоиться о медленности интерпретации Java кода, т.к. интерпретации нет. Возможно меня даже анафеме предадут за то, что я яву назвал транслируемым, а не компилируемым языком. :)
Больше обо всем этом можно узнать в документации по Sun Java Machine и в документации Android Dalvik Machine.

Однако, возвращаясь к вопросу о компилируемых языках. Сам язык, как моя практика показывает, значения тут не имеет. Любой язык может стать как транслируемым, так и компилируемым или интерпретируемым. Для разработки на Android существует уже много инструментов с поддержкой множества самых разных языком. Кое-кто и python использует в качестве языка разработки проектов.
Существует так называемая связка поддержки низкого уровня. В нее входят средства компиляции языков в команды непосредственно процессор(а|ов). Для Android этим целям служат языки C и C++.
И, раз уж в вопросе делается акцент на максимальное быстродействие программы, можно предположить что именно этот момент интересен больше всего.

Native Development Kit - NDK - позволяет создавать низкоуровневые модули для последующего подключения их в основной код проекта (написанный обычно на Java). Во времена ранних версий (1.6-2.0-2.2) андроида, команда разработчиков рекомендовала минимизировать объем низкоуровневого кода и опираться только на средства Java.
Однако, со временем стало понятно что низкоуровневый код пользуется большой популярностью и функциональность NDK стала увеличиваться. С каких-то пор стало и вовсе возможно создавать исключительно C/C++ приложения без кода на яве, только это тот еще геморрой.
Использовать C/C++ для разработки на андроид не сложнее использования оных в разработке для других ОС, но ровно до момента, когда надо пообщаться со стороной на яве. Для налаживания общения между C/C++ и Java кодом в NDK имеется интерфейс JNI. С JNI проще всего познакомиться на сайте Oracle, в разделах документации к Java.