{"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\/news\/google-perehodit-k-publikaczii-koda-android-dvazhdy-v-god","title":{"rendered":"Google ver\u00f6ffentlicht den Android-Code zweimal im Jahr","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Auf der Website des AOSP-Repositorys (Android Open Source Project), in dem der Quellcode der Android-Plattform ver\u00f6ffentlicht wird, ist eine Warnung \u00fcber die \u00c4nderung des Codever\u00f6ffentlichungsschemas erschienen, die besagt, dass neuer Android-Code nur nach dem n\u00e4chsten Release ver\u00f6ffentlicht wird. Der Inhalt des AOSP wird nun nur noch zweimal im Jahr aktualisiert \u2013 im zweiten und vierten Quartal. Zuvor hat Google viertelj\u00e4hrliche Codever\u00f6ffentlichungen praktiziert. <\/p>\n
Anstelle des kontinuierlich aktualisierten Branches \u201eaosp-main\u201c wird empfohlen, den neuen Branch \u201eandroid-latest-release\u201c f\u00fcr die Erstellung von Builds und die Entwicklung von \u00c4nderungen zu verwenden, der dem Zustand der Codebasis des letzten Android-Releases zugeordnet ist (zum Beispiel ist das derzeit \u201eandroid16-qpr2-release\u201c). Diese \u00c4nderung wirkt sich nicht auf die Ver\u00f6ffentlichung von Sicherheitspatches aus, die weiterhin einmal im Monat in den Branches \u201eandroid-security\u201c ver\u00f6ffentlicht werden. <\/p>\n
Als Gr\u00fcnde f\u00fcr die \u00c4nderung werden der Wunsch nach Stabilit\u00e4t der Plattform f\u00fcr das Android-\u00d6kosystem und die Einf\u00fchrung eines trunk-stable Entwicklungsmodells f\u00fcr AOSP genannt, um die Entwicklung von Android zu vereinfachen, die Notwendigkeit der Pflege mehrerer Branches zu beseitigen und Drittentwicklern stabileren und sichereren Code bereitzustellen. Das Vorhandensein getrennter interner und \u00f6ffentlicher Branches f\u00fchrte zu einer Ansammlung von Unterschieden w\u00e4hrend der Entwicklung eines Releases und zu einem erh\u00f6hten Ressourcenaufwand f\u00fcr die Synchronisierung von \u00c4nderungen und das Zusammenf\u00fchren von Patches zwischen verschiedenen Branches. <\/p>\n
Im vergangenen Jahr schr\u00e4nkte Google die \u00dcbertragung von \u00c4nderungen, die spezifisch f\u00fcr Pixel-Ger\u00e4te sind, in AOSP ein und wechselte zu einer geschlossenen Entwicklung von Releases ohne Ver\u00f6ffentlichung Zwischenberichte im AOSP. Zuvor wurde die Plattform unter Verwendung eines gemischten Entwicklungsmodells weiterentwickelt, bei dem einige Komponenten von Android, wie der Bluetooth-Stack, das Build-System, die Update-Engine und das Virtualisierungs-Framework, \u00f6ffentlich entwickelt wurden, w\u00e4hrend andere zun\u00e4chst in einem internen Repository erstellt wurden und nach dem Release offengelegt wurden. Gem\u00e4\u00df dem neuen Modell wird bei der Entwicklung ausschlie\u00dflich ein interner Branch verwendet, dessen Code an die Releases im AOSP-Repository gebunden wird. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"