Add a new <hal> entry without a max-level attribute. The <hal> entry can be added to the main manifest under manifest.xml, or to the manifest fragment for the server module specified in vintf_fragments.
Introducing new HALs are backwards compatible.
When a framework HAL updates its minor version, simply update the <version> or <fqname> field to the latest version. This is the same as any other HALs.
For example, when IServiceManager updates to 1.2, change its <fqname> field to @1.2::IServiceManager/default.
Because minor version updates are backwards compatible, all devices that require a lower minor version of the HAL are still compatible.
Leave max-level attribute empty.
When a framework HAL is deprecated, set max-level field of the HAL from empty to the last frozen version. For example, if IDisplayService is deprecated in Android S, set max-level to Android R (5):
<manifest version="3.0" type="framework"> <hal format="hidl" max-level="5"> <!-- Level::R --> <name>android.frameworks.displayservice</name> <transport>hwbinder</transport> <fqname>@1.0::IDisplayService/default</fqname> </hal> </manifest>
Note that the max-level of the HAL is set to Android R, meaning that the HAL is last available in Android R and disabled in Android S.
Deprecating a HAL doesn’t mean dropping support of the HAL, so no devices will break.
When setting max-level of a HAL:
optional="false" in frozen DCMs, the build system checks that adding the attribute does not break backwards compatibility; that is, max-level > last_frozen_level.optional="true", the check is disabled. Care must be taken to ensure max-level is set appropriately.When the framework drops support of a certain HAL, the corresponding HAL entry is removed from the framework manifest, and code that serves and registers the HAL must be removed simultaneously.
Devices that are lower than the max-level attribute of the HAL may start to break if they require this HAL. Hence, this must only be done when there is enough evidence that the devices are not updateable to the latest Android release.
First, check libvintf or hardware/interfaces/compatibility_matrices to determine the current level.
Execute the following, replacing the argument with the level to freeze:
lunch cf_x86_phone-userdebug # or any generic target LEVEL=5 ./freeze.sh ${LEVEL}
A new file, frozen/${LEVEL}.xml, will be created after the command is executed. Frozen system manifests are stored in compatibility matrices. Then, manually inspect the frozen compatibility matrix. Modify the optional field for certain HALs. See comments in the compatibility matrix of the previous level for details.
These compatibility matrices served as a reference for devices at that target FCM version. Devices at the given target FCM version should reference DCMs in the frozen/ dir, with some of the HALs marked as optional="true" or even omitted if unused by device-specific code.
At build time, compatibiltiy is checked between framework manifest and the respective frozen DCM. HALs in the framework manifest with max-level less than the specified level are omitted.