Ламерский вопрос по разработке под android.

Встроенная виртуальная машина с JIT достаточно быстра для работы с интерфейсом и логикой. Нативный код стоит включать в трех случаях: действительно тяжелые вычисления, использование готового кода в своем приложении, игры / графика.

Под каждую архитектуру все само собирается, нужно только их перечислить в конфигурационном файле.

Разработка не на java под андроид очень неудобна.

как скомпилированный под специфический процессор C++...

Не специфический, а ARMv*. У них в общем обратная совместимость вроде, так что бинарь один понадобится. Всякие движки, по крайней мере, пихают одну-две либы.

...код втыкать в приложение

Делаешь библиотеку, вызываешь из явы. Ну или делаешь проект полностью на C. В NDK примеры есть же!

Не специфический, а ARMv*.

Андроид не только на арме бывает. Как минимум ещё встречаются мипсы и x86.

мипсы и x86.

Ну и? Две дополнительные папки с бинарями.

Просто ТС так написал "под специфический процессор", что можно подумать, что под каждый проц есть свой билд. Это далеко не так.

Всякие движки, по крайней мере, пихают одну-две либы.

В пень таких жлобов: две-три - это только для армов, а ещё мипс и 86-й (как минимум)

Унификация, разработчикам же легче.

зависит от приложения. Тот-же навител - это в большем огромная so-шка и маааленькая пускалка для него. Вот там для совместимости - под один (младший?) арм (таки жлобы!).

В пень таких жлобов: две-три - это только для армов, а ещё мипс и 86-й (как минимум)

Две-три это как раз на всё-провсё. Я сегодня прикручивал к проекту libgdx, чтобы она работала на x86. В итоге "пришлось" сделать подкаталог x86 и запихнуть одну либу. Изначально в бинарях идёт две: "armeabi" и "armeabi7a". Вот я три и насчитал. А если в теме не шаришь, то

В пень таких жлобов

Разработка не на java под андроид очень неудобна.

Мальнькая прослойка для инициализации, обработки suspend/resume/etc, все остальное пишется на си.
Но как только нужна реклама, платежи, apx, то тут только ява и куча геморроя. Особенно напрягают внутренние платежи.

Изначально в бинарях идёт две: «armeabi» и «armeabi7a». Вот я три и насчитал.

А mips побоку? Вот сам и иди в пень!

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

А что сложно запустить сборочный скрипт еще для одной архитектуры?

ndk-build собирает сразу для всех (указанных в конфигурационных файлах).

Ну например тебе надо использовать готовую библиотеку в своем проекте. Например тот же ffmpeg. Писать для него скрипты для ndk-build запарненько. Лучше собрать и подпихнуть готовый .a файл, в этом случае придется собирать уже под все платформы.

Мне как бы пришлось несколько проектов компилировать под mips, ни в одном не было .a файлов, везде исходники. Фактически всё сводилось к добавлению mips в список архитектур и пересборке. Но это были opensource проекты; возможно в закрытых делают по-другому.

ndk-build умеет собирать autotools-проекты?

ndk-build умеет собирать autotools-проекты?

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

Ну вот, иногда проще просто собрать autotools-проект при помощи standalone-тулчейна полученного из ndk, и просто скинуть .a файлы куда надо. mk-файлы ndk-build спокойно подхватывают такие файлы.