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 döndürme 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 derleme isteğinde bulunabilirsiniz. İ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 oluşturma istekleri gönderin.
  • 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 uyumsuz olması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 sürüm derleme notlarında yer alır. Örneğin, Eylül 2025 sürümü, yeniden oluşturma işlemleri için Mart 2027'ye kadar desteklenir. Bu tarih, Eylül 2025'te yayınlanmaya başlayan 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.

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çmeniz gerekir. Bu, geliştirme dalındaki sürümle tutarsız yazar veya commit bilgilerine neden olabileceğinden diğer yayın dallarından (ör. 2025-08 ile 2025-09 arasında seçim yapmayın) seçim yapmayın. 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 yamayı içeriyorsa bunları tek bir sıralı zincir olarak yükleyin.
  • ABI ve KMI yerleşimi: Çoklu yama yeniden oluşturma işlemi, ç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 commit'i düzenlerseniz derleme hatalarını önlemek için tüm alt yamaları üst yamanın en son düzeltmesinin ü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 taahhüt zinciri başarıyla oluşturulmalıdır.

Zorunlu etiketler

Yeniden döndürme isteğindeki ilerleme, 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ına birleştirildiyse LTS sürümünün cherry-pick'i olmalı ve UPSTREAM yaması olarak biçimlendirilmelidir. Android Common Kernel'lara 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 (yeniden oluşturma): XYZ'nin, mevcut yeniden oluşturma 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 cherry-pick yaparken 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 temiz 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 döndürme isteğine bir ö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üresi (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 tarama isteğinde değişiklik yaparsanız yeni bir yeniden tarama isteği gönderin. Ek değişiklik listeleri (CL) ekleme isteğini yeniden açmayın.
  • Yeniden döndürme 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 ş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 inceleme 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 döndürme 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.
    • Yamayı 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ı 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, regresyon açısından test eder ve sertifikalandırır.

    • Sürüm: