Jak czytam to co niektórzy tutaj wypisują to zaczynam się zastanawiać czy ktokolwiek tutaj ma jakiekolwiek pojęcie o prawidłowym budowaniu AOSP'a, a może to po prostu ja wiem za dużo 😉.
Do zbudowania ROMu ze źródeł potrzebujesz device tree, które składa się z co najmniej 2 repo - głównego repo danego urządzenia - android_device_VENDOR_MODEL, np. android_device_samsung_i9300, oraz repo proprietary, czyli blobów, pod hasłem proprietary_vendor_VENDOR, np. proprietary_vendor_samsung, w którym to będzie podfolder z twoim urządzeniem (i9300).
To jest minimum, zakładające że o danym urządzeniu nie wiadomo nic, a kernel nawet nie ma źródeł tylko pełni rolę bloba podobnie co reszta potrzebnego firmware'u. W praktyce urządzenie dziedziczy po wspólnym dla danego SoCa repo, np. android_device_samsung_smdk4412-common (dla Exynosa 4412) oraz posiada źródła kernela, np. android_kernel_samsung_smdk4412, które to z kolei może być kernelem typu unified (wspiera wszystkie urządzenia na danym SoCu), lub kernelem typu device (wspiera konkretne urządzenie i nic więcej).
Samo stworzenie, nawet w poprawny sposób potrzebnych repo nie gwarantuje jeszcze absolutnie niczego, bo żeby dodać wsparcie dla danego urządzenia czy to w AOSPie, CMie czy jakimkolwiek innym ROMie to trzeba się znać, a nie klepać tutoriale z googla i sugerować się kilkoma szarlatanami na tym forum, którzy portują romy z innych urządzeń i mówią, że wszystko gra bo im "działa" 😉.
Prawda jest taka, że to jak łatwe lub jak trudne będzie dodanie urządzenia do AOSPa określa bardzo dużo zależności:
1. SoC. Jeśli wyszło już jakieś urządzenie oparte o dany SoC, i ma już co najmniej minimalne wsparcie, to duża szansa jest, że małym kosztem będziesz w stanie doprowadzić urządzenie co najmniej do stanu "bootuje".
2. Architektura. Przykładowo mój ukochany Exynos 4412 jest jedną z najgorszych architektur jakie kiedykolwiek powstały, co oznacza że wymaga niezliczonej ilości hacków, workaroundów i dodatkowej pracy, żeby postawić go na nogi. Czym gorsza architektura tym więcej blobów potrzeba i tym więcej trzeba zreverse-engineerować.
3. Polityka producenta. Producent może wydawać pełne źródła (userspace + kernel) jak np. Sony, może wydawać minimalne źródła wymuszane przez licencję (kernel) jak np. Samsung, albo nie wydawać absolutnie niczego i mieć developerów głęboko w poważaniu, jak np. MicroMax. Oczywiście w tym ostatnim przypadku jest najciężej.
Do samego drzewa danego urządzenia mogą dochodzić potrzebne hacki/workaroundy/funkcje, które muszą być również zaimplementowane "wyżej", np. w natywnym frameworku. Przykład . Ponownie, mając znaną i już wspieraną architekturę jest duża szansa, że nic poza device tree i kernelem nie będzie potrzebne, ale każde urządzenie jest inne i do każdego wsparcie dodaje się inaczej.
Jeśli jeszcze się nie zraziłeś tym co napisałem, to podpowiem że samo Google oferuje przykładowe drzewo pod hasłem android_device_sample, a także można się wzorować na już jakimś istniejącym jeśli potrzeba konkretnej rzeczy.
Pierwszym krokiem po stworzeniu device tree jest próba skompilowania bootującego i działającego custom recovery, czy to CWM, TWRP czy jakiekolwiek inne. Czysto teoretycznie do działania custom recovery potrzeba TYLKO kernela (zImage) oraz poprawnego device tree, np. fstaba. To jest pierwszy krok, jeśli kernel z jakiegoś powodu nie działa lub się nie kompiluje to tym bardziej nie skompiluje się reszta romu. Można w dość prosty sposób zbudować samo recovery, bez potrzeby budowania całego ROMu:
lunch cm_DEVICE-userdebug # Gdzie DEVICE to urządzenie, które zdefiniowałeś w tree, CM oczywiście trzeba zastąpić aosp dla AOSP'a, omni dla Omni itd.
make recoveryimage -jX # Gdzie X to liczba threadów na twoim CPU
Powodzenia, o ile jeszcze masz chęci 😃.