Segítség kérés SDL fordítás Androidra

C/C++

Csinált már valaki ~t? Van valamelyik fórumtársnak ilyenben tapasztalata? Próbálom kihámozni a lényeget, de finoman szólva is egy overcomplicated agyfasz ez az egész Android buildelés.

Ami nekem kéne, az minimális dependency-vel annyi, hogy a letöltött SDL.so-ból, a kigenerált main.so-ból és még néhány asset fájlból összerakjon nekem egy .apk fájlt. Tehát lehetőleg C és Java fordítás nélkül, csak a csomagolást oldja meg. Ha itt-ott generálni kell egy xml-t app specifikus sztringekkel a bemenetben hozzá, az nem probléma, azt megoldom, de elsőre az is elég, ha minden egyedi sztringje "helloworld". FONTOS: semmilyen más függőség nincs, csakis az SDL alapfüggvénykönyvtár.

Nézegettem a doksikat és forrásokat, de egy irtó katyvasz az egész, pláne ahhoz képest, hogy az .apk lényegében csak egy zip archívum.

Az SDL hivatalos doksi itt van, a hozzá tartozó repó meg itt. Ezzel az a bajom, hogy egy dependency hell fos az egész, kell neki ndk, cmake, make, ant, gradle, prefab, python meg még isten tudja mi. Ez instant bukó, túl sok verzió, túl sok függőség, túl sok hibalehetőség.
(És akkor arról még nem is beszéltem, hogy a forrásba egy csomó helyen bele van égetve ez-az, túl sok helyen kell belőle a helloworld-öt kiirtani, még xml stroke path-ok is bele vannak vasalva, meg nem használ main()-t, szóval kiiunduló sablonnak totál szar.)

A legjobb megoldás eddig, amit találtam, az ez. Ez SDL2-höz van, de az nem baj, sőt, ahogy nézem kevesebb szívás, úgyhogy jobb is. Ennek nem kell se gradle, se cmake, se python, se stb. és stroke pathok sincsenek beleégetve. Csak ndk kell neki, mert forrásból fordítja az SDL-t. Namost én nem akarom forrásból fordítani, nekem teljesen jó a hivatalos bináris, akár az .aar verzió, akár az, hogy kézzel berakom az ARM-re fordított libSDL.so-t a jni mappába.

Nem akarom ráhagyni a program fordítását se, azt is megoldom inkább magamtól gradle meg minden más fos nélkül. Simán fordítok ezek nélkül egy main.so-t, ami shared library main() függvénnyel ARM architectúrán. Arra is oda tudok figyelni, hogy adott verziójú SDL-lel fordítsam, és simán be tudom másolni az eredményt a jni mappába python meg cmake meg a többi szotty nélkül.

Tudna segíteni valaki ebben, csinált már valaki ilyent? Már az is irtó nagy segítség lenne, ha valaki le tudná fordítani az SDL_helloworld vagy sdl2_on_android repókat és belinkelné ide a letölthető eredmény .apk-t, hogy aztán szétcincálhassam és összevethessem a forrásával.

(ps: amihez kéne, hogy a projektemben generálok egy main.so-t, és ebből meg pár előre legyártott fájlból csináljon nekem egy működő .apk-t. Az egyetlen függőség a libc-n túl az SDL2 vagy 3.)

  • 1266 megtekintés

ha a libsdl2.so kell

Kösz, de nem kell, az van. A többi faszságra kéne valami. Például arra, hogy ne kelljen 20G-nyi Android Studio-t telepíteni csak azért, hogy az ember lefordítson egyetlen 5 soros .java fájlt, ami mást sem csinál, csak meghívja a main()-t. Meg az ilyenekre kéne valami.

Igazából az lenne a legjobb, ha lenne valaki, akinek be van röffentve már ez a környezet, és hajlandó lenne segíteni abban, hogy lefordítson nekem egy projektet adott appnévvel és egy üres main() függvénnyel. Az így nyert vázat már tudnám használni, csak kicserélném benne a main.so-t és csók.

Például arra, hogy ne kelljen 20G-nyi Android Studio-t telepíteni csak azért, hogy az ember lefordítson egyetlen 5 soros .java fájlt, ami mást sem csinál, csak meghívja a main()-t. Meg az ilyenekre kéne valami.

Nem kell Android Studio. Gradle kell és az SDK.

Igazából az lenne a legjobb, ha lenne valaki, akinek be van röffentve már ez a környezet, és hajlandó lenne segíteni abban, hogy lefordítson nekem egy projektet adott appnévvel és egy üres main() függvénnyel. Az így nyert vázat már tudnám használni, csak kicserélném benne a main.so-t és csók.

Itt van: https://hub.docker.com/r/mobiledevops/android-sdk-image

Adott verziót lehúzod, Docker-ben elindítod és ott van egy CLI Android SDK környezet, amiben azt csinálsz, amit akarsz.

https://iotguru.cloud

Nem kell Android Studio. Gradle kell és az SDK.

Csakhát az SDK-t nem lehet felrakni Android Studio nélkül, legalábbis a doksi szerint... Bárhol nézed, mindenhol azzal kezdik, hogy rakd fel az AS-t, még az SDK linkje is direktben oda vezet...

Adott verziót lehúzod, Docker-ben elindítod és ott van egy CLI Android SDK környezet, amiben azt csinálsz, amit akarsz.

Ez nem jó. Be sem jön az oldal. De még ha menne, akkor sem lenne elég az Android SDK környezet az SDL-nek, kell az NDK is meg a gradle is, meg python meg cmake meg prefab is. Ezek gondolom jól kimaradtak ebből a dockerből, úgyhogy függőségek hiányában egyébként se lehetne SDL-t fordítani rajta.

De egyébként sem akarok ezzel a fordítással szarakodni, pont azért keresek egyszerű .apk csomagoló megoldást helyette. Ahogy elnézem, mindössze egyetlen .dex fájl fordítása kérdéses, minden más faék, bár sha1 ellenörzőösszeget nem tudnak az Androidos toolok számolni, az is biztos.

Nézd, nálam megy Android Studio nélkül és bejön a hivatkozott oldal is. Van benne NDK és Gradle is, ezt használom headless Android CI build-re évek óta, ha kell bele neked még valami, akkor csinálsz magadnak egy Dockerfile és azt teszel még bele, amit csak akarsz.

https://iotguru.cloud

Le tudod fordítani az SDL_helloworld példát? Ha csinálok egy hasonló minimál android-project mappát, azt lefordítanád nekem?

Ha az SDL_helloworld lefordul, akkor úgyis lefordul, ha kihajítod belőle ezt meg ezt? Az előbbiben nem tudom, mit csinálhat a google() hívás, de kurvára nem tetszik, és a gradle dokumentációjában sem említik egy szóval se. A másodikban meg még kevésbé tetszik, hogy egy hálózatról letöltőgetős kód, ami beinjektálódik a lefordított proggiba... Nekem nem kellenek semmiféle gradle pluginok se google cuccos, csak egy mezei .apk, ami meghívja a main()-t.

Ha ezek nem, akkor az sdl2_for_android példát le tudod fordítani (az még ant-os). Ha ebből csinálok egy hasonló minimál android-project mappát, azt lefordítanád nekem?

Le tudod fordítani az SDL_helloworld példát? Ha csinálok egy hasonló minimál android-project mappát, azt lefordítanád nekem?

Nem fogom, ez annyira faék dolog, hogy meg tudod csinálni te is. Ha meg beüt a paranoia, akkor csináld egy eldobható gépen.

mit csinálhat a google() hívás

Meghatározza a Google Maven repository helyét.

de kurvára nem tetszik, és a gradle dokumentációjában sem említik egy szóval se

Megemlítik, itt: https://developer.android.com/build

Idézem: 

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. Here we
      * define the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }

A másodikban meg még kevésbé tetszik, hogy egy hálózatról letöltőgetős kód, ami beinjektálódik a lefordított proggiba...

Miért, a többi cuccod nem a hálózatról töltötted le? Megrendelted futárral papíron és begépelted?

https://iotguru.cloud

Nem fogom

Magyarul: járatod itt a pofád össze-vissza feleslegesen, na de segíteni, na azt nem akarsz.

Miért, a többi cuccod nem a hálózatról töltötted le?

Tényleg nem érted, mi a különbség aközött, hogy fordítás ELŐTT letöltesz valami forrást, lefordítod és ÖSSZELINKELED, illetve aközött, hogy a build akaratodon kívül belerak valamit, ami aztán FUTÁSIDŐBEN töltöget le és futtat le kódot a hálózatról?

senki nem ugy hasznalja az android buildet, mi ezt mondtuk hogy hasznald te is igy. de ha te teljesen mashogy akarod csinalni, akkor sajat magadnak kell kiturni a dolgot. ezestben nem ertem mit varsz itt?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Tényleg nem érted, mi a különbség aközött, hogy fordítás ELŐTT letöltesz valami forrást, lefordítod és ÖSSZELINKELED, illetve aközött, hogy a build akaratodon kívül belerak valamit, ami aztán FUTÁSIDŐBEN töltöget le és futtat le kódot a hálózatról?

Hja, én vagyok a fasz, hogy segíteni akartam, legközelebb ez már nem fordul elő.

Szerintem ez egy jó kérdés.

Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

Szerintem ez egy jó kérdés.

Hamis dilemma. A build az akaratomnak megfelelően belerakja azt, amit én szeretnék, hogy belekerüljön és a central maven repóból letölti, hogy ne nekem kelljen ezzel baszkolódni. Sokkal kényelmesebb, hogy csak meghivatkozom, hogy nekem kell a `classpath 'com.google.firebase:perf-plugin:2.0.1'`, akkor a Gradle (és a Maven is) letölti ezt az egzakt verziót a central repóból a build részeként (ha nem lenne meg helyben már), felhasználja a benne lévő mindenféle fájlt annak megfelelően, ahogy használni szeretném. Továbbra se értem a felháborodást, egyszerűen vannak, akik buborékban élnek.

https://iotguru.cloud

Ez nem probléma?

Mint írtam, ez hamis dilemma. A build nem tesz semmit bele az akaratom ellenére, amit beletesz, azt kifejezetten én akarom, hogy tegye meg. Ahonnan indultunk ott volt említve a `google()`, ami a Google Maven repository (https://maven.google.com/web/index.html), innen tölt le mindent, amire hivatkozok; a második említés a `gradle-wrapper` volt, ami annyit csinál, hogy letölti és elindítja a `gradle.properties` meghivatkozott Gradle verziót. Egyik se csinál olyat, ami az akaratom ellenére történne, viszont mind a kettő futásidőben, a build előtt tölt le dolgokat és futtat kódot (konkrétan a build kódját), mert ez a dedikált dolguk, hogy ne nekem kelljen azzal baszakodni, hogy ezer apró függőséget letöltök. Ezen ennyire meglepődni buborékban élés és a tudatlanság minősített esete.

https://iotguru.cloud

Most lehet, hogy én értek félre valamit, de konkrétan mi itt az, amin a nagy felháborodás megy, hogy futásidőben (mármint az app fejlesztő által írt Java program, ami egy Android app futásidejében) kezd el letölteni valami "ismeretlen" dolgot? A gradle wrapper a gradle-t meg a gradle függőségeket azok mind a fordítási folyamat részeként tölti le, vagy itt most másról van szó?

nem ertesz felre semmit. a gradle csinalja a build kornyezet felepiteset (ami linuxos C-s appoknal te csinalsz kezzel apt-get install gcc-11 binutils libtool stb), csak itt a google altal hostolt repoban vannak azok a pluginek ami a buildeleshez kellenek (xml formatum ellenoro, java->dex compiler, apk signer, stb). a gradle wrapper meg csak annyi hogy "milyen verzioju apt-get-ed legyen". igy lehet az appra koncentralni a build folyamatos meg rabizni okossakra akik megcsinaltak mar.

persze akinek felelme van hogy a google maven-lint-check-plugin valami csunya dolgot fog injektalni a kodba, es ki akarja hagyni ezeket, es kezzel csinalni a buildet. hat lelke rajta, csak epp szopo.

kaktusszal is lehet rejszolni, csak nem annyira elvezetes... :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( bzt | 2025. 09. 26., p – 22:56 )

Szerkesztve: 2025. 09. 26., p – 23:18

Na, a következőkre jutottam:

Gradle NO GO, hálózatos letöltős kódot inject-ál a lefordított proggiba, ami egy hú bazdmeg, nehogymá, ezért simán akasztás jár jobb helyeken!

Szóval Android Studio és Gradle nélküli megoldás jöhet csak szóba.

A kérdéses toolchain-t letölthető simán ugyan, de az URL-jét kisujjból kell kiszopni, ami trükkös, mert néha számkód van benne (pl itt). Erre találtam ezt az oldalt, de ez nem tűnik hivatalosnak. Mindenesetre az oldalon szerepelő linkek a google-re visznek és működni látszanak.

Az SDL3 forrásából (hála a gitnek) van még Gradle mentes, itt. Ez még nem inject-ál semmit a lefordított kódba, és ant-ot használ. Cserébe elképzelni sem tudom, hogy ez valaha is lefordulna, ugyanis össze vissza nevek szerepelnek az xml-ekben (meg SDL2_static itt-ott)...

Némi metaadat, némi aláírások, ilyesmik. Biztos vagyok benne, hogy meg lehet csinálni speckó alapján Gradle nélkül. Csak rámegy 1-2-3 éved mire működni fog :-)

Mivel mindenki Gradle-val csinálja, az Androidosok nem fognak panaszkodni miatta. Én is azt javaslom, hogy egy virtuális masinába tedd fel és csináld meg úgy.

Némi metaadat, némi aláírások, ilyesmik.

Faszt. Dalvik kódot húz le, amit le is futtat, leellenőriztem.

Biztos vagyok benne, hogy meg lehet csinálni speckó alapján Gradle nélkül. Csak rámegy 1-2-3 éved mire működni fog

Öööööö KÉT repót is linkeltem, ami megcsinálja Gradle nélkül, nem kell kitalálni semmit, csak kipróbálni, hogy megy-e valamelyik...
pl: https://github.com/jarchen/sdl2_on_android

Mivel mindenki Gradle-val csinálja, az Androidosok nem fognak panaszkodni miatta.

Az elég nagy baj. Írtó gáz, ha a build environment hálózatos kódot injektál a lefordított proggiba. Kimondhatatlanul nagy gáz. De ha bevallottan ennyire balfaszok az Androidosok, ám legyen, felőlem jöhet Gradle-s megoldás is!

Én is azt javaslom, hogy egy virtuális masinába tedd fel és csináld meg úgy.

Próbáltam, nem megy. Legalább 16G RAM-ot kér, nem tudok ekkora virtuális gépet csinálni, nincs elég hoszt RAM-om hozzá. Swapfájlt meg valamiért nem eszi meg újabban a VB, mindenki látja, mindenki használja, csak a VB nem.
Természetesen a VM volt a legelső, amit próbáltam, mielőtt HUP-ra írtam volna.

Ha ment volna VM-ben, nem is nyitottam volna segítségkérő topikot...

( hrgy84 | 2025. 09. 30., k – 12:48 )

Figyelj, nulladik körben szard le a beinjektált kódot meg a paranoiát, fordítsd le a standard megoldással, hogy egyáltalán megszólal-e az alkalamzásod. Nem kell valódi telefonra kiraknod, az Android Emulator - az AS-ba integrálva de külön is elérhető - tudja futtatni, semmi érzékeny adat nem megy ki róla sehova. Ha az megvan, hogy a kódod lefordul, és fut, és működik, na akkor lehet szétszedni meg újra összerakni a buildet úgy, hogy megint megszólaljon az emulátoron. Én mindent megértek, de egy tök ismeretlen ökoszisztémát úgy tudsz megismerni a legjobban, ha legalább az ismerkedés időszakában rendeltetésszerűen használod. Aztán amikor már érted, hogy hogy működik a kód a háttérben, akkor utána megalkothatod a te UltimateAndroidBuilder (uab.exe) megoldásodat.

Amúgy, az Android buildelés meglehetősen bonyi dolog, már nem sok mindenre emlékszek a régi próbálkozásaimból, de az NDK és az SDK musthave dolgok, mert az R.java fordításához kell az SDK (és a Gradle is), a többihez az NDK. Ezen felül még az adott platform cuccai is kellenek.

Ha nem akarsz Android Studiot használni, ott van az sdkmanager CLI eszköz: https://developer.android.com/tools/sdkmanager

Régen ennek volt egy GUI-s megoldása is, de azt úgy látom megszüntették, de ezzel szinte biztos, hogy AS nélkül is le tudod tölteni a dolgokat - kicsit nagyobb szopással.

Ami a Gradle-t illeti, én kifejezetten javaslom, hogy azt tartsd meg, mert elég sok szopást meg tudsz vele spórolni Java fordításnál illetve csomagolásnál - az APK csomagokat nem csak be kell ZIP-elni, hanem DEX-elni is kell meg aláírni digitálisan. Erre a Gradle a legegyszerűbb megoldás.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Figyelj, nulladik körben szard le a beinjektált kódot meg a paranoiát

Nem tehetem, nem engedi a lelkiismeretem. Pláne, ha találtam KÉT repót is, ami elvileg enélkül megoldja out-of-the-box. (Az sdl2_on_android és az SDL3 korábbi változata)

fordítsd le a standard megoldással

Mint említettem volt, nem tudom, mert nem tudok akkora virtuális gépet csinálni neki.

hogy egyáltalán megszólal-e az alkalamzásod.

Mint említettem volt, nem saját alkmazást akarok első körben fordítani, hanem az SDL_helloworld-öt...

ha legalább az ismerkedés időszakában rendeltetésszerűen használod.

Mint említettem volt, nem tudom rendeltetésszerűen használni, mert nincs elég RAM a gépemben... A VB meg nem eszi meg a swapfájlt, így lehazudni sem tudok többet.

az APK csomagokat nem csak be kell ZIP-elni, hanem DEX-elni is kell

Ezt a lépést már megoldottam, pofon egyszerű, az SDK-beli d8 egysoros parancssal megy.

meg aláírni digitálisan.

Ez a része meg nem érdekel, unsigned .apk-ra van szükségem. (Egyébként az aláírás is egysoros paranccsal megy simán, nem ügy megoldani, ha esetleg kellene.)

Tisztában vagyok vele, hogy ezek a lépések lennének, a gond az, és amiért segítséget kértem itt a HUP-on, mert egyáltalán nem fut a környezet. Szétcincáltam a komponenseit, és külön külön próbáltam és tudom futtatni őket, de mint írtad, nehéz úgy ismerkedni egy új környezettel, ha még sosem láttad teljes egészében működni. Legalább egy lefordított SDL_helloworld vagy sdl2_on_android .apk-ra szükség lenne, ez a minimum, de eddig még csak okoskodást kaptam itt a HUP-on a lefordított binárisok helyett.

( persicsb | 2025. 09. 30., k – 15:20 )

Szerkesztve: 2025. 09. 30., k – 15:21

Simán fordítok ezek nélkül egy main.so-t, ami shared library main() függvénnyel ARM architectúrán.

Csakhogy az Android alkalmazások nem ilyenek. Mindenképpen kell neked egy Androidos entry point, amit az Android loader meg tud találni. Ezek nem sima ARM binárisok.

https://source.android.com/docs/core/runtime

A rendszer ezt fogja betölteni, ez már betölthet más binárisokat is a saját DEX archívumán belül.

Pontosabban telepítéskor átfuttatja a dex2oat eszközön, hogy ahead-of-time legyen belőle egy olyan ARM bináris, amit az ő betöltője be tud tölteni. Nem standard GNU/Linux loadert használnak.

At install time, ART compiles apps using the on-device dex2oat tool. This utility accepts DEX files as input and generates a compiled app executable for the target device. The utility should be able to compile all valid DEX files without difficulty.

Natív binárisokat is csak az NDK segítségével használhatsz.

 

A lényeg, hogy az Android nem csak egy sima GNU/Linux, az egész permission-kezelése nem engedi meg, hogy olyan laza legyen, mint a POSIX processz modell, emiatt a betöltő sem szokványos stb.

Jól van most már, nem okoskodásra van szükség... Pláne nem olyantól, aki jól láthatóan nem is ért hozzá, már bocs.

Csakhogy az Android alkalmazások nem ilyenek. Mindenképpen kell neked egy Androidos entry point, amit az Android loader meg tud találni. Ezek nem sima ARM binárisok.

Csakhogy az SDL esetében igenis ilyenek. A classes.dex konkrétan csak annyit csinál, hogy meghívja a main()-t, semmi mást. A példa esetében egész konkrétan a libs/*/libsdl-helloworld.so fájlbeli main()-t.

Natív binárisokat is csak az NDK segítségével használhatsz.

Ez sem igaz. Egyrészt a használathoz lófaszt se kell az NDK, csak fordításhoz, ráadásul bármelyik ARM cross-compiler is éppúgy megteszi.

A lényeg, hogy az Android nem csak egy sima GNU/Linux

A lényeg, hogy már megintcsak haszontalan (ráadásul hibás) okoskodást kaptunk lefordított bináris helyett.

en mindig birtam azokat az embereket, akik segitsegert jonnek, de jol lefikkantjak aki barmi mast hozzaszol. De ha ilyen magas a lo, es mindenhez IS ertesz akkor miert kerdezel? nemertem.... :/

tobbet en sem tudok mondani minthogy hasznald ugy hogy kitalaltak, mert az _mukodik_. de most mar kivancsi vagyok mi lesz a vergodes vege! 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( bzt | 2025. 09. 30., k – 15:49 )

Szerkesztve: 2025. 09. 30., k – 15:54

Na mégegyszer: a segítség a következőből állna:

1. le kéne fordítani az SDL helloworld-öt, és elküldeni nekem a binárist (lehetőleg gradle nélküli repót)
2. ez alapján csinálnék egy hasonló faék egyszerű android-project mappát
3. ezt is le kéne fordítani és elküldeni nekem a binárist
4. ha esetleg gond van, akkor iteráció 2. ponttól néhány alkalommal

Ennyi. Erre lenne egész konkrétan szükség. Cserébe bekerülne az illető a LUDUS credits fájljába, illetve fel tudok ajánlani egy MEG4 PRO licenszt, ha igényt tart rá (ezzel lehet natív Windows, Linux és WebAssembly binárist exportálni a virtuális konzol programokból). Vagy cserébe felajánhatok segítséget olyan programozási problémával, amivel ő küzd.

Ha jól értem a repót, az androidos csomagot kizárólag Gradle-lel tudod lefordítani: https://github.com/libsdl-org/SDL_helloworld/blob/main/.github/workflow…

A CMake-es konfig az csak a natív binárist oldja meg, de az Android app lefordításához ő a Gradle-t használja. Elindítom a fordítást, de nem egy acélos a gépem CPU-ban, nem tudom mennyi idő lesz, ha van bináris, felnyomom neked valahova.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Én már a CMake-nál, hogy nem hiányolja az NDK-t, valami speckón kellene a cmake-t meghívnom, még kutatok. 

Ja, neked amúgy nem is aarch64 kellene, hanem az alábbiak valamelyike:

armeabi-v7a  
armeabi-v7a with NEON Same as armeabi-v7a.
arm64-v8a  
x86  
x86_64

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

me@gagyiarm64router:/home/me/sdl2_on_android-master# ndk-build
ERROR: Unknown host CPU architecture: aarch64

A hosttal van a baja , mindenáron keresztfordítani szeretne, de lehet van olyan NDK amivel ezen is menne, vagy lehetne tákolni rakta valamit , hogy menjen, nem vagyok android dev. 

A CMake-nak konkrétan meg kell mondani, hol lakik a jóisten hol lakik az NDK. Viszont, nekem nem kellett ez az ndk-build vagy nem tudom, hogy kellett-e volna, az Android Studio weboldalán találtam ehhez egy leírást: https://developer.android.com/ndk/guides/cmake

Innen ollóztam ki azt a baromi hosszú CMake parancsot, kicsit fodrászoltam rajta, mert egy kicsit régebbi CMake-hez vannak benne opciók, volt ami nem működött (a -H például), azokat kivagdostam, meg a prefabos részt is kihajítottam, mert nekem nincs olyanom. Apparently enélkül is lefordult... :thinking: 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Az APK csomagok: https://static.hron.me/hup-bzt-sdl-helloworld-apks.zip

Viszont, nem tudtam emulátorban tesztelni, mert nem tudom életrekelteni, nem enged x86_64 -es gépen ARM64-es QEmu-t indítani, és egy nagyon hosszú nap végén vagyok, ne haragudj, ebbe már nem mentem bele.

A binárist így fordítottam:

$ANDROID_HOME/cmake/4.1.1/bin/cmake  -DCMAKE_BUILD_TYPE=Debug -DANDROID_ABI=arm64-v8a  -DANDROID_NDK=$ANDROID_HOME/ndk/28.2.13676358 -DANDROID_PLATFORM=android-35 -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a -DCMAKE_ANDROID_NDK=/opt/android-sdk/ndk/28.2.13676358 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=$PWD -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=$PWD -DCMAKE_MAKE_PROGRAM=$ANDROID_HOME/cmake/4.1.1/bin/ninja -DCMAKE_SYSTEM_NAME=Android -DCMAKE_SYSTEM_VERSION=35 -B "$PWD/build" -GNinja

A Gradle-ös fordítás tulajdonképpen könnyű volt, miután felpakolt minden függőséget az SDK Managerrel. Az egyetlen trükkös rész az a preparáció volt:

https://github.com/libsdl-org/SDL/releases/download/release-3.2.16/SDL3-devel-3.2.16-android.zip ~/Downloads
unzip ~/Downloads/SDL3-devel-3.2.16-android.zip -d ./android-project/app/libs SDL3-3.2.16.aar
cd android-project
export ANDROID_HOME=/opt/android-sdk
./gradlew assemble

Légyszi, ha nem működik, ne engem üss. A CMake parancsot jórészt az Android Studiós dokumentáció alapján raktam össze + a Gradle által kiírt platform/ABI információkból egészítettem ki. Nem figyeltem, mennyi memóriát eszik, de szerintem nem akart 16 gigát enni, bár tényleg fogalmam sincs, lehet, hogy belül ilyen Xmx-szel indul el a Gradle, de nem láttam erre utaló infót.

A fordítás gyors és eseménytelen volt.

PS: Hogy egyértelmű legyen: ebben a projektben a CMake -s build csak az SDL-es bináris részt buildeli meg, semmi mást. Az APK előállításához a helloworld-ös repóban mindenképpen kell a Gradle-ös build, ez - legalábbis ebben a repóban - nem egy megkerülhető függőség.

Ha bármilyen köztes fájl kell a repóból, elküldöm szívesen csak szólj.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Köszönöm, erről van szó!

Megpróbálnád az sdl2_on_android repót is? Az a gradle mentes.

Egyébként csak az armv8a architektúra kell, az az AArch64 tulajdonképpen (átkeresztelték kóbor apácák megtévesztése végett).

ebben a projektben a CMake -s build csak az SDL-es bináris részt buildeli meg, semmi mást.

Igen, ha megvan a main()-t tartalmazó .so-d, akkor egyáltalán nem kell. Ezt már sikerült az egésztől függetlenül lefordítanom az NDK-beli Clang-gal, úgyhogy biztos kihagyható simán a CMake. (Egyetlen C forrásfájlt kell csak fordítani.)

Az APK előállításához a helloworld-ös repóban mindenképpen kell a Gradle-ös build,

Azért ezt még meglátjuk, én azért megpróbálnám kiiktatni ezt is. Szerintem átalakítható a fentebb linkelt repó mintájára ez is (az ant-os, de végső soron GNU/Make-re akarom átírni az egészet).

Ha bármilyen köztes fájl kell a repóból, elküldöm szívesen csak szólj.

Köszönöm, az R.java érdekelne csak. Illetve ha van részletes kimenete a gradlew-nek a lefuttatott paranccsokkal, az még nagyon nagyon hasznos lenne. Ahogy beraktad a kiadott parancsokat, az nagyon jó és hasznos infó!

Köszönöm az eddigi segítséget!!!

Bocsánat, kicsit hektikus ez a hét, részben azért, mert két hete tart (végigdolgoztam a hétvégét is).

Szóval, elöljáróban: a helloworldös cucc nem generált R.java / R.class fájlt. Nem tudom, miért.

Most nézem a Gradle nélküli repót.

Update:

Nem sikerült lebuildelni, és ennyire már nem értek a C fejlesztéshez, hogy értsem, mi fáj neki ennyire.

Ami változott a repóban, mert enélkül nem indultunk el:

diff --git a/android-project/jni/Application.mk b/android-project/jni/Application.mk
index e5b5079..e254413 100644
--- a/android-project/jni/Application.mk
+++ b/android-project/jni/Application.mk
@@ -3,4 +3,4 @@
 # See CPLUSPLUS-SUPPORT.html in the NDK documentation for more information
 # APP_STL := stlport_static 
 
-APP_ABI := armeabi armeabi-v7a x86
+APP_ABI := arm64-v8a
diff --git a/android-project/project.properties b/android-project/project.properties
index 0840b4a..ea365c1 100644
--- a/android-project/project.properties
+++ b/android-project/project.properties
@@ -11,4 +11,4 @@
 #proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
 
 # Project target.
-target=android-15
+target=android-35

A hibaüzenet, amit kaptam:

/opt/android-sdk/ndk/28.2.13676358/ndk-build                                                                                                                                         (ruby-3.3.4)
Android NDK: Found platform level in ./project.properties. Setting APP_PLATFORM to android-35.    
Android NDK: WARNING: APP_PLATFORM android-35 is higher than android:minSdkVersion 10 in ./AndroidManifest.xml. NDK binaries will *not* be compatible with devices older than android-35. See https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md for more information.    
[arm64-v8a] Compile        : SDL2 <= SDL_assert.c
[arm64-v8a] Compile        : SDL2 <= SDL.c
[arm64-v8a] Compile        : SDL2 <= SDL_error.c
[arm64-v8a] Compile        : SDL2 <= SDL_hints.c
[arm64-v8a] Compile        : SDL2 <= SDL_log.c
[arm64-v8a] Compile        : SDL2 <= SDL_audio.c
[arm64-v8a] Compile        : SDL2 <= SDL_audiocvt.c
[arm64-v8a] Compile        : SDL2 <= SDL_audiodev.c
[arm64-v8a] Compile        : SDL2 <= SDL_audiotypecvt.c
[arm64-v8a] Compile        : SDL2 <= SDL_mixer.c
[arm64-v8a] Compile        : SDL2 <= SDL_wave.c
[arm64-v8a] Compile        : SDL2 <= SDL_androidaudio.c
[arm64-v8a] Compile        : SDL2 <= SDL_dummyaudio.c
[arm64-v8a] Compile        : SDL2 <= SDL_atomic.c
[arm64-v8a] Compile        : SDL2 <= SDL_spinlock.c
[arm64-v8a] Compile        : SDL2 <= SDL_android.c
[arm64-v8a] Compile        : SDL2 <= SDL_cpuinfo.c
[arm64-v8a] Compile        : SDL2 <= SDL_dynapi.c
[arm64-v8a] Compile        : SDL2 <= SDL_clipboardevents.c
[arm64-v8a] Compile        : SDL2 <= SDL_dropevents.c
[arm64-v8a] Compile        : SDL2 <= SDL_events.c
[arm64-v8a] Compile        : SDL2 <= SDL_gesture.c
[arm64-v8a] Compile        : SDL2 <= SDL_keyboard.c
[arm64-v8a] Compile        : SDL2 <= SDL_mouse.c
[arm64-v8a] Compile        : SDL2 <= SDL_quit.c
[arm64-v8a] Compile        : SDL2 <= SDL_touch.c
[arm64-v8a] Compile        : SDL2 <= SDL_windowevents.c
[arm64-v8a] Compile        : SDL2 <= SDL_rwops.c
[arm64-v8a] Compile        : SDL2 <= SDL_haptic.c
[arm64-v8a] Compile        : SDL2 <= SDL_syshaptic.c
[arm64-v8a] Compile        : SDL2 <= SDL_gamecontroller.c
[arm64-v8a] Compile        : SDL2 <= SDL_joystick.c
[arm64-v8a] Compile        : SDL2 <= SDL_sysjoystick.c
[arm64-v8a] Compile        : SDL2 <= SDL_sysloadso.c
[arm64-v8a] Compile        : SDL2 <= SDL_power.c
[arm64-v8a] Compile        : SDL2 <= SDL_syspower.c
[arm64-v8a] Compile        : SDL2 <= SDL_sysfilesystem.c
[arm64-v8a] Compile        : SDL2 <= SDL_d3dmath.c
[arm64-v8a] Compile        : SDL2 <= SDL_render.c
[arm64-v8a] Compile        : SDL2 <= SDL_yuv_mmx.c
[arm64-v8a] Compile        : SDL2 <= SDL_yuv_sw.c
[arm64-v8a] Compile        : SDL2 <= SDL_render_d3d11.c
[arm64-v8a] Compile        : SDL2 <= SDL_render_d3d.c
[arm64-v8a] Compile        : SDL2 <= SDL_render_gles2.c
In file included from jni/SDL/src/render/opengles2/SDL_render_gles2.c:277:
jni/SDL/src/render/opengles2/SDL_gles2funcs.h:56:1: error: incompatible function pointer types assigning to 'void (*)(GLuint, GLsizei, const char **, const GLint *)' (aka 'void (*)(unsigned int, int, const char **, const int *)') from 'void (GLuint, GLsizei, const GLchar *const *, const GLint *)' (aka 'void (unsigned int, int, const char *const *, const int *)') [-Wincompatible-function-pointer-types]
   56 | SDL_PROC(void, glShaderSource, (GLuint, GLsizei, const char **, const GLint *))
      | ^              ~~~~~~~~~~~~~~
jni/SDL/src/render/opengles2/SDL_render_gles2.c:266:45: note: expanded from macro 'SDL_PROC'
  266 | #define SDL_PROC(ret,func,params) data->func=func;
      |                                             ^~~~~
jni/SDL/src/render/opengles2/SDL_render_gles2.c:800:26: warning: address of array 'shader->instances' will always evaluate to 'true' [-Wpointer-bool-conversion]
  800 |             if (!shader->instances)
      |                 ~~~~~~~~~^~~~~~~~~
1 warning and 1 error generated.
make: *** [/opt/android-sdk/ndk/28.2.13676358/build/core/build-binary.mk:420: obj/local/arm64-v8a/objs/SDL2/src/render/opengles2/SDL_render_gles2.o] Error 1

Verdikt: Az eredeti projektnek a project.settings alapján Android 15 volt a target platformja, és ARMv7. Nagyon is elképzelhetőnek tartom, hogy a projekt inkompatibilis az újabb Android verziókkal, a nálam összerakott NDK-SDK verziópárooskban viszont nem volt _ennyire_ régi Android. Mivel helyszűkében vagyok diskben (nekem meg ez a korlátom), nem tudok ennyi NDK/SDK/Google API/Emulator verziót feltelepíteni, és most nem tudok disket bővíteni. Emiatt ezt a feltételezést nem tudom igazolni.

Viszont! Az Android 15 fordítás biztos, hogy kevesebb memóriát evett, mert kb az volt az utolsó platform, amivel még foglalkoztam forrásból forgatás címszó alatt, és akkor még egy bádogdoboz volt a gépem a mostanihoz képest (asszem up to 16G RAM-om volt). Azt elvileg te is meg tudod buildelni ARMv7-re. Azt megpróbálhatnád még (és az APP_EABI-ben is csak 1 darab ABI-t hagyj).

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Az Android 15 fordítás biztos, hogy kevesebb memóriát evett, mert kb az volt az utolsó platform, amivel még foglalkoztam forrásból forgatás címszó alatt, és akkor még egy bádogdoboz volt a gépem a mostanihoz képest

Valamit keversz, az Android 15 az egy éve jött ki, alig van még elterjedve (API level 35). Az API level 15 kb. sose létezett ebben a formában, az egy bugfix release volt.

https://iotguru.cloud

Valóban rosszul fogalmaztam, az API level 15-re gondoltam, ami az Android 4.0.3 volt. Mentségemre szóljon, hogy 6-10 éves emlékeket rángatok itt elő.

> kb. sose létezett ebben a formában

Hát, akkor a hivatalos oldal rosszul tudja, kérlek írj nekik egy levelet, hogy ne írjanak hülyeségeket: https://developer.android.com/tools/releases/platforms#4.0.3

(vagy le is szállhatnál néha a magas lóról, emlékszem, hogy dolgoztam ezzel a platform verzióval, még SDK is volt hozzá külön meg minden eszköz, ami ehhez kellett, teljesen ful lfeatured API level release volt - bár ez valóban nem járt Android verzióemeléssel, ettől nem létezett kevésbé)

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Valóban rosszul fogalmaztam, az API level 15-re gondoltam, ami az Android 4.0.3 volt. Mentségemre szóljon, hogy 6-10 éves emlékeket rángatok itt elő.

A Gradle 2014 decemberében jelent meg egyáltalán, mint Android build eszköz, API level 20 (Android 5) előtt ezért volt mindenféle build módszer, azóta egységesen Gradle van használva erre, meg is halt az összes egyéb módszer, az is, amit próbáltok hegeszteni. 

Hát, akkor a hivatalos oldal rosszul tudja, kérlek írj nekik egy levelet, hogy ne írjanak hülyeségeket: https://developer.android.com/tools/releases/platforms#4.0.3

Attól még sose létezett ebben a formájában, egy bugfix release volt tablet eszközökre, nem volt értelmes build target fejlesztői környezetben.

https://iotguru.cloud

> meg is halt az összes egyéb módszer, az is, amit próbáltok hegeszteni. 

Imádok elmerülni az alternatív valóságodban, csak néha nehéz követni téged.

Se az Ant, se a (C)Make mint eszköz nem halott, csak by default nem így fordul a cucc. Az informatika nem mágia, lényegében a Gradle se csinál a nap végén semmi extrát, mint meghívja a JAVAC-ot meg a többi toolt, hogy az output előálljon. Ha tudjuk, hogy mit hív meg, meg hogyan akkor ezt akár egy CMake-kel is elő lehet állítani, vagy Ant-tal, vagy egy tetves Bash scripttel, nincs igazán különbség. Amivel a Gradle játszik, az a Classpathok, ezt-azt beinjektál, esetleg van bytekód manipulálás - de ezekre mind megvannak az eszközök az összes ökoszisztémában, csak a Google fejlesztőcsapata azt választotta, hogy a Gradle-t támogatja. Ez minőségileg különbözik attól, hogy a többi módszer halott lenne. Minden amit az Android fejlesztésben csinálnak, csinálják az összes egyéb Java-related ökoszisztémában a JNI használattól kezdve a bytecode compilálásig. Akármennyire is hirdetik, hogy a Dalvik más, mint az Oracle Java, lényegében az is sok szempontból hasonlít egy standard Java implementációra, nem találták fel újra a meleg vizet. Felesleges is lett volna.

Arról nem is beszélve, hogy sosem baj, ha pontosan értjük, mi történik a háttérben, és nem csak katalógusból fejlesztünk, mert amikor valami széttörik a picsába, akkor nem nézünk, mint béka a szatyorban, hanem tudjuk, hogy mi történt a háttérben és mi ment félre. Ehhez néha olyan szentségtörő dolgokat kell csinálni, mint megpróbálni valamit nem a szándékolt módon használni, meg nem tekinteni halottnak dolgokat, amik nem halottak. Persze megértem, hogy ez mennyire nehéz lehet neked.

És hogy miért pofázok én bele mégiscsak amikor itt vagy te, ó nagy bölcs, és elmondtad Szent Igazságodat? Én vagyok az első, aki bevallom, hogy nem értek dolgokhoz, de ez nem jelenti azt, hogy nem is érdekel, hogy hogyan működik és hogyan működhetne másképp. A Gradle-ös cucc is úgy jött létre, hogy valakit rohadtul érdekelt, hogy ezt a sok szart amit kell csinálni a buildelés folyamán vajon lehetne-e Gradle-el csinálni. És nem fogadta el, hogy "á, a Gradle túl új még, biztos nem fog sikerülni". Na, én ilyen vagyok. Nem fogadom el, hogy valami "halott" vagy "nem működik vele". És azt látom, hogy bzt kollega is ilyen. Ha neked ez nem tetszik, akkor tudod abba lehet hagyni a téma követését, de károgni meg hülyeségeket osztani felesleges idejönnöd. 

> Attól még sose létezett ebben a formájában, egy bugfix release volt tablet eszközökre, nem volt értelmes build target fejlesztői környezetben.

Nézd, nem engem kell meggyőznöd, hanem a Google-t. Mondd meg nekik, bár valószínű szembe fognak röhögni. Az, hogy Neked nem kellett soha erre dolgoznod, az nem jelenti azt, hogy ez nem volt valid target. Az meg, hogy mi értelmes és mi nem a te olvasatodban vs a valóságban - hát minimum kérdéses.

Nem mintha a kérdés kontextusában aműgy ez bármennyire is számítana. Ha van rá SDK, lehet rá fordítani. Ha az alap alkalmazás Android 15 API platforrmmal lett fordítva (és azzal lett, oda van írva), akkor akár hiszed akár nem, van olyan ember a világon, aki ezt a stuffot lefordította arra a platformra. Ha neki sikerült, akkor valószínűleg másnak is sikerülni fog. Itt és most nem feltétlenül cél egy működő alkalmazás megalkotása (ezen a ponton még), sokkal fontosabb, hogy megértsük a build eszköz működését. És az is teljesen irreleváns, hogy az Android 15 API platform mennyire támogatott vagy nem támogatott a mai telefonokon (semennyire), mert jelenleg még egy laborkísérlet zajlik, az, hogy előáll egy APK ami a vele mindenben kompatibilis platformú Android oprendszeren (jelen esetben Android 4.0.3-on) elindul, sikerként könyvelhető el.

Meglep, hogy mindezt éles elméd és hatalmas bölcsességed nem vette észre első öt körben.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-