Sailfish OS portuvačky na OnePlus 7T Pro

[Morc]

Zdalo by sa, že tento príspevek bude vyprávať o hotdog porte. Prd.
Michał z VerdandiTeamu ma povereu aktivitou "sprav port pre Motorolu Moto G84 5G a pomóž komunite".
Ohrabal som vyše rok a pol starú dokumentáciu, zas mám nové poznatky. (z kerých sa volakeré týkajú aj toho, že toto je Android 15 port namísto Android 10 portu)

---

Poznatek č.1. | pridávaní middleware balíčkov z iného branchu:

Code: Select all

cd hybris/mw
git clone https://github.com/mer-hybris/ngfd-plugin-droid-vibrator.git -b aidl
cd $ANDROID_ROOT
rpm/dhd/helpers/build_packages.sh --mw=https://github.com/mer-hybris/ngfd-plugin-droid-vibrator.git

Svojim spósobom hovorí za seba, zas netreba tam extra hovoriť veci navyše. Celá podstata bola vybuilduvať celý ten package a zebrať si z neho ngfd-plugin-binder-vibrator pre Moto port kerý je totižto súčasťou toho špecifického aidl branchu a jako dodatočný rpm spec z toho repa.

Poprípade existuje alternatíva kedy sa dá builduvať čisto len špecifický spec z repa, jak napríklad pri sensorfw-aidl kerý treba pre správne funguvaní senzorov na tomto porte:

Code: Select all

rpm/dhd/helpers/build_packages.sh --mw=https://github.com/sailfishos/sensorfw --spec=rpm/sensorfw-qt5-binder.spec

---

Poznatek č.2. | definitívne opravení balíčkuvača:
Michał má ve svojom droid-config-${zarádení} repozitári zložku kickstart kde je upravený pack_package-droid-updater skript kerý sa používa pre alternatívne generuvaní flashuvacého ZIPu.
Šecky úpravy tohoto skriptu mosá pokračuvať configs rebuildom: rpm/dhd/helpers/build_packages.sh --configs

Póvodne tento flashuvací ZIP vyzíra tak, že má v sebe .tar.bz2 namísto .tar.gz (TWRP varianta) alebo userdata.img (modernejšá LineageOS recovery varianta)
Na to, aby tento kickstart skript ale vóbec volakedy funguval treba načať súbor rpm/dhd/helpers/build_packages.sh v kerom treba nájsť jedinú zmienku s .tar.bz2 a zameniť ju za .tar.gz alebo za .tar (polla toho čo komu treba) a potom má skript vačšú šancu funguvať.

Ďalej si to vyžaduje buď už iba sb2 -R zypper install zip cpio alebo zypper install zip cpio? (toto mosím ešte zistiť napresno) a odťál by to malo už lítať aj samé.

Upozornení: tento skript ví krachuvať celkom nahovno v prípade že v build zložke je už obsah. nepýtajte sa ma jak vím..

---

Poznatek č.3. | Jak na ZIP s vendor_bootom:
Toto je vellajšá vec, droid-hal-${zarádení}.spec potrebuje v sebe

Code: Select all

%define enable_kernel_update 1
%define enable_dtbo_update 1
%define enable_vendor_boot_update 1

Potom to pri rpm/dhd/helpers/build_packages.sh --mic konečne zakomponuje aj vendor_boot.img kerý "treba" pri tom druhom flashuvacom skripte. (V realite ten vendor_boot ostáva taký jak z toho LineageOS buildu, ale preventívne ho flashujeme aby sa volačo nedoonďalo)

---

Poznatek č.4. | Prečo mi to nebootuje a de zehnať linkerconfig:
Jeden z potenciálnych dóvodov prečo droid-hal neste bootuvať je potenciálna vec, kedy /system/bin/logcat vykrikuje že neví nájsť túto knižnicu, hentú knižnicu, bla, bla.
Potenciálne riešení je vysymlinkuvať obsahy šeckých /apex/<meno apexu>/lib a lib64 zložék do /odm/lib a /odm/lib64, ale tak sa veci NE-RO-BÁ.

Reálne riešení je teda zistiť, že prečo linkerconfig (kerý sa v logoch dá nájsť ťéž, len je tam schovatý) neví nájsť, neví pustiť, neví existuvať.
Prvý problém je to, že by to voláky linkerconfig pustilo keby existuval.
Pri builduvaní v ubu-chroot Android prostredí sa dá zistiť že či sa vybuilduval, stačí spraviť bežné rošošo setupenv, breakfast a potom pustiť make a jako parameter dať linkerconfig. Lenže to je vec, kerá 100% bude už existuvať.

Dóvod toho, že linkerconfig neni na svojom míste je ten, že keď človek pustí "find out/target/product -name linkerconfig" tak dojde na to že potenciálny zoznam súborov je takýto

Code: Select all

out/target/product/bangkk/recovery/root/linkerconfig
out/target/product/bangkk/symbols/apex/com.android.runtime/bin/linkerconfig
out/target/product/bangkk/root/linkerconfig
out/target/product/bangkk/obj/EXECUTABLES/linkerconfig.com.android.runtime_intermediates/linkerconfig

Šecko v porádku až na to, že ten aj keď tam apexový linkerconfig je, je to iba symbol, executable je jako objekt ale neni tam, kde by sa mal nachádzať. Reálna cesta k nemu by mala by vyzírať zhruba takto: out/target/product/${zarádení}/apex/com.android.runtime/bin/linkerconfig

Pokračuvaní riešeňá je v tom, že buď treba vyhodiť volakeré patche a dúfať že to pomóže, alebo treba otvoriť rpm/dhd/droid-hal-device.inc, tam v ňom nájsť rádky s týmto obsahom:

Code: Select all

if [ -f %{android_root}/out/target/product/%{device}/apex/com.android.runtime/bin/linkerconfig ]; then
    cp -a \
        %{android_root}/out/target/product/%{device}/apex/com.android.runtime/bin/linkerconfig \
        $RPM_BUILD_ROOT%{_libexecdir}/droid-hybris/system/bin/
fi

Títo rádky skopíruvať, naduplikuvať a prepísať v nich apex/com.android.runtime/bin/linkerconfig na obj/EXECUTABLES/linkerconfig.com.android.runtime_intermediates/linkerconfig kerý samozrejme v našom builde existuje jak je videť na zozname hore kúštek vyšší.
Po tomto samozrejme treba už iba vybuilduvať hal s klasickým rpm/dhd/helpers/build_packages.sh --droid-hal a malo by byť oficiálne po probléme.

---

Poznatek č.5. | Najlepšá "dokumentácia" je build na OBS:
Zopakujem sa, najlepšá "dokumentácia" je build na OBS. Zas né na tej vyzílačke, ide o ten open build system service zázrak čo majú. Celá tá šaškárňa s middleware balíčkami je taký bordel-chaos, že človek vlastne neví jaký build používa customove balíčky a prečo a jaké.
Tak to je za normálnych okolností ak to je lokálny build, kedy takéto náležitosti po čase zabunne aj ten, kto si build spraveu (samozrejme dá sa to vyčuchať v hybris/mw/)

Ak ale teda človek narve build na OBS, tak najlepší je poznať a videť zoznam balíčkov odťál, lebo tí zmenené alebo alternatívne prídavné treba k tomu, aby OBS vóbec vyskladalo ten ostatek, ináč sa ťažko robá buildy a veci, ak neni z čoho.
Názorný príklad: build.sailfishos.org/project/show/nemo:testing:hw:motorola:miami