1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
# Updating the latest framework manifest
## Adding new HALs / Major version update
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.
## Minor version update
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.
## Deprecating HAL
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):
```xml
<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:
- If `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`.
- If `optional="true"`, the check is disabled. Care must be taken to ensure
`max-level` is set appropriately.
## Removing HAL
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.
# Freezing framework HAL manifest
First, check `libvintf` or `hardware/interfaces/compatibility_matrices` to
determine the current level.
Execute the following, replacing the argument with the level to freeze:
```shell script
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.
|
