Yeniden oluşturma isteğinde bulunma

Yeniden derleme, GKI çekirdeğinin herkese açık olarak yayınlanmasından sonra bir ikili programın yeniden birleştirilmesi, yeniden derlenmesi, yeniden test edilmesi ve yeniden sertifikalandırılması sürecidir.

Yeniden oluşturma isteğinde bulunmadan önce aşağıdaki kuralları göz önünde bulundurun.

Uygunluk ve yaşam döngüsü

  • Zamanlama: Yeniden derleme isteklerini yalnızca üç aylık derlemenin ilk herkese açık sürümü yayınlandıktan sonra yayın dallarında gönderebilirsiniz. İlk herkese açık sürümden sonra en fazla altı ay boyunca yalnızca belirli bir sürüm dalı için satıcı kancaları veya diğer özelliklerle ilgili yeniden yanıt isteğinde bulunulabilir.
  • 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 şartları, dalın uyumsuz olmasına neden olduğunda dalın desteği sonlandırılır. Desteği sonlandırılmış 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ü, yeniden döndürme işlemleri için Mart 2027'ye kadar desteklenir. Bu tarih, Eylül 2025'ten itibaren yayınlanan sürümler için 18 aylık LTS 2.0 çekirdek sürümü 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.
  • 16 KB GKI sürümleri: Desteklenen 16 KB GKI dalları (android15-6.6, android16-6.12 ve android17-6.18) için isteğe bağlı yeniden derlemeler, 4 KB derlemelerle aynı yeniden derleme istek formunu, yama gönderme standartlarını ve yeterlilik sürecini takip eder. 4 KB ve 16 KB çekirdekleri birlikte güncellemeniz gerekmez ancak bunu yapmanızı öneririz.

Yama gönderme standartları

Yeniden oluşturma isteği işlemleri için Beklenen Standart Çözüm Süresi'ni (ESRT) karşılamak üzere, yayın dalına gönderilen tüm yamaların aşağıdaki teknik kurallara uyması gerekir.

Doğruluk kaynağı ve seçmece değişiklikler

  • Önce geliştirme dalı: Üç aylık sürüm dalına giren tüm yamalar, ana GKI geliştirme dalıyla birleştirilmiş olmalıdır. Örneğin, android15-6.6-2025-08 sürümünün yeniden derlenmesi için bir yama gerekiyorsa bu yamanın android15-6.6 sürümüyle birleştirilmiş olması gerekir.
  • Temiz seçme: Yamaları doğrudan geliştirme dalından seçmeniz gerekir. Diğer sürüm dallarından seçerek alma işlemi yapmayın (ör. 2025-08 dalından 2025-09 dalına seçerek alma işlemi yapmayın). Bu, geliştirme dalındaki sürümle tutarsız olan yazar veya commit bilgilerine neden olabilir. Tutarsız bilgiler içeren yamalar kabul edilmez.
  • Meta verileri koru: Orijinal commit meta verilerini (ör. yazar, orijinal zaman damgası) koruyun. Meta verileri korumak için git cherry-pick -x kullanın.

İşleme zinciri

  • Sıralı zincir: Yeniden derleme isteği birden fazla yamayı içeriyorsa bunları tek bir sıralı commit zinciri olarak yükleyin.
  • ABI ve KMI yerleşimi: Birden fazla yama içeren bir yeniden derleme, çekirdek modülü arayüzü (KMI) ve uygulama ikili arayüzü (ABI) güncellemelerini (örneğin, 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 kaydı düzenlerseniz derleme hatalarını önlemek için tüm alt yamaları, üst yamalarının en son revizyonuna göre yeniden temellendirmeniz gerekir.
  • Çakışma çözümü: Hiçbir yamada çakışma işaretçisi bulunmadığını doğrulayın.
  • Derleme doğrulaması: Tüm commit zinciri başarıyla derlenmelidir.

Zorunlu etiketler

Yeniden oluşturma isteğinin ilerlemesi, taahhüt mesajında aşağıdaki etiketler olmadan engellenir:

  • Change-Id: Geliştirme dalı değişikliğinin Change-Id değeriyle 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şlemiyle alınmış bir sürümü olmalı ve UPSTREAM yaması olarak biçimlendirilmelidir. Android Ortak Çekirdeklerine nasıl yama gönderebilirim? başlıklı makaleyi inceleyin.
  • Bug (mevcut): Orijinal geliştirme dalı commit'indeki mevcut Bug: XYZ etiketleri kaldırılmamalıdır.
  • Bug (yeniden döndürme): XYZ'nin, mevcut yeniden döndürme 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: Geliştirme dalından yayın dalına bir CL seçerken ve CL, UPSTREAM olarak etiketlendiğinde 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.
    • Değişiklik listesi sorunsuz bir şekilde uygulanmazsa çakışmaları düzeltin, etiketi BACKPORT olarak güncelleyin ve çakışma çözümü kapsamında yapılanları belgeleyin. Ana hat Linux'tan geriye dönük taşıma koşulları başlıklı makaleyi inceleyin.

Öncelik ve ESRT

GKI ekibinin önceliklendirmesine yardımcı olmak için yeniden döndürme 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 istekleri için aciliyet gerekçesini de belirtmeniz gerekir.

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

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

Hizmet düzeyi sözleşmesi politikaları

  • Her sürüm dalı için ayrı bir yeniden derleme isteği gönderin.
  • "Düzeltildi" olarak işaretlenen bir yeniden değerlendirme isteğinde değişiklik yapmanız gerekiyorsa yeni bir yeniden değerlendirme isteği gönderin. Ek değişiklik listeleri (CL'ler) eklemek için isteği 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 içinde yanıt vermezseniz hata, Düzeltilmeyecek (Eski) olarak işaretlenir.

Yeniden döndürme isteği gönderme

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

Acil yeniden döndürme süreci Şekil 1. Acil yeniden döndürme süreci.

Yeniden döndürme isteği göndermek için:

  1. GKI yeniden döndürme isteği formunu doldurun ve hemen Google'daki iletişim noktanızla iletişime geçin.

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

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

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

    Örnek: android16-6.12'den android16-6.12-2025-12'e 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 yapılır:

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

      • Google GKI ekibi, isteği inceler ve onaylar ya da daha fazla bilgiye ihtiyaç duyulursa isteği size geri atar.
      • Bir düzeltme üzerinde anlaşmaya varıldıktan sonra Google GKI ekibi, değişiklik için kod incelemesi yapar. Bu inceleme sırasında ESRT zamanlayıcısı etkindir. Ancak yama reddedilirse veya yeniden çalışılması gerekirse ESRT zamanlayıcısı sıfırlanır.
      • GKI ekibi değişikliği birleştirir, derler, gerileme için test eder ve onaylar.

    • Sürüm: