Zarządzanie oprogramowaniem na Androida

Projekt Android Open Source Project (AOSP) utrzymuje kompletny stos oprogramowania, który może być przenoszony przez producentów OEM i innych twórców urządzeń i uruchamiany na ich własnym sprzęcie. Aby utrzymać jakość Androida, firma Google zatrudniła pełnoetatowych inżynierów, menedżerów produktów, projektantów interfejsu użytkownika, testerów zapewnienia jakości i wszystkie inne osoby wymagane do wprowadzenia nowoczesnych urządzeń na rynek.

W związku z tym utrzymujemy szereg linii kodu, aby wyraźnie oddzielić obecną stabilną wersję Androida od niestabilnej wersji eksperymentalnej. Wprowadzamy administrację open source i utrzymanie linii kodowych Androida w szerszy cykl rozwoju produktu.

Zarządzanie kodem AOSP

Poniższy wykres przedstawia koncepcje stojące za zarządzaniem kodem AOSP i jego wydaniami.

1. W każdej chwili dostępna jest najnowsza wersja platformy Android. Zwykle przybiera to formę gałęzi na drzewie.
2. Twórcy urządzeń i współpracownicy pracują z najnowszą wersją, naprawiając błędy, uruchamiając nowe urządzenia, eksperymentując z nowymi funkcjami i tak dalej.
3. Równolegle Google pracuje wewnętrznie nad kolejną wersją platformy i frameworku Android zgodnie z potrzebami i celami produktu. Opracowujemy kolejną wersję Androida, współpracując z partnerem zajmującym się urządzeniami nad flagowym urządzeniem, którego specyfikacje zostały wybrane tak, aby popchnąć Androida w kierunku, w którym naszym zdaniem powinien zmierzać.
4. Gdy wersja n+1 będzie gotowa, zostanie opublikowana w publicznym drzewie źródeł i stanie się najnowszą wersją.

Warunki i zastrzeżenia

• Wydanie odpowiada formalnej wersji platformy Android, takiej jak 1.5 lub 8.1. Wersja platformy odpowiada wersji w polu SdkVersion plików AndroidManifest.xml i zdefiniowanej w ramach frameworks/base/api w drzewie źródłowym.
• Projekt nadrzędny to projekt typu open source, z którego stos Androida pobiera kod. Oprócz projektów takich jak jądro Linuksa i WebKit, kontynuujemy migrację niektórych półautonomicznych projektów na Androida, takich jak ART, narzędzia Android SDK i Bionic, aby działały jako projekty nadrzędne. Generalnie projekty te są opracowywane w całości w drzewie publicznym. W przypadku niektórych projektów typu upstream deweloperzy wnoszą bezpośredni wkład w projekt typu upstream. Aby uzyskać szczegółowe informacje, zobacz Projekty upstream . W obu przypadkach migawki są okresowo pobierane do wydań.
• Przez cały czas linia kodu wydania (która może składać się z więcej niż jednej gałęzi w git) jest uważana za jedyny kanoniczny kod źródłowy dla danej wersji platformy Android. Producenci OEM i inne grupy tworzące urządzenia powinny pobierać wyłącznie z gałęzi wydania.
• Ustalono eksperymentalne kody, aby wychwytywać zmiany wprowadzane przez społeczność, aby można było je powtarzać z myślą o zapewnieniu stabilności.
• Zmiany, które okażą się stabilne, zostaną ostatecznie przeniesione do gałęzi wydania. Dotyczy to wyłącznie poprawek błędów, ulepszeń aplikacji i innych zmian, które nie mają wpływu na interfejsy API platformy.
• W razie potrzeby zmiany są pobierane do gałęzi wersji z projektów nadrzędnych (w tym projektów nadrzędnych dla systemu Android).
• Wersja n+1 (kolejna główna wersja frameworka i interfejsów API platformy) jest opracowywana wewnętrznie przez Google. Aby uzyskać szczegółowe informacje, zobacz Prywatne linie kodowe .
• W razie potrzeby zmiany są pobierane z gałęzi nadrzędnych, wydań i eksperymentalnych do gałęzi prywatnej Google.
• Gdy interfejsy API platformy dla następnej wersji zostaną ustabilizowane i w pełni przetestowane, Google wypuści kolejną wersję platformy (w szczególności nową SdkVersion ). Odpowiada to wewnętrznemu kodowi, który stał się gałęzią wydań publicznych, oraz nowej, obecnej linii kodowej platformy.
• Kiedy wycinana jest nowa wersja platformy, jednocześnie tworzona jest odpowiednia eksperymentalna linia kodu.

Prywatne linie kodowe

Powyższa strategia zarządzania źródłami obejmuje linię kodu, którą Google zachowuje jako prywatną, aby skupić uwagę na bieżącej publicznej wersji Androida.

Producenci OEM i inni producenci urządzeń naturalnie chcą dostarczać urządzenia z najnowszą wersją Androida. Podobnie twórcy aplikacji nie chcą mieć do czynienia z większą liczbą wersji platformy, niż jest to konieczne. Tymczasem Google pozostaje odpowiedzialny za strategiczny kierunek rozwoju Androida jako platformy i produktu. Nasze podejście koncentruje się na niewielkiej liczbie flagowych urządzeń w celu obsługi funkcji przy jednoczesnym zapewnieniu ochrony własności intelektualnej związanej z Androidem.

W rezultacie Google często jest w posiadaniu poufnych informacji od osób trzecich i musi powstrzymywać się od ujawniania poufnych funkcji do czasu zapewnienia odpowiednich zabezpieczeń. Ponadto istnieje realne ryzyko dla platformy, jeśli jednocześnie istnieje zbyt wiele wersji platformy. Z tych powodów zorganizowaliśmy projekt open source (uwzględniając wkład stron trzecich) tak, aby skupiał się na obecnie publicznej, stabilnej wersji Androida. Głęboki rozwój kolejnej wersji platformy odbywa się w trybie prywatnym, dopóki nie będzie ona gotowa do wydania oficjalnego.

Zdajemy sobie sprawę, że wielu autorów nie zgadza się z tym podejściem i szanujemy ich punkt widzenia. Jednak takie podejście uważamy za najlepsze i postanowiliśmy je wdrożyć w przypadku Androida.