Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Stay organized with collections
Save and categorize content based on your preferences.
Review the following information to test graphics implementations.
For benchmarking, use the following flow by phase:
Specification. When initially specifying the device (such as when
using immature drivers), use predefined (fixed) clocks and workloads to
measure frames per second (fps) rendered. This gives a clear view of hardware
capabilities.
Development. As drivers mature, use a fixed set of user actions
to measure the number of visible stutters (janks) in animations.
Production. When a device is ready for comparison against
competitors, increase the workload until stutters increase. Determine if the
current clock settings can keep up with the load. This can help you identify
where to slow the clocks and reduce power use.
For help deriving device capabilities during the specification phase, use the
Flatland tool at platform/frameworks/native/cmds/flatland/.
Flatland relies on fixed clocks and shows the throughput achievable with
composition-based workloads. It uses gralloc buffers to simulate multiple window
scenarios, filling in the window with GL then measuring the compositing.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-12 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-12 UTC."],[],[],null,["# Implementation testing\n\nReview the following information to test graphics implementations.\n\nFor benchmarking, use the following flow by phase:\n\n- *Specification.* When initially specifying the device (such as when using immature drivers), use predefined (fixed) clocks and workloads to measure frames per second (fps) rendered. This gives a clear view of hardware capabilities.\n- *Development.* As drivers mature, use a fixed set of user actions to measure the number of visible stutters (janks) in animations.\n- *Production.* When a device is ready for comparison against competitors, increase the workload until stutters increase. Determine if the current clock settings can keep up with the load. This can help you identify where to slow the clocks and reduce power use.\n\nFor help deriving device capabilities during the specification phase, use the\nFlatland tool at `platform/frameworks/native/cmds/flatland/`.\nFlatland relies on fixed clocks and shows the throughput achievable with\ncomposition-based workloads. It uses gralloc buffers to simulate multiple window\nscenarios, filling in the window with GL then measuring the compositing.\n| **Note:** Flatland uses the synchronization framework to measure time, so your implementation must support the synchronization framework."]]
