{"id":153445,"date":"2026-01-07T11:11:58","date_gmt":"2026-01-07T09:11:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/google-perehodit-k-publikaczii-koda-android-dvazhdy-v-god"},"modified":"2026-01-07T11:11:58","modified_gmt":"2026-01-07T09:11:58","slug":"google-perehodit-k-publikaczii-koda-android-dvazhdy-v-god","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/google-perehodit-k-publikaczii-koda-android-dvazhdy-v-god","title":{"rendered":"Google wechselt zu einer halbj\u00e4hrlichen Ver\u00f6ffentlichung des Android-Codes.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Auf der Website des AOSP (Android Open Source Project), wo der Quellcode der Android-Plattform bereitgestellt wird, wurde eine Warnung bez\u00fcglich einer \u00c4nderung des Ver\u00f6ffentlichungsschemas ver\u00f6ffentlicht. Dies bedeutet, dass neuer Android-Code nur nach dem n\u00e4chsten Release bereitgestellt wird. Der Inhalt von AOSP wird k\u00fcnftig nur noch zweimal j\u00e4hrlich aktualisiert - im zweiten und vierten Quartal. Zuvor hatte Google den Code viertelj\u00e4hrlich ver\u00f6ffentlicht. <\/p>\n
Statt des kontinuierlich aktualisierten Zweigs \u201eaosp-main\u201c f\u00fcr den Bau von Versionen und die Entwicklung von \u00c4nderungen wird empfohlen, den neuen Zweig \u201eandroid-latest-release\u201c zu verwenden, der mit dem Status der Codebasis der neuesten Android-Version identifiziert wird (zum Beispiel ist dies derzeit \u201eandroid16-qpr2-release\u201c). Diese \u00c4nderung hat keinen Einfluss auf die Ver\u00f6ffentlichung von Sicherheits-Patches, die weiterhin einmal im Monat in den Zweigen \u201eandroid-security\u201c bereitgestellt werden. <\/p>\n
Die Gr\u00fcnde f\u00fcr die \u00c4nderungen sind der Wunsch, Plattformstabilit\u00e4t f\u00fcr das Android-\u00d6kosystem zu gew\u00e4hrleisten und AOSP auf ein trunk-stable Entwicklungsmodell umzustellen. Dies soll die Android-Entwicklung vereinfachen, die Notwendigkeit zur Unterst\u00fctzung mehrerer Branches beseitigen und externen Entwicklern stabileren und sichereren Code bereitstellen. Die Separierung von internen und \u00f6ffentlichen Branches f\u00fchrte zu einem Anstieg der Unterschiede w\u00e4hrend der Release-Entwicklung und erforderte Ressourcen f\u00fcr die Synchronisierung von \u00c4nderungen und das Zusammenf\u00fchren von Patches zwischen verschiedenen Branches. <\/p>\n
Im vergangenen Jahr hat Google die \u00dcbertragung ger\u00e4tespezifischer \u00c4nderungen f\u00fcr AOSP bei Pixel-Ger\u00e4ten eingeschr\u00e4nkt und ist zu einer Entwicklung von Releases hinter verschlossenen T\u00fcren \u00fcbergegangen, ohne Zwischenst\u00e4nde im AOSP zu ver\u00f6ffentlichen. Zuvor wurde die Plattform unter Verwendung eines gemischten Entwicklungsmodells betrieben, bei dem einige Android-Komponenten, wie der Bluetooth-Stack, das Build-System, die Update-Engine und das Virtualisierungs-Framework, \u00f6ffentlich entwickelt wurden, w\u00e4hrend andere zu Beginn in einem internen Repository erstellt und nach der Ver\u00f6ffentlichung offengelegt wurden. Nach dem neuen Modell wird nur noch der interne Branch f\u00fcr die Entwicklung verwendet, dessen Code in Bezug auf die Releases in das AOSP-Repository \u00fcbertragen wird. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"