D>Начиная с чудесной, казалось бы, IDE Android Studio,
Зачем она тебе? Нужен любой текстовый редактор начиная от vim заканчиваю VisualStudio (с плагинами для сборки под андроид).

D>В результате мне приходится тащить libxml2 отдельно (из репы опенсорсной части Андроида, хаха), думать, как его собирать.
Пишеш / редактируеш исходный makе и добавляеш к остальным make-ам (ndk-build). Реально там совсем не сложно.
Документации нет (на самом деле — хз, я не искал или читал), но можно посмотреть другие make-и как писать и интегрировать в ndk-build.

D>Есть "родные" automake/autoconf. Спасибо, очень помогло.
Автотулз не имеют таргетов на Андроид. Забудь.

D>Ещё в libxml2 есть файл Android.bp, про который гуглится, что это файл для blueprint, который как-то связан с сборочной системой с именем "soong".
Это задродство гугловых юных андроидоводов. Это в топку, просто пиши make.

D>Ещё пишут "так откатись на несколько ревизий назад, там есть Android.mk, а это обычный мейкфайл!"
D>Нет, сука, если я откачусь на несколько ревизий назад, то я могу получить не ту библиотеку.
Возьми не из Андроидных веток, а нативно из opensource.

PS: Незабудь dtd валидацию в libxml2 отключить, а то за-DDOS-ите и вас забанят (И я не шучу, т.к. такое уже было).

BE>1. Под Андроид нужно разрабатывать из-под Винды или Линукса.
+ (верно)
BE>2. Писать на Java or Kotlin.
— (неверно)

BE>3. Нужен мощный компьютер. Не ноутбук.
— (неверно)

D>Второй компьютер с линуксом заводить? Ну, не знаю...
Android.mk нативно работает под Linux. В остальных случаях приходится для него (частично) эмулировать окружение и прочии плюшки.
Можеш поставить себе виртуалку, думаю время сборки не особо критично для Андроид таргетов.

У первого два монитора, если у второго ещё два монитора будет, они на столе не поместятся.
Hint: Ходи на второй (комп) по ssh из первого (компа) через putty. Второму компу вообще мониторы не нужны.

BE>>2. Писать на Java or Kotlin.
В топку (обоих).

D>Я бы с удовольствием перешёл на Линукс обратно, привык с начала нулевых, но под него нет Xcode
Под него есть Vim. Под венду тоже есть Vim. под андроид... тоже есть Vim (но придется попотеть над пересборкой).

D>Ага. Она написана через libxml2. Я ж не буду из С++-кода через JNI дёргать библиотеку, написанную на Java, которая будет вызывать нативную часть на libxml2.
Вполне вариант. Это не больно, многие так делают.
(лично мне такое не приятно, плюс есть опыт в кучерявых эффектах. Но когда деться больше некуда — это работает вполне нормально).

D>Ровно та же история, что и с libxml.
Ну sqlite совсесм простой для интеграции. ЕМНИП у них есть all-in-one-source вариант — просто добавляеш "huge .c" и заголовок.

CS>Но через NDK рисовать низзя
Можно. Создаеш контекст EGL и вперед. В купе с поддержкой нативных App классов одно раздолье: из Жабы остается только тонкая обертка вокруг эвеентов и все, остально нативно на C/C++.

CS>С грустью вспоминаю Windows CE / Windows Mobile.
WCE была достаточно корявой системой. Мне ее не жалко, хотя занимался ею достаточную часть времени, что бы помнить.

CS>Важно то что те 2D примитивы рисования что использует сам Android не доступны.
CS>А шрифты, i18n и прочее?
Шрифты — рeчками. i18n — gettext.
Причем WCE ни первым ни вторым особо не отличалась (шрифты сглаживались там пень через жопу, а лайауты диалогов там автоматом под локализованый текст предлагается растягивать разработчика своими собственными руками, что совсем не айс).

CS>Где бы были Windows, MacOS или Linux если бы из них убрать GDI, CoreGraphics и GTK. Что-бы было если убрать DrawText и его поддержку ClearType из Windows API...
Там же. (кстати, в Linux, как в ОС, нет ни GDI ни единого прямого аналога: можете Xlib, а можете GTK, а можете и TUI — это все не части ОС, а сторонии либы).

Здравствуйте, eskimo82, Вы писали:

D>>Я бы с удовольствием перешёл на Линукс обратно, привык с начала нулевых, но под него нет Xcode
E>Под него есть Vim. Под венду тоже есть Vim. под андроид... тоже есть Vim (но придется попотеть над пересборкой).

Я в Vim писал под Андроид, пока не было Андроид Студии, а на Эклипс у меня аллергия. А до этого писал в Vim практически вообще всё. Я умею в Vim, но настроить запуск разного и отладку не готов.

Здравствуйте, eskimo82, Вы писали:

CS>>Где бы были Windows, MacOS или Linux если бы из них убрать GDI, CoreGraphics и GTK. Что-бы было если убрать DrawText и его поддержку ClearType из Windows API...
E>Там же. (кстати, в Linux, как в ОС, нет ни GDI ни единого прямого аналога: можете Xlib, а можете GTK, а можете и TUI — это все не части ОС, а сторонии либы).

Есть Linux, а есть Linux Desktop. Linux Desktop это Ubuntu, Mint и пр.

Всё что модно сравнивать так это Desktop Windows и Desktop Linux. Windows и GDI/GDI+, GTK и Cairo. То же самое на MacOS и iOS, там CoreGraphics.
Все эти OS предоставляют стабильные graphics API.

Android же есть недо-ось. Половины того что нужно нет.

Здравствуйте, Dair, Вы писали:

D>И я рад за Java (который используется в бэкенде банков, вроде как, да?), но я, конечно, говорил про конкретную область.
D>Вот у меня есть кроссплатформенное приложение на Win/Lin/iOS/Android. Критичное иногда к времени выполнения. С++ — единственный выбор для этого. Не то чтобы я сильно фанат С++, но другого не дают.

а всякие там компиляторы в натив не пробовал?

CS>Есть Linux, а есть Linux Desktop. Linux Desktop это Ubuntu, Mint и пр.
"Linux Desktop" это не ось, а GDE (Graphical Desktop Environment).

CS>Всё что модно сравнивать так это Desktop Windows и Desktop Linux. Windows и GDI/GDI+, GTK и Cairo. То же самое на MacOS и iOS, там CoreGraphics.
CS>Все эти OS предоставляют стабильные graphics API.
Еще раз — Linux OS не предоставляет graphics API, поскольку его там нет (фреймбуфер тут не в счет).

CS>Android же есть недо-ось. Половины того что нужно нет.
Андроид — совсем даже неплохая ОС для мобильных девайсов.

D>Я в Vim писал под Андроид, пока не было Андроид Студии, а на Эклипс у меня аллергия. А до этого писал в Vim практически вообще всё. Я умею в Vim, но настроить запуск разного и отладку не готов.
gdb запускается отдельно (надо пробросить порт на десктоп через adb, сервер кладется рядом вместе с нативными либами внутри apk, запускается через adb) от vim (и там есть TUI) или различные графические фронтэнды (ddd, insight).

Но ок, если не нравится — для вижуал студии есть плагины (nsight tegra например). С точки зрения пользователя проект под Андроид ничего не отличается от вендового, работа с отладчиком тоже интегрирована.

D>Если JSON — это всего лишь моё с сервером API

ну так чего ж ты молчал? кидай все на сервер, храни/обрабатывай там, а обратно православный JSON в формочке показывай средствами операционки. сервер он все стерпит

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

Здравствуйте, Dair, Вы писали:

D>Второй компьютер с линуксом заводить?
Виртуалка, не?

Здравствуйте, eskimo82, Вы писали:

E>Под него есть Vim.
Ты ещё ed предложи, да?

Здравствуйте, CreatorCray, Вы писали:

D>>Второй компьютер с линуксом заводить?
CC>Виртуалка, не?

Противоречит пункту 3 же

Но да, я понял идею. Щас поставлю, посмотрю, что будет там.

Здравствуйте, Dair, Вы писали:

C>>Ну так а сначала написать на Java, а потом посмотреть на скорость? Или вообще на JS с Electron.
D>Требовать от клиента ставить Java при установке на винду — моветон.
Electron — на JS, если нужно UI.

D>Как поставить джаву на iOS, и пустят ли такое приложение в аппстор — поделись.
Kotlin, кстати, поддерживается.

C>>Ну так возьми обычный libxml2 с сайта libxml и поставь в сборку. Там будет и CMake и блэкджек.
D>Найти CMake мне не удалось: https://gitlab.gnome.org/GNOME/libxml2/
CMakeFile генерируется из вот этого шаблона:
https://gitlab.gnome.org/GNOME/libxml2/blob/master/libxml2-config.cmake.in

Можно просто руками его переименовать.

D>Но и это я решу. Но хотелось-то чтобы было проще. Я тут ною не от невозможности чего-то сделать, а от того что сделано сложно ну вот просто так, без каких-либо реальных причин, просто не подумали.
Нет, они подумали. Android специально ограничивает доступную поверхность доступного API для того, чтобы было проще поддерживать бинарную совместимость.

C>>А они точно нужны? UTF-8 уже доминирует везде.
D>Пользовательский контент, теоретически, может быть любым. Пока это валидный XML, надо уметь парсить. В Японии "любят" родную (JIS) кодировку до сих пор, например, это про что я точно знаю.
Что-то не очень понятно, зачем это на Андроиде.

D>>>Что "зачем"? Чтобы собрать libxml2, конечно!
C>>Зачем из репозитория Андроида?
D>Потому что в репозитории Андроида он ровно тот, который внутри Андроида.
И что?

D>Вообще у меня была мысль с ним слинковаться, но в бандл не пихать, чтобы библиотека пользовалась системным. Но, видимо, не судьба, я уже смирился.
Вот именно поэтому и не дают таким бредом заниматься. Так как это создаёт скрытые зависимости, которые Google может совершенно случайно сломать очередным update'ом системы.

D>>>У меня бизнеслогика на С++, которая собирается и туда, и туда.
C>>Вот тут-то и вопрос — если в С++ нужно чтение XML, да ещё с кодировками, то задача выглядит уж совсем точно не для С++.
D>Да XML-то пример просто. Так-то, вообще, у меня есть бизнес-логика, которая:
D>1. Хранит на "диске" SQLite-базы
D>2. "Спрашивает" и "слушает" сеть (сеть на "родных" интерфейсах, через уровень абстракции)
D>3. По этой сети получает (в т.ч.) XML определённого формата и JSON определённого формата.
Ну вот и поместить нормализацию на сервер. Но да, тогда С++ ещё как-то вменяемо выглядит. Хотя я бы всё равно писал на чём-нибудь типа Go или C#.

Здравствуйте, Dair, Вы писали:

D>Ты перечитай. Я и взял. В репе Андроида она и лежит, отличие только в наличии Android.bp.

Ну в репозитории Андроида может быть не самая свежая версия. В целом лучше всего брать исходники у изначальных авторов. Хотя к обсуждаемой проблеме это особого отношения не имеет.

D>Я и хочу теперь уже собрать и прилинковать.
D>Но есть нюанс.
D>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong.
D>Стоит совершенно непонятно зачем задача сопряжения одного и другого.

Это ещё зачем? Для подключения сторонней библиотеки в C/C++ проект достаточно указать компилятору на папку с заголовочными файлами и на папку со скомпилированными библиотеками. Больше не требуется ничего. Причём дело не в том, что системы сборки разные — даже при одной системе сборки у проекта и библиотек нет никакого смысла в каком-то их объединение, т.к. именно ради такого разделения и придумано вообще понятие библиотек.

Здравствуйте, Dair, Вы писали:

C>>А руки проверять не пробовали на радиус кривизны?
D>Давай курвиметр. Других рук вот только нет, сорри.

Курви́метр (от лат. curvus — изогнутый + греч. μέτρον — мера) — прибор для измерения длины...

Здравствуйте, alex_public, Вы писали:

D>>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong.
D>>Стоит совершенно непонятно зачем задача сопряжения одного и другого.

_>Это ещё зачем? Для подключения сторонней библиотеки в C/C++ проект достаточно указать компилятору на папку с заголовочными файлами и на папку со скомпилированными библиотеками. Больше не требуется ничего. Причём дело не в том, что системы сборки разные — даже при одной системе сборки у проекта и библиотек нет никакого смысла в каком-то их объединение, т.к. именно ради такого разделения и придумано вообще понятие библиотек.

А скомпилированные под 4 архитектуры библиотеки я
а) Возьму где?
б) Хранить буду как?