GMS Certification: Basic Testing Requirements and Compatibility Documentation for Handheld Devices on Google Android 12
i. Definition and Requirements for Handheld Devices
An Android handheld device is typically defined as an Android device designed to be used by holding it in your hand, such as an MP3 player, smartphone, or tablet.
Android devices are classified as handheld devices if they meet all of the following conditions. Handheld devices seeking GMS certification must obtain a MADA agreement.
*DeepLight Technology notes: Handheld devices must have a power source that provides mobility, such as a battery.
ii. Testing Requirements for Handheld Devices to Pass GMS Certification
1. At least one Android-compatible display that meets all requirements described in this document must be present. It is strongly recommended to provide users with the ability to change display sizes (screen density).
2. The GPU combination must support a graphics buffer that is at least as large as the highest resolution of any built-in display.
3. If the handheld device implementation supports software screen rotation, it must ensure that the logical screen available to third-party applications has a short edge of at least 2 inches and a long edge of at least 2.7 inches.
4. If the handheld device does not support software screen rotation, the logical screen available to third-party applications must have a short edge of at least 2.7 inches.
5. If the handheld device implementation declares support for High Dynamic Range (HDR) display through `Configuration.isScreenHdr()`, it must advertise support for the following extensions: `EGL_EXT_gl_colorspace_bt2020_pq`, `EGL_EXT_surface_SMPTE2086_metadata`, `EGL_EXT_surface_CTA861_3_metadata`, `VK_EXT_swapchain_colorspace`, and `VK_EXT_hdr_metadata`.
6. The device must report support for GPU profiling via the system property `graphics.gpu.profiler.support`.
7. If the handheld device implementation declares support for GPU profiling through the system property
`graphics.gpu.profiler.support`:
1) It must report protobuf traces that conform to the GPU counter and GPU rendering stage architecture defined in the Perfetto documentation.
2) It must report consistent values for GPU counters after the GPU counter trace packet proto.
3) It must report consistent values for GPU RenderStages after the rendering stage trace packet proto.
4) It must report GPU frequency tracking points in the format: `power/gpu_frequency`.
5) It must support backward compatibility modes for older Android open-source code implementations. Specifically, the device implementation must not alter the triggers or thresholds for activating compatibility modes, and must not change the behavior of compatibility modes themselves.
6) It must include support for third-party input method editor (IME) applications.
7) It must provide a home button function on all Android-compatible displays.
8) It must provide a Back function on all Android-compatible displays and a Recents function on at least one Android-compatible display.
9) It must send normal and long press events for the Back function (`KEYCODE_BACK`) to the foreground application. These events must not be used by the system and may be triggered by external hardware keyboards connected to the Android device.
10) It must support touchscreen input.
8. If the handheld device implementation includes a 3-axis accelerometer, it must be capable of reporting events at a frequency of at least 100 Hz.
9. If the handheld device implementation includes a GPS/GNSS receiver and reports functionality to applications through the `android.hardware.location.gps` feature flag:
1) It must report GNSS measurement results immediately after detection, even if the location based on GPS/GNSS has not yet been reported.
2) It must report GNSS pseudorange and pseudorange rate, under open sky conditions, when stationary or moving at an acceleration of less than 0.2 m/s², with sufficient accuracy to calculate location within 20 meters and speed within 0.2 m/s, at least 95% of the time.
10. If the handheld device implementation includes a 3-axis gyroscope:
1) It must be capable of reporting events at a frequency of at least 100 Hz.
2) It must be able to measure direction changes up to 1000 degrees per second.
11. Handheld devices that can make voice calls and indicate any value other than `PHONE_TYPE_NONE` in `getPhoneType`:
1) Should support a 6-degree-of-freedom pose sensor.
2) Should include support for Bluetooth and Bluetooth LE.
12. If the handheld device implementation includes a metered connection, it must provide data protection mode.
13. If the handheld device implementation includes a logical camera device with listed features:
1) It must have a normal field of view (FOV) by default, between 50 and 90 degrees.
2) It must have at least 4 GB of non-volatile storage available for application private data (also known as the “/data”
partition).
3) It must return "true" for `ActivityManager.isLowRamDevice()` when available memory in the kernel and user space is less than 1 GB.
14. If the handheld device implementation claims support for only 32-bit ABI:
1) If the default display uses a framebuffer resolution up to qHD (e.g., FWVGA), the available memory in the kernel and user space must be at least 416 MB.
2) If the default display uses a framebuffer resolution up to HD+ (e.g., HD, WSVGA), the available memory in the kernel and user space must be at least 592 MB.
3) If the default display uses a framebuffer resolution up to FHD (e.g., WSXGA+), the available memory in the kernel and user space must be at least 896 MB.
4) If the default display uses a framebuffer resolution up to QHD (e.g., QWXGA), the available memory in the kernel and user space must be at least 1344 MB.
15. If the handheld device implementation claims support for both 32-bit and 64-bit ABI:
1) If the default display uses a framebuffer resolution up to qHD (e.g., FWVGA), the available memory in the kernel and user space must be at least 816 MB.
2) If the default display uses a framebuffer resolution up to HD+ (e.g., HD, WSVGA), the available memory in the kernel and user space must be at least 944 MB.
3) If the default display uses a framebuffer resolution up to FHD (e.g., WSXGA+), the available memory in the kernel and user space must be at least 1280 MB.
4) If the default display uses a framebuffer resolution up to QHD (e.g., QWXGA), the available memory in the kernel and user space must be at least 1824 MB.
Note that the “available memory in the kernel and user space” refers to the memory space provided, excluding any memory already dedicated to hardware components (such as radio, video, etc.), which is not under the kernel's control.
16. If the handheld device implementation includes kernel and user space memory of 1 GB or less:
1) It must declare the feature flag `android.hardware.ram.low`.
2) It must have at least 1.1 GB of non-volatile storage for application private data (also known as the “/data” partition).
17. If the handheld device implementation includes more than 1 GB of memory available for kernel and user space:
1) It must have at least 4 GB of non-volatile storage available for application private data (also known as the “/data” partition).
2) It should declare the feature flag `android.hardware.ram.normal`.
18. If the handheld device implementation includes kernel and user space memory of 2 GB or more but less than 4 GB, it is strongly recommended to support only a 32-bit user space (application and system code).
19. If the handheld device implementation includes less than 2 GB of memory available for kernel and user space:
1) It must support only the 32-bit ABI.
2) It must not provide less than 1 GiB of application shared storage.
3) It should include USB ports that support peripheral mode.
20. If the handheld device implementation includes USB ports that support peripheral mode, it must implement the Android Open Accessory (AOA) API.
21. If the handheld device implementation includes USB ports that support host mode, it must implement the USB Audio class as described in the Android SDK documentation.
Handheld devices:
1) Must include a microphone.
2) Must have audio output and declare `android.hardware.audio.output`.
Deeplight Technology has completed GMS certification for many domestic and international clients, including smartphones, tablets, large displays, POS machines, and other products. We offer one-stop services including MADA agreement authorization, EDLA agreement authorization, pre-testing, debugging, and official testing. Contact us for consultation!
-
A Series of Testing Tools Used for Google TV Device Certification
Google TV devices, such as TVs, TV boxes, and projectors, require TADA certification, which involves passing tests like CTS, GTS, VTS, and TVTS to obtain certification.2024-09-11
-
Google/Android TV CDD Details Requirements
A Google/Android TV device refers to an Android-based television device, providing an entertainment interface suitable for users viewing television programs from approximately 10 feet away ("interface for large-screen entertainment experiences" or "interface for viewing from 10 feet away"). It allows users to watch digital media, movies, TV broadcasts, play games, and/or use applications.2024-09-11
-
Google Android TV/Set-Top Box Certification for Android ATV
Google Android ATV certification refers to the whole machine certification, submitted by ODM/OEM to Google to do the certification test, SOC manufacturers do not need to do the chip-level certification.Android TV was introduced at Google I/O on 26 June 2014, specially designed for TV and set-top box products designed for the application service package. Based on the Android AOSP version, plus the GTVS package can be compiled out of the Android TV Firmware.2024-09-11
-
The Project Process and Testing Contents for Google's Android TV Testing and Certification
Google Android TV certification is a program by Google that ensures a device meets a set of requirements and standards before being allowed to use the Android TV operating system. This certification ensures that the device is compatible with the Android TV platform and the user experience meets the standards set by Google. Device manufacturers must meet certain hardware and software requirements, as well as pass tests and compliance checks to receive the certification.2024-09-11
-
Understanding Google's TADA Agreement and the Android TV Certification Process
TADA is one of the many Agreement in Google GMS certification, Google for different products, launched different Agreements, in addition to TADA Agreement, there are MADA Agreement, EDLA Agreement, GAS Agreement, different Agreements for different products.2024-09-11