คู่มือการทดสอบ Android 6.0
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Android 6.0 ช่วยให้คุณมั่นใจได้ว่าแอปจะทำงานร่วมกับแพลตฟอร์มเวอร์ชันถัดไปได้ เวอร์ชันนี้มี API และการเปลี่ยนแปลงลักษณะการทำงานหลายรายการที่อาจส่งผลต่อแอปของคุณ ตามที่อธิบายไว้ในภาพรวม API และการเปลี่ยนแปลงลักษณะการทำงาน ในการทดสอบแอปกับรุ่นนี้ มีการเปลี่ยนแปลงระบบบางอย่างที่คุณควรมุ่งเน้นเพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดี
คู่มือนี้จะอธิบายถึงสิ่งที่ต้องทดสอบและวิธีทดสอบฟีเจอร์ของ Android 6.0 กับแอปของคุณ คุณควรให้ความสําคัญกับการทดสอบฟีเจอร์ต่อไปนี้เนื่องจากมีแนวโน้มที่จะส่งผลต่อลักษณะการทํางานของแอป
การทดสอบสิทธิ์
โมเดลสิทธิ์ใหม่เปลี่ยนวิธีที่ผู้ใช้จัดสรรสิทธิ์ให้กับแอปของคุณ แอปของคุณต้องขอสิทธิ์แต่ละรายการจากผู้ใช้ขณะรันไทม์แทนการให้สิทธิ์ทั้งหมดในระหว่างกระบวนการติดตั้ง สําหรับผู้ใช้ ลักษณะการทํางานนี้ช่วยให้ควบคุมกิจกรรมของแอปแต่ละแอปได้อย่างละเอียดยิ่งขึ้น รวมถึงมีบริบทที่ดีขึ้นสําหรับทําความเข้าใจสาเหตุที่แอปขอสิทธิ์หนึ่งๆ ผู้ใช้สามารถให้หรือเพิกถอนสิทธิ์ที่ให้แก่แอปแต่ละรายการได้ทุกเมื่อ ฟีเจอร์นี้ของรุ่นมีแนวโน้มที่จะส่งผลต่อลักษณะการทำงานของแอปมากที่สุด และอาจขัดขวางไม่ให้ฟีเจอร์บางอย่างของแอปทำงานได้ หรืออาจอยู่ในสถานะที่ประสิทธิภาพลดลง
การเปลี่ยนแปลงนี้จะส่งผลต่อแอปทั้งหมดที่ทำงานบนแพลตฟอร์มใหม่ แม้ว่าแอปเหล่านั้นจะไม่กําหนดเป้าหมายเป็นแพลตฟอร์มเวอร์ชันใหม่ก็ตาม แพลตฟอร์มนี้มีลักษณะการทำงานที่จำกัดสำหรับแอปเดิม แต่คุณควรเริ่มวางแผนการย้ายข้อมูลแอปไปยังโมเดลสิทธิ์ใหม่ตั้งแต่ตอนนี้ โดยมีเป้าหมายเพื่อเผยแพร่แอปเวอร์ชันอัปเดตในการเปิดตัวแพลตฟอร์มอย่างเป็นทางการ
เคล็ดลับการทดสอบ
ใช้เคล็ดลับการทดสอบต่อไปนี้เพื่อช่วยคุณวางแผนและทำการทดสอบแอปด้วยลักษณะการทํางานของสิทธิ์แบบใหม่
- ระบุสิทธิ์ปัจจุบันของแอปและเส้นทางโค้ดที่เกี่ยวข้อง
- ทดสอบโฟลว์ของผู้ใช้ในบริการและข้อมูลที่ได้รับการคุ้มครองสิทธิ์
- ทดสอบด้วยชุดค่าผสมต่างๆ ของสิทธิ์ที่อนุญาต/เพิกถอน
- ใช้เครื่องมือ
adb เพื่อจัดการสิทธิ์จากบรรทัดคำสั่ง โดยทำดังนี้
- แสดงรายการสิทธิ์และสถานะตามกลุ่ม:
adb shell pm list permissions -d -g
- ให้หรือเพิกถอนสิทธิ์อย่างน้อย 1 รายการโดยใช้ไวยากรณ์ต่อไปนี้
adb shell pm [grant|revoke] <permission.name> ...
- วิเคราะห์แอปเพื่อหาบริการที่ใช้สิทธิ์
กลยุทธ์การทดสอบ
การเปลี่ยนแปลงสิทธิ์จะส่งผลต่อโครงสร้างและการออกแบบแอป รวมถึงประสบการณ์ของผู้ใช้และขั้นตอนที่คุณมอบให้ผู้ใช้ คุณควรประเมินการใช้สิทธิ์ปัจจุบันของแอปและเริ่มวางแผนสำหรับขั้นตอนใหม่ที่ต้องการนำเสนอ การเปิดตัวแพลตฟอร์มอย่างเป็นทางการจะมีลักษณะการทำงานความเข้ากันได้ แต่คุณควรวางแผนอัปเดตแอปและไม่ใช้ลักษณะการทำงานเหล่านี้
ระบุสิทธิ์ที่แอปต้องการและใช้จริงๆ จากนั้นค้นหาเส้นทางโค้ดต่างๆ ที่ใช้บริการที่ได้รับการคุ้มครองสิทธิ์ ซึ่งทำได้โดยผสมผสานการทดสอบในแพลตฟอร์มใหม่และการวิเคราะห์โค้ด ในการทดสอบ คุณควรมุ่งเน้นที่การเลือกรับสิทธิ์รันไทม์โดยเปลี่ยน targetSdkVersion ของแอปเป็น API ระดับ 23
ทดสอบด้วยชุดค่าผสมต่างๆ ของสิทธิ์ที่เพิกถอนและเพิ่ม เพื่อไฮไลต์ขั้นตอนของผู้ใช้ที่ขึ้นอยู่กับสิทธิ์ ในกรณีที่ความเกี่ยวข้องไม่ชัดเจนหรือไม่เป็นเหตุผล คุณควรพิจารณา refactoring หรือแบ่งส่วนการทํางานของขั้นตอนนั้นเพื่อขจัดความเกี่ยวข้อง หรือระบุให้ชัดเจนว่าเหตุใดจึงต้องใช้สิทธิ์
ดูข้อมูลเพิ่มเติมเกี่ยวกับลักษณะการทํางานของสิทธิ์รันไทม์ การทดสอบ และแนวทางปฏิบัติแนะนําได้ที่การทํางานกับสิทธิ์ของระบบสําหรับนักพัฒนาแอป
การทดสอบโหมด Doze และสแตนด์บายแอป
ฟีเจอร์ประหยัดพลังงานของโหมดสลีปและโหมดสแตนด์บายของแอปจะจำกัดปริมาณการประมวลผลเบื้องหลังที่แอปของคุณทำได้เมื่ออุปกรณ์อยู่ในสถานะไม่มีการใช้งานหรือขณะที่แอปไม่ได้อยู่ในโฟกัส ข้อจำกัดที่ระบบอาจกำหนดให้กับแอป ได้แก่ การเข้าถึงเครือข่ายแบบจำกัดหรือไม่มีสิทธิ์เข้าถึง งานที่ทำงานอยู่เบื้องหลังถูกระงับ การแจ้งเตือนถูกระงับ คำขอปลุกที่ถูกละเว้น และสัญญาณเตือน คุณควรทดสอบแอปโดยจำลองสถานะพลังงานต่ำเหล่านี้เพื่อให้แน่ใจว่าแอปทำงานได้อย่างถูกต้องเมื่อใช้การเพิ่มประสิทธิภาพการประหยัดพลังงาน
การทดสอบแอปด้วยโหมด Doze
วิธีทดสอบโหมดสลีปกับแอป
- กำหนดค่าอุปกรณ์ฮาร์ดแวร์หรืออุปกรณ์เสมือนด้วยภาพระบบ Android 7.0 (API ระดับ 24)
- เชื่อมต่ออุปกรณ์กับเครื่องสำหรับพัฒนาซอฟต์แวร์และติดตั้งแอป
- เรียกใช้แอปและปล่อยให้แอปทำงาน
- จำลองอุปกรณ์ที่เข้าสู่โหมดสลีปโดยเรียกใช้คำสั่งต่อไปนี้
$ adb shell dumpsys battery unplug
$ adb shell dumpsys deviceidle step
$ adb shell dumpsys deviceidle -h
- สังเกตลักษณะการทำงานของแอปเมื่ออุปกรณ์เปิดใช้งานอีกครั้ง ตรวจสอบว่าระบบกู้คืนได้อย่างราบรื่นเมื่ออุปกรณ์ออกจากโหมดสลีป
การทดสอบแอปโดยใช้สแตนด์บายแอป
วิธีทดสอบโหมดแอปรอดำเนินการกับแอป
- กำหนดค่าอุปกรณ์ฮาร์ดแวร์หรืออุปกรณ์เสมือนด้วยอิมเมจระบบ Android 7.0 (API ระดับ 24)
- เชื่อมต่ออุปกรณ์กับเครื่องสำหรับพัฒนาซอฟต์แวร์และติดตั้งแอป
- เรียกใช้แอปและเปิดไว้
- จำลองแอปที่เข้าสู่โหมดสแตนด์บายโดยเรียกใช้คำสั่งต่อไปนี้
$ adb shell am broadcast -a android.os.action.DISCHARGING
$ adb shell am set-idle <packageName> true
- จำลองการปลุกแอปโดยใช้คำสั่งต่อไปนี้
$ adb shell am set-idle <packageName> false
- สังเกตลักษณะการทํางานของแอปเมื่อระบบปลุกแอป ตรวจสอบว่าอุปกรณ์กลับมาทำงานได้ตามปกติจากโหมดสแตนด์บาย โดยเฉพาะอย่างยิ่ง คุณควรตรวจสอบว่าการแจ้งเตือนและงานในเบื้องหลังของแอปยังคงทำงานตามที่คาดไว้หรือไม่
การสำรองข้อมูลอัตโนมัติสำหรับแอปและตัวระบุเฉพาะอุปกรณ์
หากแอปยังมีตัวระบุเฉพาะอุปกรณ์ เช่น รหัสการลงทะเบียนการรับส่งข้อความในระบบคลาวด์ของ Google ในที่จัดเก็บข้อมูลภายใน โปรดทำตามแนวทางปฏิบัติแนะนำเพื่อยกเว้นตำแหน่งพื้นที่เก็บข้อมูลจากการสำรองข้อมูลอัตโนมัติ ตามที่อธิบายไว้ในสำรองข้อมูลผู้ใช้ด้วยการสำรองข้อมูลอัตโนมัติ
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-27 UTC"],[],[],null,["# Android 6.0 Testing Guide\n\nAndroid 6.0 gives you an opportunity to ensure your apps work with the next\nversion of the platform. This release includes a number of APIs and behavior changes that can\nimpact your app, as described in the [API\nOverview](/about/versions/marshmallow/android-6.0) and [Behavior Changes](/about/versions/marshmallow/android-6.0-changes). In testing\nyour app with this release, there are some specific system changes that you should focus on to\nensure that users have a good experience.\n\n\nThis guide describes the what and how to test Android 6.0 features with your app. You should\nprioritize testing of these specific features, due to their high potential impact on your\napp's behavior:\n\n- [Permissions](#runtime-permissions)\n- [Doze and App Standby](#doze-standby)\n- [Auto Backup and Device Identifiers](#ids)\n\nTesting Permissions\n-------------------\n\n\nThe new [Permissions](/guide/topics/permissions/overview) model\nchanges the way that permissions are allocated to your app by the user. Instead of granting all\npermissions during the install procedure, your app must ask the user for individual permissions\nat runtime. For users this behavior provides more granular control over each app's activities, as\nwell as better context for understanding why the app is requesting a specific permission. Users\ncan grant or revoke the permissions granted to an app individually at any time. This feature of\nthe release is most likely to have an impact on your app's behavior and may prevent some of your\napp features from working, or they may work in a degraded state.\n\n\nThis change affects all apps running on the new platform, even those not targeting the new\nplatform version. The platform provides a limited compatibility behavior for legacy apps, but you\nshould begin planning your app's migration to the new permissions model now, with a goal of\npublishing an updated version of your app at the official platform launch.\n\n### Test tips\n\n\nUse the following test tips to help you plan and execute testing of your app with the new\npermissions behavior.\n\n- Identify your app's current permissions and the related code paths.\n- Test user flows across permission-protected services and data.\n- Test with various combinations of granted/revoked permission.\n- Use the `adb` tool to manage permissions from the command line:\n - List permissions and status by group: \n\n ```text\n adb shell pm list permissions -d -g\n ```\n - Grant or revoke one or more permissions using the following syntax: \n\n ```text\n adb shell pm [grant|revoke] \u003cpermission.name\u003e ...\n ```\n- Analyze your app for services that use permissions.\n\n### Test strategy\n\n\nThe permissions change affects the structure and design of your app, as well as\nthe user experience and flows you provide to users. You should assess your app's current\npermissions use and start planning for the new flows you want to offer. The official release of\nthe platform provides compatibility behavior, but you should plan on updating your app and not\nrely on these behaviors.\n\n\nIdentify the permissions that your app actually needs and uses, and then find the various code\npaths that use the permission-protected services. You can do this through a combination of\ntesting on the new platform and code analysis. In testing, you should focus on opting in to\nruntime permissions by changing the app's `targetSdkVersion` to API level 23.\n\n\nTest with various combinations of permissions revoked and added, to highlight the user flows that\ndepend on permissions. Where a dependency is not obvious or logical you should consider\nrefactoring or compartmentalizing that flow to eliminate the dependency or make it clear why the\npermission is needed.\n\n\nFor more information on the behavior of runtime permissions, testing, and best practices, see\n[Working with System Permissions](/training/permissions) developer.\n\nTesting Doze and App Standby\n----------------------------\n\n\nThe power saving features of Doze and App Standby limit the amount of background processing that\nyour app can perform when a device is in an idle state or while your app is not in focus. The\nrestrictions the system may impose on apps include limited or no network access,\nsuspended background tasks, suspended Notifications, ignored wake requests, and alarms. To ensure\nthat your app behaves properly with these power saving optimizations, you should test your app by\nsimulating these low power states.\n\n#### Testing your app with Doze\n\nTo test Doze with your app:\n\n1. Configure a hardware device or virtual device with an Android 7.0 (API level 24) system image.\n2. Connect the device to your development machine and install your app.\n3. Run your app and leave it active.\n4. Simulate the device going into Doze mode by running the following commands: \n\n ```bash\n $ adb shell dumpsys battery unplug\n $ adb shell dumpsys deviceidle step\n $ adb shell dumpsys deviceidle -h\n ```\n5. Observe the behavior of your app when the device is re-activated. Make sure it recovers gracefully when the device exits Doze.\n\n#### Testing apps with App Standby\n\nTo test the App Standby mode with your app:\n\n1. Configure a hardware device or virtual device with an Android 7.0 (API level 24) system image.\n2. Connect the device to your development machine and install your app.\n3. Run your app and leave it active.\n4. Simulate the app going into standby mode by running the following commands: \n\n ```bash\n $ adb shell am broadcast -a android.os.action.DISCHARGING\n $ adb shell am set-idle \u003cpackageName\u003e true\n ```\n5. Simulate waking your app using the following command: \n\n ```bash\n $ adb shell am set-idle \u003cpackageName\u003e false\n ```\n6. Observe the behavior of your app when it is woken. Make sure it recovers gracefully from standby mode. In particular, you should check if your app's Notifications and background jobs continue to function as expected.\n\nAuto Backup for Apps and Device-Specific Identifiers\n----------------------------------------------------\n\nIf your app is persisting any device-specific identifiers, such as Google\nCloud Messaging registration ID, in internal storage,\nmake sure to follow best practices to exclude the storage\nlocation from auto-backup, as described in [Back Up User\nData with Auto Backup](/guide/topics/data/autobackup)."]]
