Вышел CrystaX NDK 10.2.0

Но программировать бизнес-логику в 21м веке на не-managed языке, да еще настолько кривом как Кресты?

Проект скоро добавит поддержку D - будет счастье

libcurl, openssl, zlib, Boost (только filesystem, остальное либо хедер-онли, либо pre-c++11, либо просто не нужно), minizip - нормально собираются через standalone toolchain, они есть на staticlibs.net например.

pcre, pcre++ - не нужно же, осиль ICU, она вроде даже прилагалась к crystax.

tinyxml - осиль libxml, он есть подо все платформы.

jsoncpp - jansson же, также всюду есть, а вообще json парсеров как грязи.

glog - log4cplus же, и под андроид и под iOS и под офтоп собирается, правда не 2.0 ветка, но для логирования без разницы.

gumbo, gumbo-query - а вот это было бы хорошо иметь, libtidy умер и без него плохо.

А что на С можно под андроид разрабатывать? Игоря?

Все более-менее ресурсоемкое, далвик тормозить меньше не стал даже с переходом на AOT при установке, ну и плюс софт и игорян как правило кроссплатформа с иос\консолей то есть код там уже имеющийся на сях/плюсах и на жабу никто переписывать ради одной платформы не будет.

нафиг вообще нужен C++?

вопрос не в нужности/ненужности C++, вопрос в том, на каком языке писать, чтобы не переписывать большую часть кода (ядро программы) под соответствующую платформу.

Кстати, эпики в 4 UDK (который вроде как высокоуровневое средство разработки игоряна где о сексе с байтами на куче платформ уже позаботились за тебя) убрали скриптинг и оставили только или мышкой лапшу в блюпринте рисовать или на жутких плюсах писать с макрокостылями в стиле windows MFC.

pcre, pcre++ - не нужно же, осиль ICU,

Ну тогда уж std::regex, но мне лень переписывать. К тому же, pcre это общепризнанный стандарт, а про icu regexp я первый раз слышу.

std::regex сломан совсем в GCC < 4.9. Не у всех 5.1 есть, я вот под 4.7 пишу, где С++11 уже почти весь. А ICU вообще недооцененная библиотека, она на 99% девайсов есть, но напрямую редко используется - слишком низко в системе находится. А pcre скорее всего тоже собирается, но я не пробовал. Google re2 вот хорошо собирается, но под оффтопиком не работает.

Objective-C - очень даже хороший, нативный, по-настоящему объектно-ориентированный язык. Сначала отпугивает, но потом понимаешь, что он лучше, проще и удобнее, чем C++.

Только синтаксис у него чуть лучше чем у брэйнфака.

GTA'шечку и Angry Birds на Java не напишешь.

Игоря не нужны :-)

нафиг вообще нужен C++

Чтобы быть примером того, как делать не нужно.

Ну, icu мне все равно пригодится, буду юзать для конвертирования из одной кодировки в другую. К тому же boost::locale, если не ошибаюсь, использует icu.

Игоря не нужны :-)

деньги нужны. раз быдло платит за игори, значит мне они нужны.

То, что по ссылке вообще не соберется, т.к. не указан -std=c++11. Непонятно, каким компилятором собирали и на каком девайсе тестили, например, без указанного APP_PLATFORM я на своем Nexus 6 получаю «error: only position independent executables (PIE) are supported.».

Надо собирать так:

/opt/android/android-ndk-r10e/ndk-build APP_CXXFLAGS="-std=c++11" APP_PIE=true

Это тест из CrystaX NDK test suite, и там он собирается как есть, т.к. "-std=c++11" в CrystaX NDK используется по умолчанию (если не указан иной -std в Android.mk/Application.mk), а APP_PIE указывается всегда.

Запускал на нескольких устройствах (Nexus 4, Nexus 5, Galaxy Nexus), на разных версиях Android, а также на эмуляторах - падает везде:

$ /opt/android/android-ndk-r10e/ndk-build APP_CXXFLAGS="-std=c++11" APP_PIE=true NDK_TOOLCHAIN_VERSION=4.9 APP_ABI=armeabi-v7a
[armeabi-v7a] Compile++ thumb: test_std_atomic_crash_gnustl_shared <= main.cc
[armeabi-v7a] Prebuilt       : libgnustl_shared.so <= <NDK>/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/thumb/
[armeabi-v7a] Executable     : test_std_atomic_crash_gnustl_shared
[armeabi-v7a] Install        : test_std_atomic_crash_gnustl_shared => libs/armeabi-v7a/test_std_atomic_crash_gnustl_shared
[armeabi-v7a] Compile++ thumb: test_std_atomic_crash_gnustl_static <= main.cc
[armeabi-v7a] Executable     : test_std_atomic_crash_gnustl_static
[armeabi-v7a] Install        : test_std_atomic_crash_gnustl_static => libs/armeabi-v7a/test_std_atomic_crash_gnustl_static
[armeabi-v7a] Install        : libgnustl_shared.so => libs/armeabi-v7a/libgnustl_shared.so

$ adb push libs/armeabi-v7a/libgnustl_shared.so /data/local/tmp
5723 KB/s (661132 bytes in 0.112s)

$ adb push libs/armeabi-v7a/test_std_atomic_crash_gnustl_shared /data/local/tmp
1365 KB/s (13528 bytes in 0.009s)

$ adb shell chmod 0700 /data/local/tmp/test_std_atomic_crash_gnustl_shared

$ adb shell 'cd /data/local/tmp && LD_LIBRARY_PATH=/data/local/tmp ./test_std_atomic_crash_gnustl_shared'
...Thread updates:  [  0 31400467] [  1 11590037] count=42989904
...Thread updates:  [  0 27667818] [  1 14052332] count=84710672
...Thread updates:  [  0 26219285] [  1 13127565] count=124057727
...Thread updates:  [  0 32164180] [  1 11050922] count=167272977
...Thread updates:  [  0 32324380] [  1 10889657] count=210487159
...Thread updates:  [  0 27458638] [  1 15698704] count=253644496
...Aborted

Если же собрать с помощью CrystaX NDK - не падает:

$ /opt/android/crystax-ndk-10.2.0/ndk-build APP_PIE=true APP_ABI=armeabi-v7a
[armeabi-v7a] Compile++ thumb: test_std_atomic_crash_gnustl_shared <= main.cc
[armeabi-v7a] Prebuilt       : libgnustl_shared.so <= <NDK>/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/thumb/
[armeabi-v7a] Executable     : test_std_atomic_crash_gnustl_shared
[armeabi-v7a] Install        : libcrystax.so => libs/armeabi-v7a/libcrystax.so
[armeabi-v7a] Install        : test_std_atomic_crash_gnustl_shared => libs/armeabi-v7a/test_std_atomic_crash_gnustl_shared
[armeabi-v7a] Compile++ thumb: test_std_atomic_crash_gnustl_static <= main.cc
[armeabi-v7a] Executable     : test_std_atomic_crash_gnustl_static
[armeabi-v7a] Install        : test_std_atomic_crash_gnustl_static => libs/armeabi-v7a/test_std_atomic_crash_gnustl_static
[armeabi-v7a] Install        : libgnustl_shared.so => libs/armeabi-v7a/libgnustl_shared.so

$ adb push libs/armeabi-v7a/libcrystax.so /data/local/tmp
4477 KB/s (524860 bytes in 0.114s)

$ adb push libs/armeabi-v7a/libgnustl_shared.so /data/local/tmp
4931 KB/s (718448 bytes in 0.142s)

$ adb push libs/armeabi-v7a/test_std_atomic_crash_gnustl_shared /data/local/tmp
1460 KB/s (13528 bytes in 0.009s)

$ adb shell chmod 0700 /data/local/tmp/test_std_atomic_crash_gnustl_shared

$ adb shell 'cd /data/local/tmp && LD_LIBRARY_PATH=/data/local/tmp ./test_std_atomic_crash_gnustl_shared'
...Thread updates:  [  0 31074010] [  1 11977970] count=43051388
...Thread updates:  [  0 31989607] [  1 11232311] count=86274740
...Thread updates:  [  0 31958174] [  1 11264912] count=129497903
...Thread updates:  [  0 31925250] [  1 22562687] count=172721021
...Thread updates:  [  0 31874601] [  1 11346483] count=215942167
...Thread updates:  [  0 31924740] [  1 11296935] count=259163962
...Thread updates:  [  0 31420660] [  1 10103222] count=300687858
...Thread updates:  [  0 30017190] [  1 12083068] count=342788170
...Thread updates:  [  0 8943010] [  1 34241969] count=385973283
...Thread updates:  [  0 9299359] [  1 33301218] count=428573808
...Thread updates:  [  0 8821626] [  1 34363837] count=471759415
...Thread updates:  [  0 8788842] [  1 34394898] count=514943166
...Thread updates:  [  0 17703683] [  1 34271316] count=558129357
...Thread updates:  [  0 8761165] [  1 34422291] count=601312746
...Thread updates:  [  0 8798569] [  1 34384296] count=644495738
...Thread updates:  [  0 8767654] [  1 34416615] count=687680057
...Thread updates:  [  0 8743480] [  1 34440648] count=730864227
...Thread updates:  [  0 8923895] [  1 68699470] count=774046929
...Thread updates:  [  0 8850504] [  1 34330603] count=817228050
...Stopping threads
Final: 860420000

btw, почему CrystaX?

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

Пока что я не знаю смысла, и это название ассоциируется с Христом, что внушает огромное отторжение (ненавижу религиозный бред).

Смысла в слове «CrystaX» нет никакого, это просто достаточно уникальное слово, которое легко запоминается и легко гуглится.

А чего не libjpeg-turbo ?

Ее тоже добавим: https://tracker.crystax.net/issues/986

Запускал на нескольких устройствах (Nexus 4, Nexus 5, Galaxy Nexus), на разных версиях Android, а также на эмуляторах - падает везде

Что-то вы неправильно готовите. А какой APP_PLATFORM? У вас он явно не указан. Подозреваю, что в нем проблема. Я указал 22, на моем Nexus 6 (5.1.1) все ок:

...Thread updates:  [  0 11580096] [  1 30627801] count=42206318
...Thread updates:  [  0 10225091] [  1 30820165] count=83253520
...Thread updates:  [  0 24039544] [  1 14735296] count=122029277
...Thread updates:  [  0 19079579] [  1 16683139] count=157791823
...Thread updates:  [  0 16438998] [  1 16167811] count=190398991
...Thread updates:  [  0 25207228] [  1 1459471] count=217065836
...Thread updates:  [  0 24926240] [  1 321490] count=242313416
...Thread updates:  [  0 31798137] [  1 17523742] count=266709359
...Thread updates:  [  0 8179176] [  1 16931362] count=291819849
...Thread updates:  [  0 11399153] [  1 31966680] count=318254286
...Thread updates:  [  0 17242637] [  1 48245203] count=351775502
...Thread updates:  [  0 15780041] [  1 20296863] count=387852588
...Thread updates:  [  0 11124975] [  1 27868347] count=426846112
...Thread updates:  [  0 10830300] [  1 25231844] count=462908292
...Thread updates:  [  0 25611952] [  1 18988951] count=496679140
...Thread updates:  [  0 652791] [  1 45073948] count=523416944
...Thread updates:  [  0 3184781] [  1 67038113] count=548565642
...Thread updates:  [  0 1699798] [  1 25424851] count=575691031
...Thread updates:  [  0 25999442] [  1 8218898] count=609909154
...Stopping threads
Final: 646310000

Скачать его как предлагаешь? И куда?

А какой APP_PLATFORM?

Поставьте 15 и проверьте, надо же не только последнюю версию поддерживать :) если будет работать - тогда круть

сваяет нечто похожее на Visual Studio. :)

VS2015 уже поддерживает сборку и отладку под андроид, и даже собственный эмулятор. пока что в зачаточном состоянии, но активно пилят.

Так только кажется. Логично же:

id something = [object somethingByReplacingSomething:arg0 withSomething:arg1];

в возможности быстро писать код

зависит от того что кодить, и кто кодит.

Что-то вы неправильно готовите. А какой APP_PLATFORM?

APP_PLATFORM по умолчанию. У гугловского r10e это android-3. У нас это android-9. Если при сборке гугловским NDK указать APP_PLATFORM=android-9, все равно падает. С APP_PLATFORM=android-21 не проверял.

Мы собираем специально с android-9, чтобы убедиться, что все, собранное под старшие версии, работает и на более новых. Более того, это вообще наша фича - мы делаем так, чтоб код работал одинаково на всех поддерживаемых версиях Android, а для этого надо собирать с минимальным API level (в нашем случае это 9, т.е. Android 2.3).

Кресты - это единственный нативный язык?

Более того, это вообще наша фича - мы делаем так, чтоб код работал одинаково на всех поддерживаемых версиях Android, а для этого надо собирать с минимальным API level

Это, кстати, очень здорово.
Но вопрос был в том, исправили ли они атомики или нет - видимо, старые платформы трогать не стали. На последней все работает.

Вот я бы хотел что-то написать для смартфонов, но желания писать код на Java или Objective-C нет никакого.

objc великолепен, и совместим с С и С++.

ни в одном нормальном SDK никогда не будет C++ в качестве основы, т.к. в нем нет основополагающих вещей для долговременного обеспечения обратной совместимости. в C то же самое (хотя и меньше гемора, в сравнении с крестами).

ты просто сам не понимаешь, что хочешь очень плохую вещь. представь, что в андроиде или ios поюзали бы культи в качестве основы. пришлось бы весь софт раз в полгода пересобирать или переписывать, после каждого релиза qt ломающего API.

А в qt часто выходят релизы ломающие api?

А в qt часто выходят релизы ломающие api?

каждый мажорный релиз (3,4,5,...), + иногда случайно в промежуточных релизах. (+ не забываем, что на C++ ABI нет стандарта до сих пор, а значит, для поломки кресто-библиотек может хватить смены компилятора, например).

это ломание API лишь малая часть проблемы. представь, что тебе надо написать программу, которая собрана с распоследним Qt5 (например 5.25) и использует новые фичи, но при этом тебе надо чтобы она запускалась на системе с Qt5.0, ессно без пересборки бинари.

С++ такое не особо умеет, а вот жаба и objc такое позволяют достаточно просто.

иными словами, я могу собрать прогу на жабе с последним android sdk, и поюзать новые фичи android5, но при этом прога будет работать на android 1.6, автоматически отключая эти фичи в рантайме. все это в 1 бинаре.

(все то же самое можно делать на C# + winphone, и objc + ios/osx)

пример этого можно посмотреть здесь

Большое спасибо!

ты просто сам не понимаешь, что хочешь очень плохую вещь.

Предположим у меня супер-друпер движок искусственного интеллекта с логикой на С++, зависящий от стопицот других с++ библиотек. Я без проблем портирую этот движок на linux win freebsd и amigaos. И вдруг я захотел это все портировать на андроид. Что прикажете делать?

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

Предположим у меня супер-друпер движок искусственного интеллекта с логикой на С++, зависящий от стопицот других с++ библиотек.

Ага, ага, движок ИИ с логикой на цепепе. На тьюринг-полных шаблонах и паттернах блеать. Бугага :-)

Предположим у меня супер-друпер движок искусственного интеллекта с логикой на С++, зависящий от стопицот других с++ библиотек.

Собрать движок под андроид. Интерфейс написать на Джаве. Серьезных проблем быть не должно

Интерфейс написать на Джаве.

Интерфейс к движку ИИ на цепепе, что на шаблонах написать на жаве. Ахаха :-) Вот это вас прёт :-)

На тьюринг-полных шаблонах

Вы так говорите, как будто это что-то плохое.

Вы так говорите, как будто это что-то плохое.

А ты правда такая симпатичная, как на фотке? :-)

И вдруг я захотел это все портировать на андроид. Что прикажете делать?

захотел - портируй. в чем проблема?

Меня просто раздражает что люди занимаются переписыванием с одного на другой язык

только гуй, и другие низкоуровневые платформозависимые вещи.

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

т.е. даже если бы нативный андроидо-гуй был на цэпэпэ — это бы мало тебе помогло.

В /opt же. Пакетов, вроде как нет.

Я им собирал тулчейн под arm, mips и sh4. Всё работает отлично. Выкачивает порядка 100 МБ (у меня тогда был GPRS, для меня это было критично), компилирует на слабом ноуте примерно час.

это ломание API лишь малая часть проблемы. представь, что тебе надо написать программу, которая собрана с распоследним Qt5 (например 5.25) и использует новые фичи, но при этом тебе надо чтобы она запускалась на системе с Qt5.0, ессно без пересборки бинари.

С++ такое не особо умеет, а вот жаба и objc такое позволяют достаточно просто.

Вообще говоря, это неверно. На C++ ABI есть де-факто стандарт, и тот факт, что можно смешивать в одной сборке бинарники, собранные gcc, clang и icc (Intel), доказывает, что это хорошо работает. Тот факт, что другие компиляторы (Microsoft) этому ABI не следуют, означает всего лишь проблемы этого компилятора, а в контексте Android и вовсе не имеет значения.

Ломание же совместимости в Qt не имеет никакого отношения к языку. Ломать совместимость прекрасно можно и на Java, тому есть много примеров.

Если бы Google озаботился создать C++ API и заботился о его обратной совместимости так же, как заботится о Java API, уверяю, что проблем вы бы не испытывали.

иными словами, я могу собрать прогу на жабе с последним android sdk, и поюзать новые фичи android5, но при этом прога будет работать на android 1.6, автоматически отключая эти фичи в рантайме. все это в 1 бинаре.

Все то же самое можно сделать и на C++, и на C, и на других языках. Никаких принципиальных препятствий тому нет. Вопрос исключительно желания и квалификации.

т.е. даже если бы нативный андроидо-гуй был на цэпэпэ — это бы мало тебе помогло.

С этим, кстати, полностью согласен. GUI - не то, что можно сделать одинаковым для всех платформ. Слишком разное поведение, слишком разный API и т.д. Поэтому даже при наличии C++ API к Android весь код, работающий с Android UI, был бы Android-specific. Так же, как нельзя просто взять код, работающий с iOS UI, и просто перенести на Windows, хотя clang (и, следовательно, Objective-C) для Windows и есть.

Это, однако, не означает, что нельзя писать общее ядро на C++, а платформно-специфичную обвязку свести к минимуму. Я так делал не раз, и это прекрасно работает, а кроме того, экономит огромное количество времени на разработку и резко снижает общую багоемкость проекта (за счет того, что вся логика проекта сосредоточена в одном месте и не дублируется на разных языках для разных платформ).

Rust же

Но вопрос был в том, исправили ли они атомики или нет - видимо, старые платформы трогать не стали. На последней все работает.

Ну, с моей точки зрения это не означает «исправили». Впрочем, это как раз в духе всего, что делает Google: «Некогда думать, пилить надо».

собранные gcc, clang и icc (Intel), доказывает, что это хорошо работает.

как нащет самого популярного компилятора на десктопе msvc?

от факт, что другие компиляторы (Microsoft) этому ABI не следуют

ага, т.е. все таки стандарта нет?

а в контексте Android и вовсе не имеет значения.

угу, потому что у андроида нет C++ API официальных.

Если бы Google озаботился создать C++ API и заботился о его обратной совместимости так же, как заботится о Java API, уверяю, что проблем вы бы не испытывали.

ты бы прочитал про остальные проблемы, помимо API/ABI.

Все то же самое можно сделать и на C++, и на C, и на других языках. Никаких принципиальных препятствий тому нет. Вопрос исключительно желания и квалификации.

конечно можно. например, COM решает подобные проблемы. но он категорически несовместим с встроенной объектной моделью крестов. и адски неудобен в применении.

Это, однако, не означает, что нельзя писать общее ядро на C++, а платформно-специфичную обвязку свести к минимуму.

я такого не утверждал. более того, я именно так и делаю, только у меня C без крестов (что принципиально дела не меняет). а утверждаю я то, что C++ это очень плохой выбор для реализации platform API. и даже C далеко не идеален. а вот java, C#, и ObjC — очень хороши для этой задачи (хотя первые два и имеют миллион других недостатков). непонятно, зачем ты споришь с очевидными вещами.

Я так делал не раз, и это прекрасно работает

ты делал ОС с platform API на C++? это BeOS/Haiku? или были другие подобные издевательства?

как нащет самого популярного компилятора на десктопе msvc?

Это придирка. MSVC к Android не имеет никакого отношения. Так можно было бы и Borland C++ вспомнить.

ага, т.е. все таки стандарта нет?

Стандарта де-юре нет. Де-факто же есть, и gcc/clang/icc ему следуют (даже документация на этот ABI есть, она только не принята в качестве международного стандарта). Для практических целей этого достаточно, потому что ломать совместимость с gcc/clang/icc никто из производителей компиляторов не будет, буде кому придет мысль сделать свой компилятор C++ под Android.

а в контексте Android и вовсе не имеет значения.

угу, потому что у андроида нет C++ API официальных.

Нет, не поэтому. А потому, что MSVC к Android не имеет никакого отношения.

ты бы прочитал про остальные проблемы, помимо API/ABI.

Я прочитал. Единственной проблемой собственно C++ была названа «отсутствие стандарта на C++ ABI», на что я и возразил. Остальные проблемы не имеют отношения к C++ как таковому, это проблемы конкретных библиотек, фреймворков и т.д.

конечно можно. например, COM решает подобные проблемы. но он категорически несовместим с встроенной объектной моделью крестов. и адски неудобен в применении.

Далеко не только COM. Откровенно говоря, в нынешнем Android Java API нет вообще ничего, что нельзя было бы сделать в виде C++ API (и поддерживать обратную совместимость, конечно же; в том числе бинарную). C++ API нет не из-за каких-то фатальных недостатков C++; его нет из-за нежелания его делать.

Это, однако, не означает, что нельзя писать общее ядро на C++, а платформно-специфичную обвязку свести к минимуму.

я такого не утверждал. более того, я именно так и делаю, только у меня C без крестов (что принципиально дела не меняет).

Я нигде и не говорил, что утверждал. Это было не возражение на ваше сообщение, а всего лишь уточнение.

а утверждаю я то, что C++ это очень плохой выбор для реализации platform API. и даже C далеко не идеален. а вот java, C#, и ObjC — очень хороши для этой задачи (хотя первые два и имеют миллион других недостатков). непонятно, зачем ты споришь с очевидными вещами.

А мой опыт говорит, что C++ для API пригоден. Просто при проектировании API всегда надо очень аккуратно и хорошо его продумывать, но это так в любом случае, неважно на каком языке этот API будет.

ты делал ОС с platform API на C++? это BeOS/Haiku? или были другие подобные издевательства?

ОС не делал, но движки с C++ API делал, и бинарную совместимость обеспечивал. Кроме того, была такая Symbian OS, под которую я в свое время писал немало. Так вот, там был C++ API, и именно в виде классов с методами, а не COM. У Symbian было много недостатков, но сам API был на C++, OS пережила много мажорных релизов, и бинарная совместимость поломана не была.

Кроме того, была такая Symbian OS, под которую я в свое время писал немало. Так вот, там был C++ API

Кроме того, была такая BeOS, написанная на ущербном языке цепепе. Была и загнулась, как и Symbian. Не пишите, дети, OS на цепепе. А лучше, вообще ничего не пишите на цепепе, если не хотите, чтобы ваши проекты не постигла участь вышеупомянутых ненужностей :-)

Остальные проблемы не имеют отношения к C++ как таковому, это проблемы конкретных библиотек, фреймворков и т.д.

ты ошибаешься. в C++ нет рефлекшена. без этого проблематично проверить существование определенных классов и их методов в рантайме, перед их использованием. поэтому придумали COM и подобные штуки. но это уже не совсем C++ (технология работает и вообще без крестов совсем).

в objc, java и c# такие штуки есть. но раз ты про это не знаешь (или не хочешь воспринимать как очевидное) — то и говорить тут не о чем.

У Symbian было много недостатков, но сам API был на C++, OS пережила много мажорных релизов, и бинарная совместимость поломана не была.

зато теперь понятно, почему она загнулась.

Статистика мешает. Мало кто может быстро писать на крестах.

Качественный код тоже мало кто писать может. Что же касается managed, то на Swift и Objective-C пацаны с района код пишут довольно быстро, а они не managed. Если бы в C++ умные указатели были бы такими же интегрированными в язык и были бы лучше плюсовые IDE / SDK, на плюсах бы тоже всё отлично было.

угу, потому что у андроида нет C++ API официальных.

Потому что msvc для андроида не компилирует. Ты какой-то неожиданно неадекватный сегодня.