API ของ Android 4.2

ระดับ API: 17

Android 4.2 (JELLY_BEAN_MR1) คือการอัปเดตรุ่น Jelly Bean ที่นำเสนอฟีเจอร์ใหม่ๆ สำหรับผู้ใช้และแอป เอกสารนี้จะแนะนำ API ใหม่ที่โดดเด่นและมีประโยชน์มากที่สุดสําหรับนักพัฒนาซอฟต์แวร์

ในฐานะนักพัฒนาแอป คุณควรดาวน์โหลดภาพระบบและแพลตฟอร์ม SDK ของ Android 4.2 จากเครื่องมือจัดการ SDK โดยเร็วที่สุด หากไม่มีอุปกรณ์ที่ใช้ Android 4.2 ในการทดสอบแอป ให้ใช้ภาพระบบ Android 4.2 เพื่อทดสอบแอปในโปรแกรมจำลอง Android จากนั้นสร้างแอปบนแพลตฟอร์ม Android 4.2 เพื่อเริ่มใช้ API ล่าสุด

หากต้องการเพิ่มประสิทธิภาพแอปสำหรับอุปกรณ์ที่ใช้ Android 4.2 ให้ดีขึ้น คุณควรตั้งค่า targetSdkVersion เป็น "17" ติดตั้งในภาพระบบ Android 4.2 ทดสอบ แล้วเผยแพร่การอัปเดตที่มีการเปลี่ยนแปลงนี้

คุณสามารถใช้ API ใน Android 4.2 ไปพร้อมกับรองรับเวอร์ชันเก่าได้ด้วยการเพิ่มเงื่อนไขลงในโค้ดที่ตรวจสอบระดับ API ของระบบก่อนเรียกใช้ API ที่ minSdkVersion ไม่รองรับ ดูข้อมูลเพิ่มเติมเกี่ยวกับการคงความเข้ากันได้แบบย้อนหลังได้ที่การสร้าง UI ที่ใช้งานย้อนหลังได้

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงานของระดับ API ได้ที่ระดับ API คืออะไร

การเปลี่ยนแปลงลักษณะการทำงานที่สำคัญ

หากคุณเคยเผยแพร่แอปสำหรับ Android โปรดทราบว่าการเปลี่ยนแปลงต่อไปนี้อาจส่งผลต่อลักษณะการทํางานของแอป

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

    การเปลี่ยนแปลงนี้จะมีผลก็ต่อเมื่อคุณตั้งค่า android:targetSdkVersion หรือ android:minSdkVersion เป็น 17 ขึ้นไป ไม่เช่นนั้น ค่าเริ่มต้นจะยังคงเป็น “true" แม้ว่าจะใช้งานบน Android 4.2 ขึ้นไปก็ตาม

  • ผลลัพธ์ของตำแหน่งของผู้ใช้อาจมีความแม่นยำน้อยกว่าเมื่อเทียบกับ Android เวอร์ชันก่อนหน้า หากแอปขอสิทธิ์ ACCESS_COARSE_LOCATION แต่ ไม่ได้ขอสิทธิ์ ACCESS_FINE_LOCATION

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

  • การตั้งค่าอุปกรณ์บางอย่างที่ Settings.System กำหนดไว้ตอนนี้ อ่านอย่างเดียว หากแอปพยายามเขียนการเปลี่ยนแปลงการตั้งค่าที่กำหนดไว้ใน Settings.System ซึ่งย้ายไปที่ Settings.Global แล้ว การเขียนจะล้มเหลวโดยไม่มีการแจ้งเตือนเมื่อทำงานใน Android 4.2 และสูงกว่า

    แม้ว่าค่าสำหรับ android:targetSdkVersion และ android:minSdkVersion ของคุณจะต่ำกว่า 17 แต่แอปจะไม่สามารถแก้ไขการตั้งค่าที่มี ย้ายไปที่ Settings.Global ขณะใช้ Android 4.2 ขึ้นไป

  • หากแอปใช้ WebView ทาง Android 4.2 จะเพิ่มการรักษาความปลอดภัยอีกชั้นหนึ่งเพื่อให้คุณเชื่อมโยง JavaScript กับโค้ด Android ได้อย่างปลอดภัยยิ่งขึ้น หากคุณตั้งค่า targetSdkVersion เป็น 17 ขึ้นไป ตอนนี้คุณต้องเพิ่มคำอธิบายประกอบ @JavascriptInterface ลงในเมธอดที่ต้องการให้ JavaScript ใช้งานได้ (เมธอดต้องเป็นแบบสาธารณะด้วย) หากคุณไม่ได้ใส่คำอธิบายประกอบ หน้าเว็บใน WebView ของคุณจะเข้าถึงเมธอดไม่ได้เมื่อเรียกใช้บน Android 4.2 ขึ้นไป หากคุณตั้งค่า targetSdkVersion เป็น 16 หรือต่ำกว่านั้น ก็ไม่จำเป็นต้องใช้คำอธิบายประกอบ แต่เราขอแนะนำให้คุณอัปเดตเวอร์ชันเป้าหมาย และเพิ่มคำอธิบายประกอบเพื่อเพิ่มความปลอดภัย

    อ่านเพิ่มเติมเกี่ยวกับการเชื่อมโยงโค้ด JavaScript กับโค้ด Android

Daydream

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

คุณสามารถสร้างฝันสำหรับ Daydream ได้โดยใช้คลาสย่อยของ DreamService API ของ DreamService คือ ออกแบบมาให้คล้ายกับของ Activity หากต้องการระบุ UI สำหรับ onAttachedToWindow() ให้ส่งรหัสทรัพยากรเลย์เอาต์หรือ View ไปยัง setContentView() เมื่อใดก็ได้หลังจากที่คุณมีหน้าต่าง เช่น จาก onAttachedToWindow() callback

คลาส DreamService มีเมธอดการเรียกกลับที่สําคัญอื่นๆ เกี่ยวกับวงจรการทํางานนอกเหนือจาก API Service พื้นฐาน เช่น onDreamingStarted(), onDreamingStopped() และ onDetachedFromWindow() คุณไม่สามารถเริ่มต้น DreamService จาก แอปจะทำงานโดยอัตโนมัติ

หากความฝันเป็นแบบอินเทอร์แอกทีฟ คุณเริ่มกิจกรรมจากความฝันเพื่อส่งผู้ใช้ไปได้ UI แบบเต็มของแอปสำหรับรายละเอียดหรือการควบคุมเพิ่มเติม คุณสามารถใช้ finish() เพื่อสิ้นสุดความฝันเพื่อให้ผู้ใช้เห็นกิจกรรมใหม่

หากต้องการให้ระบบแสดง Daydream ให้ประกาศ DreamService ด้วยองค์ประกอบ <service> ในไฟล์ Manifest จากนั้นคุณต้องใส่ตัวกรอง Intent ที่มีการดำเนินการ "android.service.dreams.DreamService" เช่น

<service android:name=".MyDream" android:exported="true"
    android:icon="@drawable/dream_icon" android:label="@string/dream_label" >
    <intent-filter>
        <action android:name="android.service.dreams.DreamService" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</service>

ยังมีวิธีอื่นที่เป็นประโยชน์ใน DreamService ที่ควรทราบในเรื่องต่อไปนี้

  • setInteractive(boolean) ควบคุมว่าระบบจะรับเหตุการณ์อินพุตของดรีมหรือจะออกทันทีเมื่อผู้ใช้ป้อนข้อมูล หากเป็นดรีมแบบอินเทอร์แอกทีฟ ผู้ใช้อาจใช้ปุ่มย้อนกลับหรือหน้าแรกเพื่อออกจากดรีม หรือคุณจะเรียกใช้ finish() เพื่อหยุดดรีมก็ได้
  • หากต้องการการแสดงผลที่สมจริงแบบเต็มหน้าจอ ให้กด setFullscreen() เพื่อซ่อนแถบสถานะ
  • ก่อนที่เดย์ดรีมจะเริ่มต้นขึ้น จอแสดงผลจะหรี่แสงลงเพื่อส่งสัญญาณให้ผู้ใช้ทราบว่าการหมดเวลาเมื่อไม่มีการใช้งาน ใกล้เข้ามาแล้ว การโทรหา setScreenBright(true) ช่วยให้คุณตั้งค่าจอแสดงผลให้สว่างตามปกติได้

ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบของ DreamService

จอแสดงผลสำรอง

ตอนนี้ Android อนุญาตให้แอปของคุณแสดงเนื้อหาที่ไม่ซ้ำกันบนหน้าจอเพิ่มเติมที่เชื่อมต่อกับอุปกรณ์ของผู้ใช้ผ่านการเชื่อมต่อแบบใช้สายหรือ Wi-Fi หากต้องการสร้างเนื้อหาที่ไม่ซ้ำกันสำหรับจอแสดงผลรอง ให้ขยายPresentation class และใช้การเรียกกลับ onCreate() ภายใน onCreate() ให้ระบุ UI สําหรับจอแสดงผลรองโดยเรียกใช้ setContentView() คลาส Presentation เป็นส่วนขยายของคลาส Dialog ที่ให้ภูมิภาคที่แอปของคุณสามารถแสดง UI ที่ไม่ซ้ำกันบน จอแสดงผลรอง

หากต้องการตรวจหาจอแสดงผลรองที่คุณสามารถแสดง Presentation ให้ใช้ API DisplayManager หรือ MediaRouter แม้ว่า DisplayManager API จะช่วยให้คุณแจกแจงจอแสดงผลหลายจอที่อาจเชื่อมต่อพร้อมกันได้ แต่โดยปกติแล้วคุณควรใช้ MediaRouter แทนเพื่อเข้าถึงจอแสดงผลเริ่มต้นของระบบสำหรับการนำเสนออย่างรวดเร็ว

หากต้องการใช้การแสดงผลเริ่มต้นสำหรับงานนำเสนอ ให้โทรหา MediaRouter.getSelectedRoute() เพื่อส่งต่อให้ ROUTE_TYPE_LIVE_VIDEO ซึ่งจะแสดงผลออบเจ็กต์ MediaRouter.RouteInfo ที่อธิบายเส้นทางที่ระบบเลือกอยู่ในปัจจุบันสําหรับงานนำเสนอวิดีโอ หาก MediaRouter.RouteInfo ไม่ใช่ค่าว่าง ให้เรียกใช้ getPresentationDisplay() เพื่อรับ Display ที่แสดงถึงจอแสดงผลที่เชื่อมต่อ

จากนั้นคุณสามารถแสดงงานนำเสนอได้โดยส่งออบเจ็กต์ Display ให้กับคอนสตรัคเตอร์ของคลาส Presentation ตอนนี้งานนำเสนอของคุณจะ จะปรากฏขึ้นบนจอแสดงผลรอง

หากต้องการตรวจหาขณะรันไทม์เมื่อมีการเชื่อมต่อจอแสดงผลใหม่ ให้สร้างอินสแตนซ์ของ MediaRouter.SimpleCallback ที่คุณใช้เมธอด Callback onRoutePresentationDisplayChanged() ซึ่งระบบจะเรียกเมื่อมี เชื่อมต่อจอแสดงผลของงานนำเสนอแล้ว จากนั้นลงทะเบียน MediaRouter.SimpleCallback โดยส่งไปยัง MediaRouter.addCallback() พร้อมกับประเภทเส้นทาง ROUTE_TYPE_LIVE_VIDEO เมื่อคุณรับสายที่ onRoutePresentationDisplayChanged() โปรดโทรหา MediaRouter.getSelectedRoute() ดังที่กล่าวไว้ข้างต้น

หากต้องการเพิ่มประสิทธิภาพ UI ใน Presentation สำหรับหน้าจอรอง ให้ใช้ธีมอื่นโดยระบุแอตทริบิวต์ android:presentationTheme ใน <style> ที่คุณใช้กับแอปพลิเคชันหรือกิจกรรม

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

ดูข้อมูลเพิ่มเติมและตัวอย่างโค้ดบางส่วนได้ที่ Presentation เอกสารของชั้นเรียน

วิดเจ็ตล็อกหน้าจอ

ตอนนี้ Android อนุญาตให้ผู้ใช้เพิ่มวิดเจ็ตของแอปลงในหน้าจอล็อกได้แล้ว หากต้องการทำให้วิดเจ็ตแอปใช้งานได้ใน ในหน้าจอล็อก ให้เพิ่มแอตทริบิวต์ android:widgetCategory ลงในไฟล์ XML ที่ระบุ AppWidgetProviderInfo แอตทริบิวต์นี้รองรับ 2 ค่า ได้แก่ home_screen และ keyguard โดยค่าเริ่มต้น แอตทริบิวต์จะตั้งเป็น home_screen เพื่อให้ผู้ใช้สามารถเพิ่ม วิดเจ็ตของแอปบนหน้าจอหลัก หากคุณต้องการให้วิดเจ็ตแอปพร้อมใช้งานบนล็อกด้วย ให้บวกค่า keyguard

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    ...
    android:widgetCategory="keyguard|home_screen">
</appwidget-provider>

คุณควรระบุเลย์เอาต์เริ่มต้นสำหรับวิดเจ็ตแอปเมื่ออยู่ในหน้าจอล็อกกับ แอตทริบิวต์ android:initialKeyguardLayout ซึ่งจะทำงานในลักษณะเดียวกับ android:initialLayout ตรงที่จะมีเลย์เอาต์ที่ปรากฏได้ทันทีจนกว่าวิดเจ็ตแอปจะเริ่มต้นและอัปเดตเลย์เอาต์ได้

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

ผู้ใช้หลายคน

ขณะนี้ Android อนุญาตให้มีพื้นที่สำหรับผู้ใช้หลายคนในอุปกรณ์ที่แชร์ได้ เช่น แท็บเล็ต ผู้ใช้แต่ละคนในอุปกรณ์จะมีชุดบัญชี แอป การตั้งค่าระบบ ไฟล์ และข้อมูลอื่นๆ ที่เชื่อมโยงกับผู้ใช้

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

การบันทึกข้อมูลในสภาพแวดล้อมที่มีผู้ใช้หลายคน

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

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

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

การระบุผู้ใช้ในสภาพแวดล้อมแบบผู้ใช้หลายคน

หากแอปต้องการระบุผู้ใช้ที่ไม่ซ้ำ เช่น เพื่อรวบรวมข้อมูลวิเคราะห์หรือสร้างบัญชีอื่น คุณควรปฏิบัติตามแนวทางปฏิบัติที่แนะนำสำหรับการระบุ มีการติดตั้งที่ไม่ซ้ำกับที่อื่น โดยการสร้าง UUID ใหม่เมื่อแอปเริ่มทำงานสำหรับ ครั้งแรก คุณมั่นใจได้เลยว่าจะได้รับรหัสที่ไม่ซ้ำสำหรับการติดตามผู้ใช้แต่ละราย ไม่ว่าจะมีผู้ใช้ ผู้ใช้ที่ติดตั้งแอปของคุณ ในอุปกรณ์เครื่องเดียว หรือจะบันทึกโทเค็นในเครื่องที่ดึงมาจากเซิร์ฟเวอร์หรือใช้รหัสการลงทะเบียนที่ Google Cloud Messaging ระบุก็ได้

โปรดระวังว่าหากแอปของคุณขอตัวระบุอุปกรณ์ฮาร์ดแวร์อย่างใดอย่างหนึ่ง (เช่น MAC ของ WiFi หรือหมายเลข SERIAL) พวกเขาจะระบุค่าเดียวกันสำหรับแต่ละรายการ เนื่องจากตัวระบุเหล่านี้เชื่อมโยงกับฮาร์ดแวร์ ไม่ใช่ตัวผู้ใช้ ยังไม่นับปัญหาอื่นๆ ที่ตัวระบุเหล่านี้ทำให้เกิดขึ้นตามที่ได้กล่าวไว้ในบล็อกโพสต์การระบุการติดตั้งแอป

การตั้งค่าส่วนกลางใหม่

เราได้อัปเดตการตั้งค่าระบบเพื่อรองรับผู้ใช้หลายคนด้วยการเพิ่ม Settings.Global ชุดการตั้งค่านี้คล้ายกับการตั้งค่า Settings.Secure เนื่องจากเป็นแบบอ่านอย่างเดียว แต่มีผลกับพื้นที่ทำงานของผู้ใช้ทั้งหมดในอุปกรณ์

การตั้งค่าที่มีอยู่หลายรายการถูกย้ายมาที่นี่จาก Settings.System หรือ Settings.Secure หากแอปของคุณคือ กำลังทำการเปลี่ยนแปลงการตั้งค่าที่เคยกำหนดไว้ใน Settings.System (เช่น AIRPLANE_MODE_ON) คุณควรคาดหวังว่า การทำเช่นนี้จะใช้ไม่ได้กับอุปกรณ์ที่ใช้ Android 4.2 หรือสูงกว่าหากการตั้งค่าเหล่านั้น ย้ายไปที่ Settings.Global คุณจะอ่านการตั้งค่าที่อยู่ใน Settings.Global ได้ต่อไป แต่เนื่องจากการตั้งค่าดังกล่าวไม่ถือว่าปลอดภัยสําหรับแอปที่จะเปลี่ยนแปลงอีกต่อไป การพยายามเปลี่ยนแปลงการตั้งค่าดังกล่าวจึงจะดำเนินการไม่สำเร็จโดยอัตโนมัติ และระบบจะเขียนคำเตือนลงในบันทึกของระบบเมื่อเรียกใช้แอปใน Android 4.2 ขึ้นไป

การรองรับเลย์เอาต์ RTL

ตอนนี้ Android มี API หลายรายการที่ช่วยให้คุณสร้างอินเทอร์เฟซผู้ใช้ที่เปลี่ยนการวางแนวเลย์เอาต์อย่างราบรื่นเพื่อรองรับภาษาที่ใช้ UI และทิศทางการอ่านจากขวาไปซ้าย (RTL) เช่น อาหรับและฮีบรู

หากต้องการเริ่มรองรับเลย์เอาต์ RTL ในแอป ให้ตั้งค่าแอตทริบิวต์ android:supportsRtl ให้กับองค์ประกอบ <application> ในไฟล์ Manifest และตั้งค่าเป็น “true" เมื่อเปิดใช้แล้ว ระบบจะเปิดใช้ RTL API ต่างๆ เพื่อแสดงแอปของคุณด้วยเลย์เอาต์ RTL ตัวอย่างเช่น แถบการดำเนินการจะแสดงไอคอนและชื่อ ด้านขวาและปุ่มดำเนินการทางด้านซ้าย และเลย์เอาต์ที่คุณสร้างขึ้นด้วย ระบบจะกลับคลาส View ที่ได้จากเฟรมเวิร์กด้วย

หากคุณต้องการเพิ่มประสิทธิภาพลักษณะที่ปรากฏของแอปเพิ่มเติมเมื่อแสดงด้วยเลย์เอาต์ RTL การเพิ่มประสิทธิภาพพื้นฐานมีอยู่ 2 ระดับดังนี้

  1. แปลงคุณสมบัติเลย์เอาต์ทางซ้ายและขวาเป็นเลย์เอาต์ที่มุ่งเน้นจุดเริ่มต้นและจุดสิ้นสุด พร็อพเพอร์ตี้

    เช่น ใช้ android:layout_marginStart แทน android:layout_marginLeft และ android:layout_marginEnd แทน android:layout_marginRight

    นอกจากนี้ คลาส RelativeLayout ยังมีแอตทริบิวต์เลย์เอาต์ที่เกี่ยวข้องเพื่อแทนที่ตำแหน่งซ้าย/ขวา เช่น android:layout_alignParentStart เพื่อแทนที่ android:layout_alignParentLeft และ android:layout_toStartOf แทนที่ android:layout_toLeftOf

  2. หรือหากต้องการเพิ่มประสิทธิภาพเลย์เอาต์ RTL อย่างสมบูรณ์ ให้ระบุไฟล์เลย์เอาต์แยกต่างหากโดยใช้ตัวระบุทรัพยากร ldrtl (ldrtl ย่อมาจาก layout-direction-right-to-left}) ตัวอย่างเช่น คุณสามารถบันทึกไฟล์เลย์เอาต์เริ่มต้นใน res/layout/ และเลย์เอาต์ที่เพิ่มประสิทธิภาพ RTL ใน res/layout-ldrtl/

    ตัวคําจํากัด ldrtl เหมาะสําหรับทรัพยากรที่วาดได้ เพื่อให้คุณระบุกราฟิกที่วางแนวในทิศทางที่สอดคล้องกับทิศทางการอ่านได้

มี API อื่นๆ อีกมากมายในเฟรมเวิร์กเพื่อรองรับเลย์เอาต์ RTL เช่น ในคลาส View เพื่อให้คุณใช้ลักษณะการทำงานที่เหมาะสมกับมุมมองที่กำหนดเองได้ และใน Configuration เพื่อค้นหาทิศทางของเลย์เอาต์ปัจจุบัน

หมายเหตุ: หากคุณใช้ SQlite และมีชื่อตารางหรือคอลัมน์เป็น "ตัวเลขเท่านั้น" โปรดระมัดระวัง เนื่องจากการใช้ String.format(String, Object...) อาจทำให้เกิดข้อผิดพลาดเมื่อระบบแปลงตัวเลขเป็นค่าเทียบเท่าภาษาอาหรับหากตั้งค่าอุปกรณ์เป็นภาษาอาหรับ คุณต้องใช้ String.format(Locale,String,Object...) เพื่อให้แน่ใจว่าหมายเลข เป็น ASCII นอกจากนี้ ให้ใช้ String.format("%d", int) แทนการใช้ String.valueOf(int) เพื่อจัดรูปแบบตัวเลข

ส่วนย่อยที่ซ้อนกัน

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

หากต้องการฝังข้อมูลโค้ด ให้เรียกใช้ getChildFragmentManager() ใน Fragment ที่ต้องการเพิ่มข้อมูลโค้ด ซึ่งจะแสดงผล FragmentManager ที่คุณสามารถใช้ได้ตามปกติจากกิจกรรมระดับบนสุดเพื่อสร้างธุรกรรมของข้อมูลโค้ด ลองดูตัวอย่างโค้ดที่เพิ่มส่วนย่อยจากในด้านล่างนี้ ชั้นเรียน Fragment ที่มีอยู่แล้ว

Kotlin

val videoFragment = VideoPlayerFragment()
childFragmentManager.beginTransaction().apply {
    add(R.id.video_fragment, videoFragment)
    commit()
}

Java

Fragment videoFragment = new VideoPlayerFragment();
FragmentTransaction transaction = getChildFragmentManager().beginTransaction();
transaction.add(R.id.video_fragment, videoFragment).commit();

จากภายในส่วนย่อยที่ฝังอยู่ คุณสามารถรับการอ้างอิงไปยังส่วนย่อยระดับบนสุดได้ด้วยการเรียก getParentFragment()

ขณะนี้ Android Support Library รองรับ Fragment ที่ซ้อนกันและคุณจะใช้ฟีเจอร์ที่ซ้อนกันได้ การออกแบบ Fragment ใน Android 1.6 ขึ้นไป

หมายเหตุ: คุณไม่สามารถขยายเลย์เอาต์เป็นแฟรกเมนต์ได้เมื่อเลย์เอาต์นั้นประกอบด้วย <fragment> ระบบจะรองรับเฉพาะการฝังข้อมูลเมื่อเพิ่มลงในข้อมูลแบบไดนามิก

Renderscript

ฟังก์ชันการประมวลผลของ Renderscript ได้รับการปรับปรุงด้วยฟีเจอร์ต่อไปนี้

ลักษณะเฉพาะของสคริปต์

คุณสามารถใช้อินทริเอตสคริปต์ในตัวของ Renderscript ซึ่งใช้การดำเนินการทั่วไปให้คุณ เช่น

หากต้องการใช้สคริปต์ภายใน ให้เรียกเมธอด create() แบบคงที่ของแต่ละ instrinsic เพื่อสร้างอินสแตนซ์ของสคริปต์ จากนั้นโทรหา set() ที่ว่างอยู่ ของแต่ละสคริปต์ภายใน การตั้งค่าอินพุตและตัวเลือกที่จำเป็น สุดท้าย โทรหา forEach() เพื่อเรียกใช้สคริปต์

กลุ่มสคริปต์

ScriptGroup ช่วยให้คุณเชื่อมต่อสคริปต์ Renderscript ที่เกี่ยวข้องเข้าด้วยกันและเรียกใช้ด้วยการเรียกใช้เพียงครั้งเดียว

ใช้ ScriptGroup.Builder เพื่อเพิ่มสคริปต์ทั้งหมดไปยังกลุ่ม โดยโทรไปที่ addKernel() เมื่อเพิ่มสคริปต์ทั้งหมดแล้ว ให้สร้างการเชื่อมต่อระหว่างสคริปต์โดยเรียกใช้ addConnection() เมื่อเพิ่มการเชื่อมต่อเสร็จแล้ว ให้เรียกใช้ create() เพื่อสร้างกลุ่มสคริปต์ ก่อนเรียกใช้กลุ่มสคริปต์ ให้ระบุอินพุต Allocation และสคริปต์เริ่มต้นที่จะเรียกใช้ด้วยเมธอด setInput(Script.KernelID, Allocation) รวมถึงระบุเอาต์พุต Allocation ที่ระบบจะเขียนผลลัพธ์และสคริปต์สุดท้ายที่จะเรียกใช้ด้วย setOutput() สุดท้าย ให้เรียกใช้ execute() เพื่อเรียกใช้กลุ่มสคริปต์

Filterscript

Filterscript จะกำหนดข้อจำกัดใน Renderscript API ที่มีอยู่ ซึ่งช่วยให้โค้ดที่ได้ทำงานบนโปรเซสเซอร์ที่หลากหลายมากขึ้น (CPU, GPU และ DSP) หากต้องการสร้างไฟล์ Filterscript ให้สร้างไฟล์ .fs แทนไฟล์ .rs และระบุ #pragma rs_fp_relaxed เพื่อบอกรันไทม์ Renderscript ว่าสคริปต์ของคุณไม่จำเป็นต้องใช้ความแม่นยำของจุดทศนิยมตามมาตรฐาน IEEE 754-2008 อย่างเข้มงวด ความแม่นยำนี้ช่วยให้ปัดเศษเป็น 0 สำหรับค่าที่ไม่ใช่ค่าปกติและการปัดเศษให้ใกล้กับ 0 นอกจากนี้ สคริปต์ Filterscript ต้องไม่ใช้ประเภทในตัวแบบ 32 บิต และต้องระบุฟังก์ชันรูทที่กำหนดเองโดยใช้แอตทริบิวต์ __attribute__((kernel)) เนื่องจาก Filterscript ไม่รองรับพอยน์เตอร์ ซึ่งการระบุลายเซ็นเริ่มต้นของฟังก์ชัน root() จะเป็นการกำหนด

หมายเหตุ: แม้ว่าจะมีการรองรับ filterscript อยู่ในแพลตฟอร์ม แต่นักพัฒนาซอฟต์แวร์ การสนับสนุนจะพร้อมใช้งานในเครื่องมือ SDK รุ่น 21.0.1

ดูรายละเอียดการเปลี่ยนแปลง API ทั้งหมดใน Android 4.2 ได้ที่รายงานความแตกต่างของ API