+86-755-89202795

Google EDLA/GMS certification

Google EDLA certification, also known as Enterprise Device Licensing Agreement, refers to the Google Enterprise Device License Agreement, which allows devices to come without batteries and have screen sizes up to 70 or even 100 inches. Common devices that require EDLA applications include large screen advertising machines, POS machines, devices without batteries, or devices with screens exceeding 18 inches.

Enterprise Compliance

Google Android 12 Version GMS Certification Compatibility Document Some Basic Requirements for Handheld Device Testing

1. Definition and requirements of handheld devices.
 
 

An Android handheld device is an Android device that is usually implemented by holding it in your hand, such as an mp3 player, mobile phone, or tablet.

If Android device implementations meet all of the following conditions, they are classified as handheld devices, and the application of GMS certification for handheld devices requires the MADA agreement.
 
Deeplight Tech Tip: Handheld devices need to have a power source that provides mobility, such as a battery.
 
 2. Handheld devices have passed GMS test requirements
 
2.1.There must be at least one Android-compatible display that meets all the requirements described in this document.It is strongly recommended to provide users with the ability to change the display size (screen density).

2.2.The GPU combination must support a graphics buffer at least as large as the highest resolution of any built-in display.
 
2.3.If handheld device implementations support software screen rotation, they must make the logical screen available to third-party applications at least 2 inches on the short side and 2.7 inches on the long side.
 
2.4.If handheld devices do not support software screen rotation, they must make the short side of the logical screen available to third-party applications at least 2.7 inches.
 
2.5.If handheld device implementations declare support for high dynamic range displays via Configuration.isScreenHdr(), they: 

MUST advertise support for the 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 extensions.

2.6.Whether the device supports GPU profiling must be reported via the system property graphics.gpu.profiler.support.
 
2.7.If handheld device implementations declare support via the system property graphics.gpu.profiler.support, they:
 
1) A protobuf trace conforming to the GPU counter and GPU render stage architecture defined in the Perfetto documentation must be reported as output.
 
2) A consistent value of the device‘s GPU counter must be reported after the GPU counter trace packet proto.
 
3) A consistent value for the device‘s GPU RenderStages must be reported after the packet  proto is traced in the render stage.
 
4) The GPU frequency trace point specified by the following format must be reported: power/gpu_frequency .
 
5) Must include support for legacy application compatibility mode implemented by the upstream Android open source code. That is, device implementations MUST NOT change the triggers or thresholds that activate Compatibility Mode, and MUST NOT change the behavior of Compatibility Mode itself.
 
6) Must include support for third-party Input Method Editor (IME) applications.
 
7) Home screen functionality must be available on all Android-compatible displays that offer a home screen.
 
8) The Back feature must be available on all Android-compatible displays and the Recents feature on at least one Android-compatible display.
 
9)Normal and long press events that return to the function ( KEYCODE_BACK ) must be sent to the foreground application. These events must not be used by the system and can be triggered externally by the Android device (for example, an external hardware keyboard connected to the Android device).
 
10)Touchscreen input must be supported.
 
2.8.If handheld device implementations include 3-axis accelerometers, they:Events must be able to be reported at a frequency of at least 100 Hz.
 
2.9.If handheld device implementations include GPS/GNSS receivers and report capabilities to applications via the android.hardware.location.gps capability flag, they:

1) GNSS measurements must be reported as soon as they are discovered, even if the position calculated from GPS/GNSS has not been reported.

2) GNSS pseudoranges and pseudorange rates must be reported, in open sky conditions after the position is determined. When stationary or moving with an acceleration of less than 0.2 m/s squared, it is sufficient to calculate that the position is within 20 meters and the velocity is within 0.2 m/s, at least 95% of the time.
 
2.10.If handheld device implementations include 3-axis gyroscopes, they:

1) Must be able to report events at a frequency of at least 100 Hz.

2) Must be able to measure directional changes of up to 1000 degrees per second.

2.11.Handheld implementations that can make voice calls and indicate any value in getPhoneType except PHONE_TYPE_NONE:
Handheld device implementation:

1) It is recommended to support pose sensors with 6 degrees of freedom.

2) Should include support for Bluetooth and Bluetooth LE.
 
2.12.If handheld device implementations include metered connections, they:Data protection mode must be provided.
 
2.13.If handheld device implementations include logical camera devices that use the listed functions, they:

1) Must have a normal field of view (FOV) by default and must be between 50 and 90 degrees.

2) There must be at least 4 GB of non-volatile storage available for application private data (aka the "/data" partition).

3) Must return "true" for ActivityManager.isLowRamDevice() when the available memory in kernel and user space is less than 1GB.
 
2.14.If the handheld implementation declares that only the 32-bit ABI is supported:

1) If the default display uses framebuffer resolutions up to qHD (e.g. FWVGA), the memory available to kernel and user space must be at least 416MB.

2) If the default display uses framebuffer resolutions up to HD+ (e.g. HD, WSVGA), the memory available to kernel and user space must be at least 592MB.

3) If the default display uses framebuffer resolutions up to FHD (e.g. WSXGA+), the memory available to the kernel and user space must be at least 896MB.

4) If the default display uses framebuffer resolutions up to QHD (e.g. QWXGA), the memory available to kernel and user space must be at least 1344MB.
 
2.15.If the handheld implementation declares support for the 32-bit and 64-bit ABIs:

1) If the default display uses framebuffer resolutions up to qHD (e.g. FWVGA), the memory available to kernel and user space must be at least 816MB.

2) If the default display uses framebuffer resolutions up to HD+ (e.g. HD, WSVGA), the memory available to kernel and user space must be at least 944MB.

3) If the default display uses framebuffer resolutions up to FHD (e.g. WSXGA+), the memory available to kernel and user space must be at least 1280MB.

4) If the default display uses framebuffer resolutions up to QHD (e.g. QWXGA), the memory available to kernel and user space must be at least 1824MB.
 
Note that "memory available to kernel and user space" above refers to memory space provided in addition to any memory already dedicated to hardware components (such as radio, video, etc.) that is not under the control of the kernel over the device implementation.
 
2.16.If handheld device implementations include less than or equal to 1GB of memory available in kernel and user space, they:

1) The feature flag android.hardware.ram.low must be declared.

2) There must be at least 1.1 GB of non-volatile storage for storing application private data (aka the "/data" partition).

2.17.If handheld device implementations include more than 1GB of memory available for kernel and user space, they:

1) There must be at least 4GB of non-volatile storage available for application private data (aka the "/data" partition).

2) The feature flag android.hardware.ram.normal should be declared.
 
2.18.If handheld device implementations include greater than or equal to 2GB and less than 4GB of available memory for kernel and user space, they: STRONGLY RECOMMEND to support only 32-bit user space (application and system code)
 
2.19.If handheld device implementations include less than 2GB of memory available for kernel and user space, they:

1) MUST support only the 32-bit ABI.

2) Application shared storage must not be provided less than 1 GiB.

3) Should include a USB port that supports peripheral mode.
 
2.20.If handheld device implementations include USB ports that support peripheral mode, they:Must implement the Android Open Accessory (AOA) API.
 
2.21.If handheld device implementations include USB ports that support host mode, they:

The USB Audio class must be implemented as described in the Android SDK documentation.
Handheld devices:

1)  A microphone must be included.

2)Must have audio output and declare android.hardware.audio.output.
 
Deeplight has completed GMS test certification for many customers around the world, including GMS certification of mobile phones, tablets, large display screens, POS machines and other products. We can provide customers with one-stop services including pre-testing, debug, and formal testing! 

For any GMS testing, certification, or quotation requirements, please feel free to contact Mr. Yu at any time, yu@dlcer.com, WhatsApp&Phone:+86-13266518903, we welcome your contact.