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.
HIDL Framework backward compatibility verification
Stay organized with collections
Save and categorize content based on your preferences.
HIDL HALs
guarantee the Android core system (aka system.img or the framework) is
backward compatible. While Vendor Test Suite (VTS)
tests ensure that HALs work as expected (e.g. 1.1 HAL tests are run on all
1.2 implementations), framework testing is needed to ensure that when a
supported HAL (1.0, 1.1, or 1.2) is provided, the framework works properly
with that HAL.
For details on HAL interface definition language (HIDL), refer to
HIDL,
HIDL versioning, and
HIDL HAL Deprecation.
About HAL upgrades
There are two types of HAL upgrades: major and minor.
Most systems include only one HAL implementation, but multiple
implementations are supported. For example:
android.hardware.teleport@1.0 # initial interface
android.hardware.teleport@1.1 # minor version upgrade
android.hardware.teleport@1.2 # another minor version upgrade
...
android.hardware.teleport@2.0 # major version upgrade
...
The system partition typically includes a framework daemon (such as
teleportd) that manages communication with a specific group of
HAL implementations. Alternatively, systems might instead
include a system library (such as
android.hardware.configstore-utils) that implements convenient
client behavior. In the example above, teleportd must work no
matter what version of the HAL is installed on the device.
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-08-29 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-08-29 UTC."],[],[],null,["# HIDL Framework backward compatibility verification\n\n[HIDL HALs](/docs/core/architecture#hidl)\nguarantee the Android core system (aka system.img or the framework) is\nbackward compatible. While [Vendor Test Suite (VTS)](/docs/compatibility/vts)\ntests ensure that HALs work as expected (e.g. 1.1 HAL tests are run on all\n1.2 implementations), framework testing is needed to ensure that when a\nsupported HAL (1.0, 1.1, or 1.2) is provided, the framework works properly\nwith that HAL.\n\nFor details on HAL interface definition language (HIDL), refer to\n[HIDL](/docs/core/architecture/hidl), [HIDL versioning](/docs/core/architecture/hidl/versioning), and [HIDL HAL Deprecation](/docs/core/architecture/vintf/fcm#hal-version-deprecation).\n\nAbout HAL upgrades\n------------------\n\nThere are two types of HAL upgrades: *major* and *minor*.\nMost systems include only one HAL implementation, but multiple\nimplementations are supported. For example: \n\n```\nandroid.hardware.teleport@1.0 # initial interface\nandroid.hardware.teleport@1.1 # minor version upgrade\nandroid.hardware.teleport@1.2 # another minor version upgrade\n...\nandroid.hardware.teleport@2.0 # major version upgrade\n...\n```\n\nThe system partition typically includes a framework daemon (such as\n`teleportd`) that manages communication with a specific group of\nHAL implementations. Alternatively, systems might instead\ninclude a system library (such as\n`android.hardware.configstore-utils`) that implements convenient\nclient behavior. In the example above, `teleportd` must work no\nmatter what version of the HAL is installed on the device."]]
