aboutsummaryrefslogtreecommitdiff
path: root/en/devices/architecture/vintf/index.html
blob: 31c0056570113a6a041c6f4da56dbbee9139f8d8 (plain)
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
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
<html devsite>
  <head>
    <title>Vendor Interface Object</title>
    <meta name="project_path" value="/_project.yaml" />
    <meta name="book_path" value="/_book.yaml" />
  </head>
  <body>
  <!--
      Copyright 2017 The Android Open Source Project

      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions and
      limitations under the License.
  -->

<p>This document describes the design of the <em>vendor interface object</em>
(VINTF object), which aggregates relevant information about a device and makes
that information available through a <em>queryable API</em>.</p>


<h2 id=about-objects>VINTF object design</h2>
<p>A VINTF object gathers some of the information it needs directly from the
device. Other aspects, such as the manifests, are described statically in
XML.</p>

<img src="../images/treble_vintf_mm.png">
<figcaption><strong>Figure 1.</strong> Manifests, compatibility matrices, and
runtime-collectible information</figcaption>

<p>VINTF object design provides the following for device and framework
components:</p>

<table>
<tr>
<th style="width:50%">For the Device</th>
<th>For the Framework</th>
</tr>
<tr>
<td>
<ul>
<li>Defines a schema for the static component (the
<a href="/devices/architecture/vintf/objects.html#device-manifest-file">device
manifest file</a>).</li>
<li>Adds build time support for defining the device manifest file for a given
device.</li>
<li>Defines the
<a href="/devices/architecture/vintf/objects.html#queryable-api">queryable
API</a> at runtime that retrieves the device manifest file (along with the other
runtime-collectible information) and packages them into the query result.</li>
</ul>
</td>
<td>
<ul>
<li>Defines a schema for the static component (the
<a href="/devices/architecture/vintf/objects.html#framework-manifest-file">framework
manifest file</a>).</li>
<li>Defines the
<a href="/devices/architecture/vintf/objects.html#queryable-api">queryable
API</a> at runtime that retrieves the framework manifest file and packages it
into the query result.</li>
</ul>
</td>
</tr>
</table>

<p>The VINTF object must be reliable and provide the same complete information
regardless of when the object is requested (see
<a href="/devices/architecture/vintf/resources.html#caveats">Caveats</a>).</p>

<h2 id=manifests-matrices>Manifests &amp; matrices</h2>
<p>As of Android 8.0, a runtime API queries what is on the device and sends that
information to the <a href="/devices/tech/ota/index.html">Over-the-Air (OTA)</a>
update server and other interested parties (such as CTS
<code>DeviceInfo</code>). Some information is retrieved at runtime and some of
it is statically-defined.</p>

<ul>
<li>The <strong>device manifest</strong> describes the static component of what
the device can provide to the framework.</li>
<li>The <strong>framework compatibility matrix</strong> describes what the
Android framework expects from a given device. The matrix is a static entity
whose composition is determined manually during development of the next release
of the Android framework.</li>
<li>The <strong>framework manifest</strong> describes high-level services the
framework can provide to the device.</li>
<li>The <strong>device compatibility matrix</strong> describes the services the
vendor image requires of the framework. Its composition is determined manually
during the development of the device.</li>
</ul>

<p>These two pairs of manifests and matrices must be reconciled at OTA time to
ensure a device can get framework updates that are compatible with the device's
capabilities. In general, a <em>manifest</em> describes what is provided and a
<em>compatibility matrix</em> describes what is required.</p>

<p>This section includes the following details on manifests and matrices:</p>
<ul>
  <li><a href="/devices/architecture/vintf/objects.html">Manifests</a> defines
  the device manifest, framework manifest, and manifest file schema.</li>
  <li><a href="/devices/architecture/vintf/comp-matrices.html">Compatibility
  Matrices</a> defines the schema for the compatibility matrix.</li>
  <li><a href="/devices/architecture/vintf/fcm.html">FCM Lifecycle</a> details
  how HIDL HALs are deprecated and removed and how FCM files are modifed to
  reflect the status of the HAL Version.</li>
  <li><a href="/devices/architecture/vintf/dm.html">DM Development</a> describes
  how vendors can define and declare the Target FCM Version in the device
  manifest for new devices or implement new HAL versions and increment the
  Target FCM Version when upgrading the vendor image for old devices.</li>
  <li><a href="/devices/architecture/vintf/match-rules.html">Matching Rules</a>
  defines the rules for a successful match between a compatibility matrix and a
  manifest.</li>
</ul>

  </body>
</html>