ในบทความนี้ เราจะสำรวจความจริงว่าทำไมอุปกรณ์ Snapdragon 801 จึงไม่ได้รับ Android Nougat ตั้งแต่ผู้ผลิตชิปเซ็ตไปจนถึงผู้จำหน่าย ปัญหามีมากมาย!
อัปเดตเพื่อให้สอดคล้องกับข้อกำหนดอย่างใดอย่างหนึ่งหรือ Vulkan หรือ OpenGL ES 3.1 สำหรับ Android 7.0
เมื่อเร็วๆ นี้ มีบทความมากมายที่เขียนเกี่ยวกับการอัปเดตเวอร์ชัน การโต้ตอบระหว่างผู้จำหน่ายและผู้ผลิตชิปเซ็ต และความหมายต่ออุปกรณ์ในอนาคต ทำไมสิ่งนี้ถึงเพิ่มขึ้นในสัปดาห์นี้?
ปรากฏว่าในสัปดาห์นี้เนื่องจาก Nexus 5 ที่มีชื่อเสียงจะไม่ได้รับการอัปเดตเป็น Android 7.0 (Nougat) และ Qualcomm ก็ประกาศว่าจะไม่ได้รับการอัปเดต ให้การสนับสนุน MSM8974 (หรือที่รู้จักกันทั่วไปในชื่อ Snapdragon 801) บน 7.0 บทความนี้เขียนขึ้นโดยความร่วมมือกับ XDA Recognized นักพัฒนา แมลงภู่
หัวข้อนี้ได้รับความสนใจไม่น้อยจากเว็บไซต์ข่าวต่างๆ แต่ หลายคนพลาดรายละเอียดเล็กๆ น้อยๆ ของสิ่งที่เกิดขึ้นเบื้องหลังจริงๆส. บทความนี้จะอธิบายเพิ่มเติมเล็กน้อยเกี่ยวกับวิธีการทำงานของการอัปเดตซอฟต์แวร์ โดยใช้ประสบการณ์ของเราในการทำงานกับ OEM ในการอัปเดตเฟิร์มแวร์อย่างเป็นทางการ เราจะอธิบายให้คุณทราบถึงสิ่งที่เกิดขึ้นเบื้องหลัง (และสาเหตุ) และสาเหตุที่คุณอาจไม่ได้รับซอฟต์แวร์ล่าสุดบนโทรศัพท์ของคุณ
ขั้นตอนแรกในชีวิตของการอัปเดตเฟิร์มแวร์ Android คือการอัปเดตอัปสตรีม นี่คือสิ่งที่ Google ทำงานเป็นการภายใน ตรงกันข้ามกับ "เวิร์กโฟลว์แบบเปิด" Android ได้รับการพัฒนาโดยใช้เวิร์กโฟลว์แบบปิด โดยมีซอร์สโค้ดถูกโยนข้ามกำแพงทุกปีโดยประมาณเมื่อมีการออกรุ่นใหม่ เดิมที Google กล่าวว่านี่เป็นการป้องกันการกระจายตัวของผู้คนที่ใช้เวอร์ชันล้ำสมัย ในขณะที่สิ่งต่าง ๆ กำลังพัฒนาอย่างรวดเร็วในช่วงแรก ๆ แต่ดูเหมือนว่าพวกเขาจะยังคงรักษานโยบายนี้ไว้ สถานที่.
ในช่วงเวลาหนึ่ง โดยปกติก่อนการประกาศการอัปเดตสู่สาธารณะ (แม้ว่าจะมีการเปิดตัวเบต้าสาธารณะเมื่อเร็วๆ นี้ แต่ช่วงเวลาเหล่านี้กำลังเปลี่ยนไป) OEM จะได้รับแจ้งถึงการอัปเดตที่กำลังจะเกิดขึ้น. จากนั้นพวกเขาจะได้รับซอร์สโค้ดในเวลาที่สองสำหรับการอัปเดตครั้งสุดท้าย (เมื่อก่อนก็คือ บางครั้งอาจแจ้งล่วงหน้าก่อนการเปิดตัวเล็กน้อย แม้ว่าเราจะทราบถึงกรณีที่ไม่ทันกำหนดก็ตาม ปล่อย).
ที่เก็บอัปสตรีม AOSP มีการสนับสนุนอุปกรณ์สำหรับอุปกรณ์จำนวนจำกัดเท่านั้น โดยปกติแล้วอุปกรณ์เหล่านี้คืออุปกรณ์ Nexus ของคุณ อย่างไรก็ตาม ด้วยเหตุผลที่จะชัดเจนในไม่ช้านี้ โปรดทราบว่า Google ไม่มีการควบคุมฮาร์ดแวร์สำหรับอุปกรณ์เหล่านี้อย่างสมบูรณ์ อุปกรณ์ดังกล่าวผลิตโดย OEM และ OEM นั้นจะซื้อ System-on-Chip (SoC) จากผู้ผลิตชิปเซ็ต
เมื่อซอร์สโค้ดถูกปล่อยออกมา ทีมเฟิร์มแวร์ของ OEM จะ (ในเชิงเปรียบเทียบ) นั่งลงและลุกขึ้นยืน แผนผังแหล่งที่มาหลักของ Android ไม่มีการรองรับฮาร์ดแวร์สำหรับชิปเซ็ตจำนวนมากมายที่ใช้ในอุปกรณ์จัดส่ง ตัวอย่างเช่น ชิปเซ็ต Qualcomm ของคุณมักไม่รองรับภายใน AOSP Exynos ของคุณไม่ใช่อย่างแน่นอนที่สุด Mediatek หรือ HiSilicon? ลืมมันซะ!
BSP ประกอบด้วยไดรเวอร์และ Hardware Abstraction Layer (HAL) ที่จำเป็นในการทำให้ Android ทำงาน
สิ่งที่จำเป็นตอนนี้คือก แพ็คเกจสนับสนุนบอร์ด (BSP). นี่คือแพ็คเกจส่วนประกอบที่เป็นกรรมสิทธิ์ที่เป็นความลับอย่างยิ่ง ซึ่งผู้ผลิตชิปเซ็ตส่งมอบให้กับ OEM โดยผู้ผลิตชิปเซ็ต BSP มีซอร์สโค้ดที่จำเป็นเพื่อให้ OEM สร้าง Android และไดรเวอร์ที่จำเป็นสำหรับอุปกรณ์ของพวกเขา
เป็นที่น่าสังเกตว่า OEM เช่น Qualcomm ไม่จำเป็นต้องไว้วางใจพันธมิตร OEM ของตนอย่างเต็มที่ - BSP จัดทำขึ้นบนพื้นฐานของ "จำเป็นต้องรู้" โดยปกติ OEM จะไม่สามารถเข้าถึงซอร์สโค้ดสำหรับส่วนที่เป็นความลับสุดยอดบางส่วนของอุปกรณ์ (เช่น ซอฟต์แวร์ที่ทำงานบนเบสแบนด์) การปิดส่วนนี้ลงก็อาจมีปัญหาที่อาจเกิดขึ้นเช่นกัน ดังที่แสดงโดยผู้ใกล้ มากมาย และ เป็นประจำ ASN.1 การแยกวิเคราะห์ช่องโหว่.
BSP ประกอบด้วยไดรเวอร์และ Hardware Abstraction Layer (HAL) ที่จำเป็นเพื่อให้ Android ทำงานบนอุปกรณ์ของคุณ AOSP ประกอบด้วยชุด HAL ซึ่งทำหน้าที่เป็นคำจำกัดความเกี่ยวกับสิ่งที่ระบบปฏิบัติการคาดหวังให้ไดรเวอร์ของคุณนำไปใช้ หากต้องการใช้ตัวอย่างที่เรียบง่ายเกินจริงอย่างน่าขัน (และสร้างขึ้นเพื่อวัตถุประสงค์ในการสาธิต) ลองจินตนาการถึงไฟฉายบนโทรศัพท์ของคุณ
ตัวอย่าง HAL - ไฟฉายของคุณ
สมมติว่าอุปกรณ์ของคุณมีไฟฉายอยู่ที่ด้านหลัง (หากคุณมี Nexus 7 2013 คุณจะต้องจินตนาการมากกว่าคนอื่นๆ เล็กน้อย ขออภัย!) สิ่งนี้ถูกควบคุมโดยคนขับ สำหรับตัวอย่างง่ายๆ สุด ๆ ของเรา สมมติว่า v1 HAL บอกว่าคุณควรมีฟังก์ชันหนึ่งที่เรียกว่า "setLED" โดยใช้พารามิเตอร์ตัวเดียว นั่นคือสถานะของแสง มันเป็นบูลีน - จริงหรือเท็จ ใน C จะมีลักษณะดังนี้:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
ฟังก์ชันนี้ถูกกำหนดไว้ภายในซอร์สโค้ด BSP จากนั้น BSP จะถูกคอมไพล์โดย OEM ในระหว่างการสร้าง ROM และนี่กลายเป็นหนึ่งในไลบรารี ".so" ที่เป็นกรรมสิทธิ์บนพาร์ติชันของผู้จำหน่ายหรือพื้นที่ของอุปกรณ์ของคุณ ซึ่งช่วยให้ OEM สามารถเก็บการทำงานของอุปกรณ์บางส่วนไว้เป็นความลับได้ สำหรับตอนนี้ สมมติว่าพวกเขาต้องการไม่ให้ทุกคนเห็นว่าพวกเขาเปิดและปิด LED นั้นอย่างไร
ตอนนี้ลองนึกภาพ Google เปิดตัว HAL เวอร์ชันอัปเดตใน Android เวอร์ชันอนาคต ตอนนี้พวกเขาตัดสินใจว่าเป็นการดีที่จะให้คุณอัปเดตความสว่างของ LED แทนที่จะเปิดหรือปิดเพียงอย่างเดียว บางทีนี่อาจเป็นสำหรับแฟลชแบบปรับได้หรืออาจเป็นเพียงเพื่อบังคับให้อัปเดต HAL และรักษาผู้ผลิตชิปเซ็ตไว้ในธุรกิจ? เราจะให้คุณผู้อ่านได้แสดงความคิดเห็นของคุณเองในเรื่องนั้น การอัปเดต HAL บางอย่างมีประโยชน์ที่ชัดเจน (เช่น Camera HAL ใหม่เผยให้เห็นการถ่ายภาพแบบ Raw และที่คล้ายกัน) ในขณะที่การอัปเดตอื่นๆ มีจุดประสงค์ค่อนข้างชัดเจนน้อยกว่า
ด้วย HAL ใหม่ (สมมติ) เพื่อความสว่าง สมมติว่า Google บอกว่าคุณต้องแสดงฟังก์ชันที่เรียกว่า setLED อีกครั้ง แต่คราวนี้ส่งผ่านจำนวนเต็มเพื่อความสว่าง ตอนนี้ 0 จะปิดมัน และ 255 จะทำให้มันเต็ม
หากคุณเป็น OEM คุณสามารถใช้รหัสลับสุดยอดของคุณเพื่อเปิด LED นั้นและใส่ลงในฟังก์ชันใหม่นี้ได้ คุณอาจใช้การปรับความกว้างพัลส์เพื่อปรับความสว่างของ LED ตามตัวเลข คุณเปลี่ยนฟังก์ชั่นให้ปรากฏดังนี้:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
แล้วไงล่ะ? ตอนนี้ Android เวอร์ชันใหม่นี้เข้ากันไม่ได้กับ "blobs" ที่มีอยู่ OEM ของคุณจำเป็นต้องใช้ Blob ใหม่เหล่านี้ เนื่องจากระบบปฏิบัติการ Android คาดว่าจะเห็นคำจำกัดความของฟังก์ชันใหม่และจะไม่ "ค้นหา" อันเก่าเมื่อมองหาวิธีตั้งค่า LED
ณ จุดนี้ เรามาดูกันว่า ROM แบบกำหนดเอง (ที่สร้างจากแหล่งที่มา) จัดการที่นี่อย่างไร นี่คือสิ่งที่คนฉลาดในหมู่พวกคุณจะต้องตะโกนใส่หน้าจอของคุณตอนนี้ - เพราะเราคือ XDA บ้านของ เอชทีซี HD2,โทรศัพท์ที่มีอายุการใช้งานยาวนานที่สุดในโลก... (บอกตามตรง พวกอัจฉริยะบ้าๆ ตรงนั้นกำลังวิ่งหนีอยู่ Android 6.0 บน HD2 ในปัจจุบัน! ไม่เลวเลยสำหรับโทรศัพท์ที่เดิมมาพร้อมกับ Windows Mobile 6.5 ในปี 2009)
มีหลายวิธีที่ใช้ที่นี่ - บางครั้งนักพัฒนาแฮ็กข้อมูลภายใน ROM และบอกให้ระบบปฏิบัติการใช้คำจำกัดความฟังก์ชันเก่า มันค่อนข้างเลอะเทอะและต้องรักษาการเปลี่ยนแปลงมากมาย อีกวิธีหนึ่งคือการ "ชิม" ไบนารีของ OEM
วิธีการ "shim" คือการเขียนและสร้างไลบรารี่ใหม่เล็กๆ ด้วยตัวเอง ซึ่งมีคำจำกัดความของฟังก์ชันที่ต้องการ - ตัวอย่างเช่น เราจะสนับสนุนความสว่างเป็นจำนวนเต็ม จากนั้น ภายในแผ่นรอง จะมีการแปลให้เป็นไปตามข้อกำหนดของ HAL แบบเก่า สำหรับตัวอย่างของเรา เราอาจบอกว่าความสว่างใดๆ ที่ร้องขอสูงกว่า 128 จะเปิดไฟ LED และอะไรก็ตามที่ต่ำกว่านั้นก็จะปิดความสว่าง หรือคุณสามารถพูดอะไรที่ไม่ใช่ศูนย์เพื่อเปิดเครื่อง มันขึ้นอยู่กับนักพัฒนา พวกเขารวบรวมชิมและให้ Android ใช้แทนอันเนทีฟ แผ่นชิมจะเรียก OEM blob
การ `กด adb` อย่างรวดเร็วและการรีบูตควรจะทำให้ชิมทำงานได้ และให้คุณควบคุมไฟ LED ที่สมมติขึ้นได้ แม้ว่าคุณจะมีเพียง HAL แบบเก่าก็ตาม
ปัญหาคือว่านี่เป็นกระบวนการที่ไม่สมบูรณ์อย่างชัดเจน ตอนนี้คุณจะได้รับนิสัยแปลกๆ - อุปกรณ์นี้จะมีแฟลชที่ค่อนข้างแย่ ซึ่งไม่ว่าจะเปิดเต็มที่หรือปิดเต็มที่ก็ตาม นั่นไม่เหมาะเลย - ระบบปฏิบัติการคิดว่ากำลังสร้างแสงที่นุ่มนวลมาก แต่ LED จริงได้รับการแจ้งว่ากำลังแข่งขันในการแข่งขันดวงอาทิตย์เทียม และกำลังพยายามทำให้คุณตาบอด แต่เดี๋ยวก่อน ชีวิตไม่ได้สมบูรณ์แบบ และตอนนี้คุณมีไฟ LED ที่ใช้งานได้บนโทรศัพท์เครื่องเก่าของคุณแล้ว!
(ใช่แล้ว นี่คือสาเหตุหนึ่งที่ทำให้ผู้ใช้และนักพัฒนา XDA จัดการกับความสามารถอันบ้าคลั่งและบ้าคลั่งในการย้ายพอร์ต จึงเกิดความแปลกและจุดบกพร่อง ฉันหมายถึงห่าที่ กาแล็กซี่ เอส II ดูเหมือนว่าจะใช้งานได้ รอม Android 6.0 แล้ว. โทรศัพท์จำนวนมากที่เปิดตัวเมื่อปีที่แล้วยังไม่มี 6.0!)
ย้อนกลับไปสู่มุมมองของ OEM กันดีกว่า น่าเศร้าที่ OEM ส่วนใหญ่ใช้งานโทรศัพท์อย่างน้อย 1 เครื่องก่อนที่เราอยู่ตอนนี้ พวกเขามุ่งเน้นไปที่โทรศัพท์เครื่องถัดไปที่พวกเขากำลังจะขาย คุณไม่สามารถตำหนิพวกเขาได้จริงๆ เพราะพวกเขาสร้างรายได้จากอุปกรณ์ที่พวกเขาขายเท่านั้น พวกเขาไม่ได้สร้างรายได้จากอุปกรณ์ที่ขายไปเมื่อหนึ่งหรือสองปีก่อน ดังนั้นพวกเขาจึงต้องออกอุปกรณ์ใหม่ๆ ออกมาเรื่อยๆ นี่เป็นเหตุผลหนึ่งที่ HTC และ Blackberry ประสบปัญหา - ไม่ว่าผู้บริหารจำนวนเท่าใดที่ยังคงควบคุม Blackberry Curve เก่าของตนได้ เนื่องจากพวกเขาไม่ได้ขายอุปกรณ์ใหม่ที่นั่น
หาก OEM ไม่ได้รับ BSP พวกเขาจะไม่ใช้วิธีการ XDA ในการแฮ็กบิลด์ด้วยกัน ทำไม ดี, พวกเขาจำเป็นต้องสนับสนุนเฟิร์มแวร์นี้สำหรับลูกค้าของพวกเขา. หากพวกเขาปล่อยเฟิร์มแวร์ที่ทำงานครึ่งเดียว ผู้ใช้จะเกลียดพวกเขา โวยวายและคลั่งไคล้ และคอยส่งเสียงสนับสนุนอย่างต่อเนื่องเป็นเวลาหลายวัน
OEM ก็ต้องแข่งขันกับผู้ให้บริการด้วยอย่างน้อยก็ในตลาดที่ไม่ใช่ยุโรป ผู้ให้บริการไม่ต้องการให้ลูกค้าประสบปัญหากับการอัปเดตซอฟต์แวร์ ในความเป็นจริง ผู้ให้บริการมักจะไม่ปล่อยการอัปเดตซอฟต์แวร์
เพื่อทำความเข้าใจสิ่งนี้ ลองจินตนาการถึงคุณป้าอลิซผู้ยิ่งใหญ่ของคุณ เธอคือคนที่โทรหาคุณในเวลาที่ไม่สะดวกเพื่อขอความช่วยเหลือเกี่ยวกับ "เรื่องคอมพิวเตอร์นั้น" จากนั้นคุณอธิบายวิธีคลิกที่ "เมนู Start" และต้องระบุว่าเป็น "ธงใหญ่ที่มุมซ้ายล่าง" และพบกับความสับสน ประมาณ 45 นาที (และหงุดหงิดมาก) ต่อมา ปรากฏว่าป้าอลิซลากเมนูเริ่มต้นไปที่ขอบหน้าจอด้านขวามือ และเพียงแค่ต้องลากกลับ ใช่ด้วยปุ่มซ้ายของเมาส์!
ลองจินตนาการว่าคุณมีป้าอลิซหนึ่งพันคน' พวกเขาทั้งหมดโทรหาฝ่ายสนับสนุนลูกค้าของคุณ โดยไม่พบ Candy Crush บนโทรศัพท์ของพวกเขา เนื่องจากกังวลว่าแฮกเกอร์จะลบมันออกจากโทรศัพท์ของพวกเขา โอ้ และไอคอนก็ดูแตกต่างไปเล็กน้อยในตอนนี้ - บางทีแฮ็กเกอร์ยังอยู่ในโทรศัพท์ของพวกเขาเหรอ?
ใช่ นี่เป็นเรื่องตลกขบขันเล็กน้อย แต่จนกว่าคุณจะพบสาเหตุที่ผู้คนเรียกผู้ให้บริการมาช่วยเหลือ คุณจะไม่เชื่อปัญหาที่พวกเขามี การอัปเดตซอฟต์แวร์ที่เปลี่ยนแปลงวิธีการทำงานของโทรศัพท์หรือตำแหน่งต่างๆ จะทำให้เกิดค่าใช้จ่ายในการสนับสนุนที่สำคัญ อย่างน้อยที่สุด จำเป็นต้องมีการฝึกอบรมเจ้าหน้าที่ฝ่ายสนับสนุนอีกครั้ง (เพราะส่วนใหญ่ไม่ใช่โปรแกรมอ่าน XDA ตัวยงของคุณ)
เมื่อ OEM ได้รับ BSP แล้ว พวกเขาจะย้าย ROM ไปใช้ และใช้การเปลี่ยนแปลงทั้งหมดกับ ROM พวกเขาจะกองอยู่ในโบลตแวร์ของพวกเขา และเพิ่มสกินการ์ตูนที่น่าสยดสยองที่จะดูเหมือนอยู่บ้านในอนิเมะของวัยรุ่น แล้วพวกเขาจะทดสอบมัน
มาก.
โทรศัพท์ของคุณต้องปฏิบัติตามข้อกำหนดทุกประการ เครือข่ายมือถือได้รับการออกแบบมาเพื่อให้เชื่อถืออุปกรณ์ของผู้ใช้ (สิ่งที่เราเรียกว่าโทรศัพท์) เพื่อให้ทำงานได้อย่างถูกต้อง ซึ่งหมายความว่าต้องมีการทดสอบมากมายเพื่อให้อุปกรณ์ได้รับการอนุมัติ การอัปเดตซอฟต์แวร์มีความเสี่ยงต่อพฤติกรรมที่เปลี่ยนแปลง ดังนั้นสิ่งต่างๆ จึงต้องทดสอบอีกครั้ง ด้วยเหตุนี้คุณจึงมักเห็นข้อมูลเกี่ยวกับการอัปเดตซอฟต์แวร์ของ Sony ที่กำลังจะมีขึ้นจากบริการทดสอบภายนอก ซึ่งยืนยันว่าเฟิร์มแวร์เป็นไปตามข้อกำหนดในการทดสอบ
ตอนนี้... จะเกิดอะไรขึ้นหลังจากการอัพเดตหนึ่งหรือสองครั้ง (หรือในบางกรณีไม่มีเลย) ผู้ผลิต SoC จะไม่ให้ BSP ที่อัปเดตแก่ OEM. ท้ายที่สุดผู้ผลิต SoC จะไม่ได้รับประโยชน์อะไรมากมายจากสิ่งนี้ OEM ไม่ได้ทำเงินกับโทรศัพท์ของคุณอีกต่อไปตั้งแต่ขายไป และ ณ จุดนี้ โทรศัพท์ของคุณจะไม่ได้รับการอัพเดตเวอร์ชันหลักอีกต่อไป
การลดจำนวน BSP ที่ OEM ต้องการจัดส่งเป็นวิธีที่ดีในการประหยัดเงิน หากคุณต้องการเพียงรุ่นปัจจุบัน และไม่ต้องการส่งมอบเวอร์ชันหลักๆ ใดๆ เพิ่มขึ้น ซึ่งจะช่วยประหยัดเงินในการซื้อ SoC และการออกใบอนุญาตครั้งแรก แต่ด้วยค่าใช้จ่ายของพวกเนิร์ดบางคนใน XDA ที่อยู่เบื้องหลัง และสงสัยว่าทำไมพวกเขาถึงไม่ได้รับ อัปเดต.
การอัปเดตมีความซับซ้อน มีผู้คนมากมายที่เกี่ยวข้องกับห่วงโซ่นี้ ไม่มีข้อแก้ตัวใด ๆ ที่เป็นข้อแก้ตัวของ OEM จากสถานะการอัปเดตบน Android ที่ขาดความกระตือรือร้นและน่าสมเพชในปัจจุบัน อย่างไรก็ตาม มีความท้าทายบางประการที่นี่
OEM หลายรายถูกตำหนิว่ามีแนวโน้มมากเกินไป และ การส่งมอบน้อยไปอย่างหลีกเลี่ยงไม่ได้ที่เราเชื่อมโยงอยู่ตอนนี้. ความจริงที่น่าเศร้าก็คือสำหรับ OEM ส่วนใหญ่ การอัปเดตซอฟต์แวร์เป็นเพียงเรื่องน่ารำคาญที่พวกเขาสามารถทำได้โดยไม่ต้องมี
ภาคอุปกรณ์เคลื่อนที่ส่วนใหญ่ติดอยู่กับแนวคิดของฟีเจอร์โฟน นั่นคือจุดที่อุปกรณ์ไม่เคยได้รับการอัปเดตใดๆ ทดสอบครั้งเดียว จัดส่ง และอย่ามองย้อนกลับไป ด้วยปัญหาด้านความปลอดภัยของสมาร์ทโฟนสมัยใหม่ และความซับซ้อนที่แท้จริงของการใช้งานระบบปฏิบัติการทั่วไปเต็มรูปแบบ พร้อมด้วยไลบรารีภายนอกหลายร้อยรายการ นั่นไม่ใช่ทางเลือกอีกต่อไป หรืออย่างน้อยก็ ไม่ควร เป็น. Google ได้ดำเนินการแก้ไขปัญหานี้โดยอย่างน้อยก็เผยแพร่กระดานข่าวและแพตช์ด้านความปลอดภัยสำหรับรุ่นที่มีอยู่ ของ Android (โปรดจำไว้ว่าจนกระทั่งเมื่อไม่นานมานี้ วิธีเดียวที่จะได้รับการอัปเดตความปลอดภัยคือผ่านระบบปฏิบัติการ Android เวอร์ชันหลักใหม่!)
อนิจจา แต่นี่ยังไม่เพียงพอจริงๆ แม้ว่า Google จะออกการอัปเดตต่อไป แต่ความปลอดภัยของอุปกรณ์ของคุณยังคงขึ้นอยู่กับผู้สร้าง SoC - เนื่องจากผู้สร้าง SoC กลายเป็นหินมาก มีคนค้นพบวิธีที่พวกเขาเปิดไฟ LED สองสามดวงหรือส่งเสียงผ่านลำโพง พวกเขาส่งไบนารี่บล็อบจำนวนมหาศาลมาที่ อุปกรณ์ Blob เหล่านี้มีโค้ดที่ค่อนข้างไม่ปลอดภัยอย่างน่ากลัว (ลองดูกระดานข่าวความปลอดภัยของ Google ที่ผ่านมา หากคุณคิดว่านี่เป็นการพูดเกินจริง!) และจำเป็นต้องอัปเดต ซึ่งหมายความว่าจำเป็นต้องมี BSP ที่อัปเดต
คอมพิวเตอร์เดสก์ท็อป (และแล็ปท็อป) มีความแตกต่างอย่างสิ้นเชิงในด้านสถาปัตยกรรมจากอุปกรณ์มือถือ โทรศัพท์มือถือหรือแท็บเล็ตของคุณเป็นก้อนซิลิคอนที่มีกรรมสิทธิ์อย่างมาก ได้รับการออกแบบมาอย่างรวดเร็วโดยบางคนที่มีความหมายดี แต่ไม่มีเวลาพอที่จะทำสิ่งที่ดี ตลาดมีการเคลื่อนไหวอย่างรวดเร็วจนแทบจะไม่สามารถตามทันความต้องการของตลาดที่ต้องการเปิดตัวผลิตภัณฑ์ใหม่ได้
ซึ่งหมายความว่ามีการใช้ทางลัด คุณจะไม่พบโทรศัพท์ของคุณรองรับเคอร์เนล mainline Linux และคุณจะพบว่าโทรศัพท์ทุกเครื่องมีวิธีบูตที่แตกต่างกัน อย่างไรก็ตาม บนแล็ปท็อปหรือเดสก์ท็อปของคุณ ผู้จำหน่ายได้ตัดสินใจเลือกวิธีมาตรฐานในการบูต - ก่อนหน้านี้เป็น MBR (มาสเตอร์บูตเรคคอร์ด) พร้อม BIOS และตอนนี้เป็น UEFI มาตรฐานนี้ทำให้สามารถรันซอฟต์แวร์เดียวกันบนอุปกรณ์แต่ละเครื่องได้
แม้ว่าจะมีการดำเนินการบางอย่างเมื่อเร็วๆ นี้ โดยเฉพาะอย่างยิ่งกับโครงการเผยแพร่ประชาสัมพันธ์ของ Sony และพวกเขา เคอร์เนลแบบรวมการเรียกใช้เคอร์เนล mainline บนโทรศัพท์ส่วนใหญ่นั้นไม่สามารถทำได้ เนื่องจากมีการแฮ็กเฉพาะผู้จำหน่ายรายใหม่จำนวนมากที่เกิดขึ้นกับอุปกรณ์แต่ละเครื่อง
ต่อสายแจ็คหูฟังผิดวิธีหรือเปล่า? เพียงแค่แฮ็คมันในไดรเวอร์! ไม่มีเวลาแก้ไขในการออกแบบการผลิต
ทีมผู้ผลิตได้ติดตั้งโมดูลกล้องกลับหัวในชุดการผลิตที่ 1 หรือไม่? แฮ็กเข้าไปตรวจสอบโค้ดเวอร์ชันภายใน และพลิกวิดีโอไปรอบๆ หากเป็นเวอร์ชัน 1!
การแฮ็กเช่นนี้ช่วยแก้ปัญหาเฉพาะหน้าได้ แต่เพียงขูดผิวเผินของการเปลี่ยนแปลงแปลกๆ และผลิตภัณฑ์เฉพาะที่เกิดขึ้นเท่านั้น เฮ็ค บางครั้งก็มีชิปที่แตกต่างกันอย่างสิ้นเชิงในการแก้ไขที่แตกต่างกันของโทรศัพท์เครื่องเดียวกัน เนื่องจากการตัดสินใจทางการค้า สิ่งเหล่านี้นำไปสู่การแฮ็กไดรเวอร์และการตัดสินใจแปลกๆ ที่สมเหตุสมผลในขณะนั้น เพื่อให้โทรศัพท์ใช้งานได้และสามารถจัดส่งได้ในสัปดาห์หน้า
ในขณะที่มีการทำงานอย่างต่อเนื่องเพื่อสนับสนุนชิป ARM 64 บิตเพื่อบูตโดยใช้ UEFI แต่ก็ยังมีจนถึงขณะนี้ ไม่มีการเคลื่อนไหวที่ชัดเจนไปสู่วิธีการบูตอุปกรณ์ ARM ที่เป็นมาตรฐานมากขึ้น. และนั่นเป็นเรื่องน่าเศร้า เพราะมันหมายความว่าโทรศัพท์จะยังคงถูกโยนทิ้งไปก่อนที่จะหมด ชีวิตการทำงาน เพราะมันแพงเกินไปที่จะรักษาหนี้ทางเทคนิคและภาระของพวกเขา ซอฟต์แวร์.
ในทางกลับกัน หาก OEM จะทำรายได้จากการขายอุปกรณ์เพียงอย่างเดียว พวกเขาไม่จำเป็นต้องรับประกันว่าผู้คนจะยังคงซื้อโทรศัพท์เครื่องใหม่ต่อไปใช่หรือไม่ ตลาดพีซีจะเปลี่ยนไปใช้โมเดลนี้หรือไม่ หากไม่มีแรงผลักดันและซอฟต์แวร์รุ่นเก่ามาเป็นเวลา 30 ปีที่ใช้แพลตฟอร์มและมาตรฐานพีซีแบบเปิดอยู่แล้ว
นี่เป็นคำถามที่ยากหากไม่มีความรู้ภายในจาก Qualcomm ซึ่งน่าเสียดายที่เราไม่มีในขณะนี้ อย่างไรก็ตาม เราสามารถดึงข้อมูลบางอย่างจากข้อกำหนด API ไดรเวอร์ Android 7.0 และ CTS ได้ ข้อกำหนดของ CTS ระบุสิ่งที่ Google คาดหวังจากอุปกรณ์ที่ใช้เฟิร์มแวร์ที่กำหนด "ค้อนใหญ่" ที่ใช้ในการบังคับใช้ข้อกำหนดเหล่านี้คือการอนุญาตให้ใช้สิทธิ์ของ Google ในการใช้ชุดบริการ Google Play ที่เป็นกรรมสิทธิ์ของพวกเขา - ถ้าคุณไม่ปฏิบัติตาม คุณจะไม่สามารถจัดส่ง Google Apps บนอุปกรณ์ได้. ในขณะที่บางคนสิ่งนี้ อาจถูกมองว่าเป็นข้อได้เปรียบเห็นได้ชัดว่านี่ไม่ใช่สิ่งที่ผู้ใช้ต้องการและคาดหวังจากอุปกรณ์
Android 7.0 ไม่ได้เพิ่มการเปลี่ยนแปลง HAL หรือไดรเวอร์มากนัก (ดังที่อธิบายไว้ข้างต้น) ดังนั้นความเข้ากันไม่ได้จึงไม่น่าจะมาจากที่นั่นโดยเฉพาะ อย่างไรก็ตาม สิ่งที่มีแนวโน้มที่จะก่อให้เกิดปัญหามากกว่าคือการแนะนำ a ข้อกำหนดใหม่สำหรับ Vulkan Graphics API หรือ GLES 3.1 เพื่อให้ผ่าน CTS ได้
ในปัจจุบัน Systems-on-Chip (SoC) จำนวนมากยังไม่รองรับ Vulkan บนโปรเซสเซอร์กราฟิก รวมถึง MSM8974 ด้วย นี่เป็นไปได้มากว่าปัญหาความเข้ากันได้กับ Android 7.0 จะเกิดขึ้น ขอย้ำอีกครั้งว่าหากไม่มีความรู้ภายในจาก Qualcomm และแผนการในอนาคตของพวกเขา ก็เป็นเรื่องยากสำหรับเราที่จะให้คำแถลงที่ชัดเจนโดยไม่ผ่านคุณสมบัติดังกล่าว อย่างไรก็ตาม ในขณะนี้ เราเชื่อว่ามีแนวโน้มว่านี่เป็นกรณี "ง่ายๆ" ของการที่ Qualcomm ยุติการสนับสนุน (ในสายตาของพวกเขา) ชิปเซ็ต MSM8974 ที่ล้าสมัย และไม่ได้จัดเตรียม BSP (แพ็คเกจสนับสนุนบอร์ด) สำหรับ 7.0 บนแพลตฟอร์มนั้น หากเป็นเช่นนั้น ก็หมายความว่า OEM เกือบจะแน่ใจว่าจะไม่จัดส่ง 7.0 บนอุปกรณ์ - พวกเขาจะต้องพบว่า Vulkan หรือ GLEs 3.1 รองรับ GPU และแหล่ง GPU ของตน รหัสเป็นหนึ่งในส่วนที่ป้องกันอย่างแน่นหนาของสแต็กมือถือ (เราจะเพิ่มโดยไม่มีเหตุผลที่แท้จริง - ดู AMD, โอเพ่นซอร์สไดรเวอร์ AMDGPU ของตัวเองบนเดสก์ท็อปสำหรับ ลินุกซ์) อย่างไรก็ตาม น่าเศร้าที่กราฟิก Vulkan และ Accelerated (GLES) โดยทั่วไปนั้นซับซ้อนกว่า LED แบบธรรมดาเล็กน้อย ดังนั้นจึงไม่ใช่สิ่งที่เราจะได้เห็นแผ่นรองเพื่อแนะนำความเข้ากันได้
เนื่องจาก 7.0 ไม่ได้ออกมานานแล้ว มีความเป็นไปได้จริงที่ชิปเซ็ตอื่นๆ (นอกเหนือจากจำนวนเล็กน้อยภายใน AOSP เอง) จะถูกทิ้งไว้ ล้าหลังใน 6.0 เนื่องจากปัญหาด้านฮาร์ดแวร์และไดรเวอร์ (เช่น ไม่มี BSP ที่อัปเดต) หรือขาดการสนับสนุนผู้จำหน่าย SoC เกี่ยวกับ Vulkan หรือ GLES 3.1 เอพีไอ ในปัจจุบัน Snapdragon 800 หรือ 801 ไม่รองรับหนึ่งในนั้น
ทางออกที่ดีที่สุดคือการดูพื้นที่นี้ - นักพัฒนาบน XDA กำลังดำเนินการไปด้วยดีอยู่แล้วด้วยพอร์ตที่ไม่เป็นทางการเป็น 7.0 สำหรับอุปกรณ์จำนวนมากที่ไม่ได้รับการรองรับ 7.0 อย่างเป็นทางการจาก Google อย่างไรก็ตาม สิ่งเหล่านี้ไม่รองรับ Vulkan หรือ GLES 3.1 - บางทีผู้พัฒนาเกมบน Android อาจจะเริ่มต้นแล้ว พบกับความหงุดหงิดจากการแตกแฟรกเมนต์หากมีผู้ใช้เพียงพอเริ่มใช้งาน ROM แบบกำหนดเองโดยไม่มี Vulkan หรือ GLES 3.1 สนับสนุน?
Apple มีแนวโน้มที่จะสนับสนุนกลุ่มผลิตภัณฑ์ iPhone บน iOS เวอร์ชันล่าสุดเป็นเวลาประมาณ 5 ปี โดย iPhone 4s เปิดตัวในเดือนตุลาคม 2554 และได้รับการอัปเดตเป็น iOS 9 อย่างไรก็ตาม จะไม่ได้รับการอัปเดต iOS 10 ที่กำลังจะมาถึง ซึ่งจะทำให้โทรศัพท์มีอายุการใช้งาน 5 ปี โดยสมมติว่า iOS 10 จะเปิดตัวประมาณเดือนตุลาคม เป็นที่น่าสังเกตว่า Apple ไม่รองรับ API กราฟิกพอร์ตด้านหลังเสมอไป - iPhone 4s และ iPhone 5 ไม่รองรับ นำเสนอ Metal Graphics API ของ Apple ซึ่งเป็นสถานการณ์ที่ค่อนข้างคล้ายกับที่เห็นใน Android วัลแคน. ข้อแตกต่างเพียงอย่างเดียวคือ Apple ยังคงสนับสนุนอุปกรณ์รุ่นเก่าต่อไปโดยไม่มี API กราฟิกใหม่
คุณคิดอย่างไร? คุณจะแฟลช ROM แบบกำหนดเองบนโทรศัพท์ของคุณเพื่อยืดอายุการใช้งานหรือไม่? คุณพูดในความคิดเห็นด้านล่าง