commit | b564858b10510e64b44e3afd4c8dffe66dc249fb | [log] [tgz] |
---|---|---|
author | Sundong Ahn <sundongahn@google.com> | Wed Apr 03 10:26:31 2019 +0900 |
committer | Sundong Ahn <sundongahn@google.com> | Fri Apr 05 05:33:58 2019 +0000 |
tree | d38ddfcddf3eb773fc6e848a6cfbdf8ca3e9011c | |
parent | a742042e7fde0c98220c71a5fb6ee3f56b998b60 [diff] |
Add setMultiple If the maxOccurs of sequence or choice is more than 1, the sub-element can occurs multiple. But the multiple of an element depends only on the element's maxOccurs. So If the parent element can occurs multiple, the sub-elements can also occurs mutitple. Test: m -j && make update-api && make check-api Bug: 128380795 Merged-In: I90954a3289c4db97c746422374f2e2860b6ce086 Change-Id: I90954a3289c4db97c746422374f2e2860b6ce086 (cherry picked from commit edaf152e2ea13e5e6aa64354a3c1bf0789b08094)
The ConfigFile as API is a formal Treble interface describing schemas of configuration files used across system and vendor partitions. The Java APIs in the current.txt file are not Java APIs for apps. It's a proxy for the schema of a xml file used between the system and vendor partition. The xml files are only ever parsed by apps on the system partition.
Add the schema (attribute, element or new complexType …) you want to add to the xsd file.
<xs:element name="class"> <xs:complexType> <xs:sequence> <xs:element name="student" type="xs:string"/> </xs:sequence> <xs:attribute name="name" type=”xs:string”/> </xs:complexType> </xs:element>
<xs:element name="class"> <xs:complexType> <xs:sequence> <xs:element name="student" type="xs:string"/> </xs:sequence> <xs:attribute name="name" type=”xs:string”/> <xs:attribute name="number" type="xs:int"/> </xs:complexType> </xs:element>
Then run “make {xsd_config module_name} .docs-update-current-api” or “make update-api” to update all the xsd_config modules.
In the above example, two functions are added as below.
To remove a tag, add an annotation tag with the name of “Deprecated” into the tag to be deleted. Partners are not allowed to create new vendor images using deprecated tags
<xs:element name="class"> <xs:complexType> <xs:sequence> <xs:element name="student" type="xs:string"/> </xs:sequence> <xs:attribute name="name" type=”xs:string”/> </xs:complexType> </xs:element>
<xs:element name="class"> <xs:complexType> <xs:sequence> <xs:element name="student" type="xs:string"> <annotation name=”Deprecated”/> </xs:element> </xs:sequence> <xs:attribute name="name" type=”xs:string”/> </xs:complexType> </xs:element>
After adding “Deprecated” annotation, we need to update the api or schema just like when adding a tag. In the above example, a @Deprecate annotation is added.
If there are any changes, we update last_current.txt and last_removed.txt before release by copying current.txt and removed.txt to last_current.txt and last_removed.txt.
Only the follow tags and attributes are allowed:
"xsd:schema" [
]
"xsd:element" [
"xsd:name" {
values: any valid java name
}
"xsd:type" {
values: built-in data type, simpleType or complexType
},
"xsd:ref" {
values: another element
},
"xsd:minOccurs" {
values: [ 0, maxOccurs ]
},
"xsd:maxOccurs" {
values: [ 1, unbounded ]
},
]
"xsd:attribute" [
"xsd:name" {
values: any valid java name
}
"xsd:type" {
values: built-in data type, simpleType or complexType
},
"xsd:ref" {
values: another element
},
]
"xsd:complexType" [
"xsd:name" {
values: any valid java name
}
]
"xsd:complexContent" [
]
"xsd:simpleContent" [
]
"xsd:restriction": [
"xsd:base" {
values: built-in data type
}
]
"xsd:extension": [
"xsd:base" {
values: built-in data type, simpleType or complexType
}
]
"xsd:simpleType": [
"xsd:name" {
values: any valid java name
}
]
"xsd:list": [
"xsd:itemType" {
values: built-in data type, or simpleType
}
]
"xsd:union": [
"xsd:memberTypes" {
values: built-in data type, or simpleType
}
]
"xsd:sequence": [
]
"xsd:choice": [
]
"xsd:all": [
]
"xsd:enumeration": [
"xsd:value" {
values: built-in data type
}
]