Google Pixel ไม่ใช่อุปกรณ์อ้างอิงของ AOSP อีกต่อไป

 (9to5google.com)
2 คะแนน โดย GN⁺ 2025-06-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google เผยแพร่ซอร์สโค้ดของ Android 16 บน AOSP แล้ว แต่ไม่ได้เปิดเผย คลังฮาร์ดแวร์ของ Pixel
  • เนื่องจากไม่มีการเปิดเผย device tree ของ Pixel และโค้ดที่เกี่ยวข้อง จึงมีข้อสงสัยในบางส่วนของชุมชนว่า “AOSP ถูกยกเลิก”
  • Google ปฏิเสธอย่างเป็นทางการว่า "AOSP จะไม่ถูกยุติ" และยืนยันอีกครั้งว่าจะยังคงเผยแพร่และอัปเดตซอร์สโค้ด AOSP ต่อไป
  • จากนี้ไป AOSP จะมุ่งไปที่ reference target ที่ไม่ผูกกับฮาร์ดแวร์เดิม และจะเปลี่ยนไปเน้นอุปกรณ์เสมือน/อุปกรณ์แบบทั่วไป เช่น 'Cuttlefish' ที่ยืดหยุ่นและต้นทุนต่ำ รวมถึง GSI
  • อาจทำให้ นักพัฒนา custom ROM และ นักวิจัยด้านความปลอดภัย เผชิญความยากลำบากมากขึ้นในการอัปเดต OS และการทำวิจัย

ประเด็นการเปิดตัว Android 16 และการเผยแพร่ซอร์สโค้ด

  • พร้อมกับการเปิดตัว Android 16 นั้น Google ไม่ได้เปิดเผย คลังฮาร์ดแวร์ของ Pixel และโค้ด device tree
    • ก่อนหน้านี้ โค้ดสำหรับฮาร์ดแวร์ Pixel จะถูกปล่อยออกมาพร้อมกับ AOSP และมีบทบาทสำคัญต่อการพัฒนา custom Android ROM
  • ด้วยเหตุนี้ จึงคาดว่านักพัฒนา custom ROM และนักวิจัยด้านความปลอดภัยจะเผชิญความยากลำบากมากขึ้นในการ พัฒนา custom OS, การติดตามอัปเดต Android ล่าสุด และการ วิจัยช่องโหว่ความปลอดภัย

ท่าทีอย่างเป็นทางการของ Google เกี่ยวกับ AOSP

  • แม้จะมีข่าวลือในบางส่วนของชุมชนว่า "AOSP กำลังจะยุติลง" แต่ Seang Chau รองประธานฝ่าย Android ได้
    • ปฏิเสธอย่างเป็นทางการว่า "AOSP จะไม่หายไป"
    • และกล่าวว่า "เรายังคงมุ่งมั่นต่อการอัปเดต AOSP ต่อไป"
  • อย่างไรก็ตาม คำตอบอย่างเป็นทางการจากทีม Android บ่งชี้ว่า ในอนาคตจะไม่มีการจัดเตรียม Pixel device tree และสิ่งที่เกี่ยวข้องอีกต่อไป
  • reference target ที่ AOSP จะจัดเตรียมให้ต่อจากนี้ จะมุ่งไปในรูปแบบที่ เป็นอิสระจากฮาร์ดแวร์เฉพาะราย
    • โดยมุ่งสู่อุปกรณ์อ้างอิงที่ ยืดหยุ่น ปรับแต่งได้ และต้นทุนต่ำ ซึ่งไม่ผูกกับฮาร์ดแวร์เฉพาะของผู้ผลิตรายใด รวมถึง Google เอง
    • ตลอดหลายปีที่ผ่านมา ชุมชนได้ใช้ Cuttlefish (อุปกรณ์อ้างอิง) และ GSI target ที่ build จากซอร์ส สำหรับการทดสอบและการพัฒนา
    • อุปกรณ์อ้างอิงเหล่านี้จะยังคงเปิดเผยให้แก่นักพัฒนาต่อไป

ผลกระทบต่อชุมชน custom ROM และความปลอดภัย

  • Google เน้นย้ำอย่างเป็นทางการถึง ความตั้งใจที่จะสนับสนุน AOSP อย่างต่อเนื่อง
  • แต่เมื่อ ไม่มีการรองรับฮาร์ดแวร์โดยตรงอีกต่อไป ก็มีแนวโน้มว่าการสร้างและบำรุงรักษา custom ROM รวมถึงงานวิจัยด้านความปลอดภัย จะมี ความยากในการพัฒนาและอุปสรรคในการเริ่มต้นสูงขึ้นอย่างมาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-13
ความคิดเห็นจาก Hacker News

  • คุณอาจมองว่าฉันแปลกก็ได้ แต่เหตุผลเดียวที่ฉันซื้อ Pixel ช่วงหลัง ๆ คือเพราะตั้งใจจะติดตั้ง GrapheneOS ทันทีหลังซื้อ และจนถึงตอนนี้ก็พอใจกับผลลัพธ์มาก ถ้าไม่ใช่เรื่องงาน ฉันพยายามหลีกเลี่ยงทุกอย่างที่เกี่ยวกับ Google ให้มากที่สุด เพราะมีหลายอย่างที่ฉันไม่ชอบเกี่ยวกับ Google จริง ๆ แน่นอนว่า Google ไม่ได้มีหน้าที่ต้องแจก binary blob พวกนั้นต่อไป แต่การหยุดแบบกะทันหันโดยไม่บอกล่วงหน้าทั้งที่ทำมาเป็นเวลานาน ก็ทำให้ฉันผิดหวังเพิ่มอีกครั้ง ฉันคิดว่าควรแจ้งล่วงหน้าให้เพียงพอเหมือนที่ควรทำตอนปิดบริการต่าง ๆ แน่นอนว่าการปล่อยไบนารีต่อและรับประกันว่าใช้งานได้ก็เป็นภาระเพิ่ม แต่ในความเป็นจริงพวกเขาก็ยังต้องทำงานนั้นภายในองค์กรอยู่ดี ฉันเดาว่า Google ตัดสินใจเชิงกลยุทธ์ว่าจะยอมขาดทุนจากผู้ใช้ GrapheneOS บางส่วนในฝั่งอุปกรณ์ แล้วไปโฟกัสกับสิ่งที่ทำเงินทางอ้อมมากกว่าอย่างระบบนิเวศแบบปิด การขุดข้อมูล หรือโฆษณา

    • ฉันก็ซื้อ Pixel ด้วยเหตุผลเดียวกัน ตอนนี้ทุกคนคงรู้กันแล้วว่ามีการติดตามแทบทุกชั้น ดังนั้นการซื้อ Pixel แล้วแฟลช GrapheneOS ทันทีน่าจะเป็นทางเลือกที่ฉลาดที่สุด โทรศัพท์ทุกเครื่องในบ้านเรา (ของภรรยากับของฉัน) ก็ใช้อย่างนี้เหมือนกัน ไม่ต้องสนใจเลยว่าจะเป็น Play Services, แอป Google หรือ Facebook ฉันแค่อยากไม่ให้ชีวิตของฉันกลายเป็นส่วนหนึ่งของโฆษณาแบบเจาะเป้าหมาย หรือข้อมูลที่อนาคตอาจถูกเอาไปใช้ทำอะไรก็ไม่รู้ ฉันกลับรู้สึกแปลกใจมากกว่าที่มีคนจำนวนมากไม่ใส่ใจเรื่องความเป็นส่วนตัวแบบนี้

    • ประเมินแบบใจดีแล้วนะ ฉันก็ทำเหมือนกัน

    • ฉันมองต่างเล็กน้อยกับคำกล่าวที่ว่า “Google หยุดแจกไบนารีโดยไม่แจ้งล่วงหน้าให้เพียงพอ” การพึ่งพาพฤติกรรมที่ไม่ได้มีการบันทึกเป็นทางการ แล้วมาร้องเรียนเมื่อมันเปลี่ยนไป เป็นเรื่องแปลก ถ้าเป็นวิศวกรซอฟต์แวร์ก็ควรถือเป็นเรื่องปกติว่าไม่ควรพึ่งสิ่งแบบนั้น ถ้ามีใครยกตัวอย่างว่าซื้อ Pixel มาใช้เป็นที่ทับกระดาษ แล้ววันหนึ่งใช้ไม่ได้เพราะกล้องนูนขึ้นมา จะไปโทษบริษัทก็คงเป็นตรรกะแบบเดียวกัน

  • ฉันยังจำได้ว่าเคยรู้สึกขอบคุณมากที่สามารถซื้อฮาร์ดแวร์สำหรับผู้บริโภคจริงอย่าง Pixel (หรือ Nexus ในอดีต) เอา AOSP กับ proprietary blob มาประกอบ แล้วสร้างบิลด์ที่ทำให้ฮาร์ดแวร์ทั้งหมดใช้งานได้โดยแทบไม่ต้องทำอะไรเพิ่ม แม้ Cuttlefish อาจเป็น reference device ที่มีประสิทธิภาพกว่าก็จริง แต่ก็ยังต่างจาก Pixel ที่สามารถนำเครื่องไปใช้ได้หลากหลายแบบ เช่น กับ GrapheneOS ฉันคิดว่าประสบการณ์การรัน Android ที่คอมไพล์ด้วยมือตัวเองบนอุปกรณ์จริง มีเสน่ห์ที่ VM ให้ไม่ได้

    • ตามบทความบอกว่า GSI (Generic System Image) ก็ยังรองรับในฐานะ reference device และนี่ก็เป็นตัวเลือกที่ใกล้เคียงฮาร์ดแวร์จริงมากกว่า เพียงแต่ GSI มีหลายอย่างที่ไม่สะดวก เช่น ประเภทของบิลด์จะแตกต่างกันไปตามสเปกระดับล่างของอุปกรณ์ (รูปแบบพาร์ทิชัน เวอร์ชัน Android ที่เปิดตัวครั้งแรก ฯลฯ) ถึงอย่างนั้นก็ไม่ใช่ทางเลือกที่แย่ ทุกวันนี้ยังมี GKI (Google Generic Kernel Image) โผล่มาด้วย ซึ่งถูกออกแบบให้รันบนอุปกรณ์รุ่นใหม่ได้ (ยกเว้น custom module/blob) แม้นี่จะไม่ใช่ mainline ของลินุกซ์เคอร์เนล และยังเป็น downstream branch ที่ใส่ custom patch ไว้มากมาย แต่ก็ช่วยให้ทดสอบและพัฒนาได้ง่ายขึ้นในรูปแบบที่เป็นหนึ่งเดียวโดยไม่ผูกกับอุปกรณ์จริง

  • ฉันคิดว่า GrapheneOS ทำให้สถานการณ์นี้ดูร้ายแรงเกินจริงจนเข้าข่ายทำพลาดเองแบบ “เด็กเลี้ยงแกะ” การวิจารณ์ที่เห็นชัดว่าไม่จริง ทำให้ฝั่งบริษัทตอบโต้ได้ง่าย คำพูดแนว ๆ “Google is killing AOSP” อาจสะดุดตาก็จริง แต่ก็เป็นเรื่องที่บริษัทหยิบเหตุผลมาโต้กลับได้ง่ายมาก สิ่งที่เกิดขึ้นตอนนี้คือ GrapheneOS ได้รับ binary blob โดยอาศัยความสมัครใจของ Google ซึ่ง Google ไม่ได้มีหน้าที่ต้องให้ และก็แค่หยุดให้เพราะมีเหตุผลของตัวเอง ยิ่ง GrapheneOS ไปพูดถึงประเด็นกฎหมายหรือการผูกขาด นักพัฒนายิ่งไม่แตะเรื่องนี้และโยนต่อให้ทีมกฎหมายอย่างเดียว

    • อยากรู้ว่าตรงไหนที่ว่าพูดเกินจริงกันแน่ อะไรคือสิ่งที่ไม่จริง GrapheneOS เคยทำแบบนี้มาก่อนหรือเปล่า และส่วนไหนที่ผิดอย่างเป็นรูปธรรม

    • ฉันคิดว่าเหตุการณ์นี้อาจทำให้ GrapheneOS หันไปรองรับอุปกรณ์วงกว้างนอกเหนือจาก Pixel มากขึ้น ซึ่งจริง ๆ ก็ควรทำมาตั้งนานแล้ว และถึงจะไม่มีการรองรับฮาร์ดแวร์ที่ดีแบบนี้ มันก็ยังปลอดภัยกว่า Android เดิมแบบทิ้งห่างอยู่ดี

    • ฉันไม่คิดว่าจำเป็นต้องออกตัวปกป้อง Google มากนัก เมื่อดูจากการที่มันเป็นหนึ่งในสองบริษัทที่แทบผูกขาดตลาดอยู่แล้ว

  • สิ่งที่ฉันกังวลมาตลอดคือ ถ้าไม่มีคลังฮาร์ดแวร์ของ Pixel (device tree, ไบนารีไดรเวอร์ ฯลฯ) การพัฒนาอัปเดต OS สำหรับ custom Android ROM จะยากมาก และอาจกระทบงานวิจัยด้านความปลอดภัยด้วย

    • ยิ่งกังวลขึ้นไปอีกเพราะมี โพสต์แบบนี้ บนทวิตเตอร์ทางการของ GrapheneOS

  • ถ้าไม่มี GrapheneOS ฉันก็น่าจะย้ายไป iPhone ฉันใช้ GrapheneOS มานานและชอบความเบา เรียบง่าย และไม่มีส่วนประกอบของ Google ที่ไม่จำเป็นมาก ๆ ตอนนี้ Pixel อย่างเป็นทางการของ Google ไม่ใช่สิ่งที่เหมาะกับฉันอีกต่อไปแล้ว

  • เพิ่มเข้าไปอีกหนึ่งรายการใน Google Graveyard ถ้าฉันควบคุมมันเองไม่ได้อีกต่อไป ก็ไม่มีเหตุผลให้ใช้ Pixel แล้ว ฉันวางแผนจะกลับไปลองใช้ iPhone อีกครั้ง ยอมรับข้อเสียของมันเพื่อแลกกับข้อดีหลายอย่าง

  • ฉันนึกถึงคำโต้แย้งประมาณว่า “AOSP ยังไม่ตาย ยังใช้ผ่าน emulator ได้อยู่” ในบทความบอกว่า “หลายปีมานี้นักพัฒนาใช้ Cuttlefish (อ้างอิง GitHub) และ target ของ GSI ที่บิลด์จากซอร์สเป็นเป้าหมายอ้างอิงอยู่แล้ว และจะยังคงให้ใช้งานต่อไปเพื่อวัตถุประสงค์ด้านการทดสอบและการพัฒนา” ฉันยังใหม่กับ AOSP เลยอยากรู้จากมุมมองของชุมชนว่า reference device พวกนี้ใช้งานพัฒนารอม custom ได้จริงแค่ไหน หรือเป็นแค่คำพูดสวยหรู

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

    • ถูกแค่บางส่วน ตาม FAQ อย่างเป็นทางการ เหตุผลหลัก คือ (1) ฟีเจอร์ความปลอดภัยฮาร์ดแวร์ระดับสูงสุด เช่น memory tagging (2) การออกแพตช์ที่รวดเร็ว และ (3) การรองรับอย่างเป็นทางการระยะยาว

    • หรือการเปลี่ยนแปลงครั้งนี้อาจทำให้ GrapheneOS ไปในทางที่จะไม่รองรับอุปกรณ์ใหม่อีกต่อไปก็ได้

  • GrapheneOS คือเหตุผลเดียวที่ทำให้ฉันซื้อ Pixel

  • เนื้อหาค่อนข้างซ้ำ ลิงก์ที่เกี่ยวข้อง