Yeniden oluşturma isteğinde bulunma

Yeniden derleme, GKI çekirdeğinin herkese açık sürümünden sonra bir ikilinin yeniden birleştirilmesi, yeniden oluşturulması, yeniden test edilmesi ve yeniden sertifikalandırılması işlemidir.

Yeniden oynatma isteğinde bulunmadan önce aşağıdaki yönergeleri göz önünde bulundurun.

Uygunluk ve yaşam döngüsü

  • Zamanlama: Yalnızca üç aylık bir derlemenin ilk herkese açık sürümü yayınlandıktan sonra yayın dallarında yeniden döndürme isteğinde bulunabilirsiniz. İlk herkese açık sürümden sonraki en fazla altı ay boyunca yalnızca belirli bir sürüm dalı için satıcı kancaları veya diğer özelliklerle ilgili respin isteğinde bulunabilirsiniz.
  • Güvenlik ve LTS: Altı ay sonra dallar, yalnızca Android Güvenlik Bülteni'nde (ASB) belirtilen güvenlik yamaları veya kritik hata düzeltmeleri için yeniden oluşturulmaya uygun olur.
  • Desteğin sonlandırılması: Android Güvenlik Bülteni (ASB) tarafından tanımlanan LTS koşulları, dalın uygun olmamasına neden olduğunda dalın desteği sonlandırılır. Kullanımdan kaldırılan dallar için yeniden derleme istekleri kabul edilmez.
    • Belirli bir GKI sürüm dalının desteğinin sonlandırılma tarihi, Sürümler bölümündeki üç aylık GKI yayınlanan derleme notlarında yer alır. Örneğin, Eylül 2025 sürümü, Mart 2027'ye kadar yeniden döndürme için desteklenir. Bu tarih, Eylül 2025'te yayınlanmaya başlayan sürümler için LTS 2.0 çekirdek sürümünün 18 aylık kullanım ömrünü yansıtır (Eylül 2025'ten önceki sürümlerin kullanım ömrü 12 aydı).
  • Kapsam: Yalnızca acil hata düzeltmeleri, sembol listesi güncellemeleri veya mevcut bir özelliği düzeltmek için yama uygulamak amacıyla yeniden derleme isteğinde bulunun.

Yama gönderme standartları

Yeniden derleme isteği işleme için Beklenen Standart Çözüm Süresi'ne (ESRT) uyulması amacıyla, yayın dalına gönderilen tüm yamaların aşağıdaki teknik kurallara uyması gerekir.

Veri kaynağı ve seçici alıntılar

  • Öncelikle geliştirme dalı: Üç aylık sürüm dalına eklenecek tüm yamalar, ana GKI geliştirme dalıyla birleştirilmiş olmalıdır. Örneğin, android15-6.6-2025-08'nın yeniden oluşturulması için bir yama gerekiyorsa bu yama android15-6.6 ile birleştirilmiş olmalıdır.
  • Temiz seçme: Yamaları doğrudan geliştirme dalından seçmelisiniz. Diğer yayın dallarından seçme yapmayın (örneğin, 2025-08 ile 2025-09 arasında seçim yapmayın). Bu, geliştirme dalındaki sürümle tutarsız yazar veya commit bilgilerine neden olabilir. Tutarsız bilgiler içeren yamalar kabul edilmez.
  • Meta verileri koru: Orijinal commit meta verilerini (örneğin, yazar, orijinal zaman damgası) koruyun. Meta verileri korumak için git cherry-pick -x kullanın.

Commit zinciri

  • Sıralı zincir: Yeniden döndürme isteği birden fazla yama içeriyorsa bunları tek bir sıralı zincir olarak yükleyin.
  • ABI ve KMI yerleşimi: Birden çok yamalı yeniden derleme, çekirdek modülü arayüzü (KMI) ve uygulama ikili arayüzü (ABI) güncellemelerini (ör. sembol listesi değişiklikleri veya XML/STG dosyası güncellemeleri) içeriyorsa bu commit'leri commit zincirinin en sonuna yerleştirin.
  • Yeniden temellendirme: Zincirdeki bir üst işlemeyi düzenlerseniz derleme hatalarını önlemek için tüm alt yamaları üst yamanın en son düzeltmesi üzerine yeniden temellendirmeniz gerekir.
  • Çakışma çözümü: Herhangi bir yamada çakışma işaretçisi bulunmadığını doğrulayın.
  • Derleme doğrulama: Tüm commit zinciri başarıyla derlenmelidir.

Zorunlu etiketler

Yeniden oluşturma isteğindeki ilerleme durumu, commit mesajında aşağıdaki etiketler olmadan engellenir:

  • Change-Id: Geliştirme dalı değişikliğinin Change-Id ile aynı olmalıdır.
    • İstisna: Yama, bir LTS güncellemesi kapsamında geliştirme dalıyla birleştirildiyse LTS sürümünün cherry-pick'i olmalı ve UPSTREAM yaması olarak biçimlendirilmelidir. Android Common Kernels'a nasıl yama gönderirim? başlıklı makaleyi inceleyin.
  • Bug (mevcut): Orijinal geliştirme dalı taahhüdündeki mevcut Bug: XYZ etiketleri kaldırılmamalıdır.
  • Bug (respin işlemi): XYZ'nin, mevcut respin işlemi isteğiyle ilişkili hata kimliğine karşılık geldiği yeni bir Bug: XYZ etiketi eklemeniz gerekir.
  • Gerekirse UPSTREAM commit etiketini güncelleyin: Bir CL'yi geliştirme dalından yayın dalına kopyalarken ve CL, UPSTREAM olarak etiketlenmişse aşağıdaki senaryoları göz önünde bulundurun:
    • CL, yayın dalına sorunsuz bir şekilde uygulanıyorsa başka bir işlem yapmanız gerekmez.
    • CL sorunsuz bir şekilde uygulanmıyorsa çakışmaları düzeltin, etiketi BACKPORT olarak güncelleyin ve çakışma çözümü kapsamında yapılan işlemleri belgeleyin. Ana Linux'tan geri bağlantı için şartlar başlıklı makaleyi inceleyin.

Öncelik ve ESRT

GKI ekibinin önceliklendirmesine yardımcı olmak için yeniden oluşturma isteğine öncelik (acil durum) atayın. Bu öncelik, GKI ekibinin iş ortaklarına zamanında daha iyi yardımcı olmasına olanak tanır.

  • Kritik veya zamana duyarlı istekler için önceliği P0 olarak işaretleyin.
  • P0 ve P1 taleplerinde aciliyet gerekçesini de belirtmeniz gerekir.

Aşağıdaki tabloda, hata önceliği ve çözüme ulaşma süresinin (ESRT) eşlemesi verilmiştir:

ÖncelikESRT
P02 iş günü
P15 iş günü
P210 iş günü
P315 iş günü

HDS politikaları

  • Her yayın dalı için ayrı bir yeniden inceleme isteği gönderin.
  • Düzeltildi olarak işaretlenen bir yeniden oluşturma isteğinde değişiklik yaparsanız yeni bir yeniden oluşturma isteği gönderin. Ek değişiklik listeleri (CL) ekleme isteğini yeniden açmayın.
  • Yeniden deneme isteği yanıtınızı gerektiriyorsa ve üç iş günü içinde yanıt vermezseniz öncelik bir seviye düşürülür. Örneğin, P0 önceliği P1'e düşürülür.
  • İki hafta boyunca yanıt vermezseniz hata, Düzeltilmeyecek (Eski) olarak işaretlenir.

Yeniden inceleme isteği gönderme

Aşağıdaki diyagramda respin işlemi gösterilmektedir. Süreç, OEM iş ortağı (siz) yeniden döndürme isteğini gönderdiğinde başlar.

Acil yeniden inceleme süreci Şekil 1. Acil respin işlemi.

Respin isteği göndermek için:

  1. GKI respin işlemi isteği formunu doldurun ve hemen Google'daki ilgili kişiyle iletişime geçin.

    • Bu form, GKI yeniden oluşturma isteği hatası oluşturur.

  2. Yamalarınızı hazırlayın:

    • Yamanın GKI geliştirme dalıyla birleştirildiğini doğrulayın.
    • Yama dosyasını uygun GKI sürüm dalına uygulayın.
    • Yeniden oluşturma isteği kimliğini belirten bir Bug: XYZ etiketi eklemek için özenle seçilmiş yamayı değiştirin.

    Örnek: android16-6.12'dan android16-6.12-2025-12'a bir CL seçmek için:

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. Hatayı gönderin. İsteği gönderdikten sonra şu işlemler gerçekleşir:

    • Gönderim yapıldıktan sonraki inceleme süreci:

      • Google GKI ekibi isteği inceler ve onaylar ya da daha fazla bilgiye ihtiyaç duyulması durumunda isteği size geri atar.
      • Düzeltme üzerinde anlaşmaya varıldıktan sonra Google GKI ekibi değişikliği kod incelemesine tabi tutar. Bu inceleme sırasında ESRT zamanlayıcısı aktiftir. Ancak yama reddedilirse veya yeniden çalışılması gerekirse ESRT zamanlayıcısı sıfırlanır.
      • GKI ekibi, değişikliği birleştirir, oluşturur, regresyon açısından test eder ve sertifikalandırır.

    • Yayın: