ส่งแพตช์

หน้านี้อธิบายกระบวนการทั้งหมดในการส่งแพตช์ไปยัง Android Open Source Project (AOSP) รวมถึงวิธีขอการตรวจสอบและติดตามการเปลี่ยนแปลงของคุณด้วย Gerrit

ข้อกำหนดเบื้องต้น

ในการเริ่มต้น ตรวจสอบให้แน่ใจว่าคุณได้ทำสิ่งต่อไปนี้แล้ว:

ทรัพยากร

  • สำหรับรายละเอียดเกี่ยวกับ Repo และ Git โปรดดูที่หน้า Source Control Tools
  • สำหรับข้อมูลเกี่ยวกับบทบาทต่างๆ ภายในชุมชนโอเพ่นซอร์ส Android โปรดดูที่หน้า บทบาทของโครงการ
  • สำหรับข้อมูลการให้สิทธิ์ใช้งานเกี่ยวกับการให้รหัสแก่แพลตฟอร์ม Android โปรดดูที่หน้า ใบอนุญาต

สำหรับผู้ร่วมให้ข้อมูล

รับรองความถูกต้องกับเซิร์ฟเวอร์

หากคุณแบ่งปันที่อยู่ IP กับผู้ใช้รายอื่น โควต้าสามารถเรียกใช้ได้แม้ในรูปแบบการใช้งานปกติ กรณีนี้อาจเกิดขึ้นได้ เช่น เมื่อผู้ใช้หลายคนซิงค์ไคลเอ็นต์ใหม่จากที่อยู่ IP เดียวกันภายในระยะเวลาสั้นๆ การเข้าถึงที่ผ่านการรับรองความถูกต้องจะใช้โควต้าแยกต่างหากสำหรับผู้ใช้แต่ละคน โดยไม่คำนึงถึงที่อยู่ IP หากต้องการอ่านเกี่ยวกับการเปิดใช้งานการเข้าถึงที่ตรวจสอบความถูกต้อง โปรดดู ที่ การใช้การรับรองความถูกต้อง

การเริ่มต้นสาขา Repo

สำหรับการเปลี่ยนแปลงแต่ละรายการที่คุณต้องการทำ ให้เริ่มสาขาใหม่ภายในที่เก็บ Git ที่เกี่ยวข้อง:

repo start NAME .

You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and isn't included either on Gerrit or in the final source tree.

Making your change

Modify the source files, and validate your changes.

Commit the changes to your local repository with these commands:

git add -A
git commit -s

เปลี่ยนคำอธิบาย

  • บรรทัดที่ 1: หัวเรื่อง

    ระบุข้อมูลสรุปหนึ่งบรรทัด ( สูงสุด 50 อักขระ )

    รูปแบบนี้ใช้โดย Git และ Gerrit สำหรับการแสดงผลต่างๆ เป็นส่วนที่สำคัญที่สุดและหนาแน่นที่สุดในข้อความยืนยันของคุณ ลองใช้คำนำหน้าเพื่ออธิบายส่วนที่คุณเปลี่ยนแปลง ตามด้วยคำอธิบายของการเปลี่ยนแปลงที่คุณทำในคอมมิตนี้ เช่น อันที่มี ui เป็นคำนำหน้า:

    ui: Removes deprecated widget

  • บรรทัดที่ 2: ว่างเปล่า

    ให้บรรทัดนี้ว่างเสมอ

  • บรรทัดที่ 3: ร่างกาย

    เขียนคำอธิบายที่ยาวขึ้นโดยเริ่มจากบรรทัดนี้

    สิ่งนี้ต้องห่อด้วยกระดาษที่มีความยาวสูงสุด 72 อักขระ อธิบายว่าการเปลี่ยนแปลงแก้ปัญหาใดได้บ้าง และอย่างไร แม้ว่าสิ่งนี้จะเป็นทางเลือกเมื่อนำคุณลักษณะใหม่ไปใช้ แต่จะมีประโยชน์มากสำหรับผู้อื่นในภายหลังหากพวกเขาอ้างถึงการเปลี่ยนแปลงนี้ โดยเฉพาะอย่างยิ่งสำหรับการดีบัก

    ใส่หมายเหตุสั้นๆ ของสมมติฐานหรือข้อมูลเบื้องหลังที่อาจมีความสำคัญเมื่อผู้ร่วมให้ข้อมูลรายอื่นทำงานในคุณลักษณะนี้

ID การเปลี่ยนแปลงที่ไม่ซ้ำ ชื่อและอีเมลของคุณ ซึ่งระบุไว้ระหว่าง repo init จะถูกเพิ่มลงในข้อความคอมมิตของคุณโดยอัตโนมัติ

นี่คือตัวอย่างข้อความยืนยัน:

Line 1, Headline - a short description

Line 3, Body - Add the detailed description of your patch here. Use as many lines
as needed. You can write an overall description, then list specifics.

I6e3c64e7a:Added a new widget.
I60c539a8f:Fixed the spinning image.
To read a blog about good commit descriptions (with examples), see How to Write a Git Commit Message by Chris Beams.

Uploading to Gerrit

After you commit your change to your personal history, upload it to Gerrit with this command: 

repo upload

If you started multiple branches in the same repository, you're prompted to select which ones to upload.

After a successful upload, Repo provides you with the URL of a new page on Gerrit. Click the link that Repo gives you to view your patch on the review server, add comments, or request specific reviewers for your patch.

Requesting a review

After you've uploaded your changes to Gerrit, the patch must be reviewed and approved by the appropriate code owners. Locate code owners in OWNERS files.

To find the appropriate code owners and add them as reviewers for your change, follow these steps.

  1. Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.

    suggest owners link in Gerrit
    Figure 1. Suggest owners link in Gerrit

  2. Add code owners from the list as reviewers for your patch.

To determine the status of the files in your patch, check for the following icons next to the files in the patch.

  • (checkmark icon): Approved by code owner
  • (cross icon): Not approved by code owner
  • (clock icon): Pending approval by code owner
Figure 2. Example of files with icons showing code owner approval status

Uploading a replacement patch

Suppose a reviewer looked at your patch and requested a small modification. You can amend your commit within Git, which results in a new patch on Gerrit that has the same change ID as the original. 

git add -A
git commit --amend

เมื่อคุณอัปโหลดแพตช์ที่แก้ไขแล้ว แพตช์นั้นจะแทนที่แพตช์ดั้งเดิมทั้งใน Gerrit และในประวัติ Git ในเครื่องของคุณ

การแก้ไขความขัดแย้งในการซิงค์

หากมีการส่งแพตช์อื่นๆ ไปยังซอร์สทรีที่ขัดแย้งกับของคุณ ให้สร้างแพตช์ของคุณใหม่บน HEAD ใหม่ของที่เก็บซอร์ส โดยเรียกใช้คำสั่งนี้:

repo sync

คำสั่ง repo sync จะดึงข้อมูลอัปเดตจากเซิร์ฟเวอร์ต้นทาง จากนั้นพยายามปรับฐาน HEAD ของคุณใหม่ไปยัง HEAD แบบรีโมตใหม่โดยอัตโนมัติ

หากการรีเบสอัตโนมัติไม่สำเร็จ ให้ทำการรีเบสด้วยตนเอง

repo rebase

อีกเครื่องมือหนึ่งในการจัดการกับข้อขัดแย้งของรีเบสคือ git mergetool เมื่อคุณรวมไฟล์ที่ขัดแย้งกันเรียบร้อยแล้ว ให้รันคำสั่งนี้:

git rebase --continue

หลังจากการรีเบสอัตโนมัติหรือด้วยตนเองเสร็จสมบูรณ์ ให้เรียกใช้ repo upload เพื่อส่งแพตช์รีเบสของคุณ

หลังจากอนุมัติการส่งแล้ว

หลังจากการส่งผ่านกระบวนการตรวจสอบและยืนยัน Gerrit จะรวมการเปลี่ยนแปลงลงในที่เก็บข้อมูลสาธารณะโดยอัตโนมัติ ผู้ใช้รายอื่นสามารถเรียกใช้ repo sync เพื่อดึงการอัปเดตไปยังไคลเอ็นต์ภายในของตน

สำหรับโครงการต้นน้ำ

Android ใช้ประโยชน์จากโครงการโอเพ่นซอร์สอื่นๆ เช่น เคอร์เนล Linux และ WebKit ตามที่อธิบายไว้ใน การจัดการซอฟต์แวร์ Android สำหรับโปรเจ็กต์ส่วนใหญ่ที่อยู่ภายใต้ external/ ให้ทำการเปลี่ยนแปลงที่อัปสตรีม จากนั้นแจ้งผู้ดูแล Android ถึงรีลีสอัพสตรีมใหม่ที่มีการเปลี่ยนแปลงของคุณ

นอกจากนี้ คุณยังอาจอัปโหลดแพตช์ที่ทำให้มีการติดตามการเผยแพร่อัปสตรีมใหม่ โปรดทราบว่าการเปลี่ยนแปลงเหล่านี้อาจทำได้ยากหากโครงการมีการใช้งานอย่างแพร่หลายใน Android เช่นเดียวกับโครงการขนาดใหญ่ส่วนใหญ่ที่กล่าวถึงด้านล่าง ซึ่งมักจะได้รับการอัปเกรดในทุกรุ่น

กรณีพิเศษที่น่าสนใจอย่างหนึ่งคือ Bionic โค้ดส่วนใหญ่มาจาก BSD ดังนั้น เว้นแต่การเปลี่ยนแปลงจะเป็นโค้ดใหม่สำหรับ Bionic โปรดทำการแก้ไขอัปสตรีม แล้วจึงดึงไฟล์ใหม่ทั้งหมดจาก BSD ที่เหมาะสม

เคอร์เนล Android

ทำการเปลี่ยนแปลงทั้งหมดตั้งแต่ต้นน้ำ สำหรับคำแนะนำทั่วไป ให้ทำตาม แนวทางการสนับสนุนเคอร์เนลของ Android และหน้า พัฒนารหัสเคอร์เนลสำหรับ GKI

ห้องไอซียู

ทำการเปลี่ยนแปลงทั้งหมดในโครงการ ICU ที่โฟลเดอร์ external/icu (โฟลเดอร์ icu4c/ และ icu4j/ ) ใน หน้าแรกของ ICU-TC ดู การส่งข้อบกพร่องของ ICU และคำขอคุณสมบัติ เพิ่มเติม เพิ่มป้ายกำกับ “android” ให้กับคำขอต้นทาง Jira ทั้งหมด

ซีแอลดีอาร์

ข้อมูลภาษาส่วนใหญ่ใน ICU มาจาก โครงการ Unicode CLDR ส่งคำขอทั้งหมดขึ้นไปตาม Contributing to CLDR และเพิ่มป้ายกำกับว่า “android”

LLVM/เสียงดังกราว/คอมไพเลอร์-rt

ทำการเปลี่ยนแปลงทั้งหมดในโครงการที่เกี่ยวข้องกับ LLVM ( external/clang , external/compiler-rt , external/llvm ) ใน หน้า LLVM Compiler Infrastructure

มช

ทำการเปลี่ยนแปลงทั้งหมดกับโครงการ MirBSD Korn Shell ที่ external/mksh โดยส่งอีเมลไปที่ miros-mksh บนโดเมน mirbsd.org (ไม่ต้องสมัครสมาชิกเพื่อส่งที่นั่น) หรือที่ Launchpad

OpenSSL

ทำการเปลี่ยนแปลงทั้งหมดในโครงการ OpenSSL ที่ external/openssl บน หน้า OpenSSL

V8

ส่งการเปลี่ยนแปลงทั้งหมดไปยังโครงการ V8 ที่ external/v8 ใน หน้าปัญหา V8 ดู การสนับสนุน V8 สำหรับรายละเอียด

เว็บคิต

ทำการเปลี่ยนแปลงทั้งหมดในโครงการ WebKit ที่ external/webkit บน หน้า WebKit เริ่มกระบวนการโดย ยื่นข้อบกพร่องของ WebKit ในจุดบกพร่อง ให้ใช้ Android สำหรับช่อง Platform และ OS เฉพาะในกรณีที่จุดบกพร่องนั้นเฉพาะกับ Android ข้อบกพร่องมีแนวโน้มที่จะได้รับความสนใจจากผู้ตรวจสอบมากขึ้นหลังจากเพิ่มการแก้ไขที่เสนอและรวมการทดสอบแล้ว ดู รหัสที่สนับสนุน WebKit สำหรับรายละเอียด

ซลิบ

ทำการเปลี่ยนแปลงทั้งหมดกับโปรเจ็กต์ zlib ที่ external/zlib บน โฮมเพจ zlib