<concept xml:lang="en" id="GUID-037DFEEE-757A-5C0B-AAA7-62E3E39FAF30"><title>Migrating from Feature Registry to Feature Manager</title><shortdesc>Provides detailed instructions for migrating Feature registry to Feature Manager runtime and buildtime. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><ul><li id="GUID-E0D11AEA-EFA1-5D4D-9BF2-6B067DBCC5D3"><p><xref href="GUID-D5FE0A98-4529-522A-825C-2444E78B9325.dita#GUID-D5FE0A98-4529-522A-825C-2444E78B9325/GUID-3F4DFEAF-1EFA-5E73-A582-7C5308361F9E">Migrating to Feature Manager runtime APIs</xref>  </p> </li> <li id="GUID-68E62080-C93B-5653-81C1-B7D73B136954"><p><xref href="GUID-4B2E38E1-323C-5523-BA20-B01053D4302B.dita">Migrating to Feature Manager buildtime tooling</xref>  </p> </li> </ul> <p id="GUID-D5FE0A98-4529-522A-825C-2444E78B9325">   </p> <section id="GUID-3F4DFEAF-1EFA-5E73-A582-7C5308361F9E-GENID-1-12-1-27-1-1-4-1-1-4-1-3-3"><title>Migrating to Feature Manager runtime APIs</title> <p>FeatureRegistry queries the presence of a feature with the functions QuerySupport() and QuerySupportS() which are now deprecated. The publishPartner version of Feature Manager implements the corresponding functionality with a choice of function calls, either static or dynamic. The SDK version only provides the static function calls. </p> <table id="GUID-93462398-D94F-5D22-8315-9FC7DB736274"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><thead><row><entry>Old</entry> <entry>New</entry> </row> </thead> <tbody><row><entry><p>TInt RFeatureRegistry:: QuerySupport(TUid aFeatureUid) </p> </entry> <entry><p>TInt RFeatureControl:: FeatureSupported( TUid aFeature ) </p> </entry> </row> <row><entry><p>TInt RFeatureRegistry:: QuerySupport(TUid aFeatureUid, TUint32&amp; aInfo); </p> </entry> <entry><p>TInt RFeatureControl::FeatureSupported( TFeatureEntry&amp; aFeature ) </p> </entry> </row> <row><entry><p>TInt static RFeatureRegistry:: QuerySupportS(TUid aFeatureUid); </p> </entry> <entry><p>TBool static CFeatureDiscovery ::IsFeatureSupportedL( TUid aFeature ) </p> </entry> </row> <row><entry><p>TInt static RFeatureRegistry:: QuerySupportS(TUid aFeatureUid); </p> </entry> <entry><p>Dynamic calls to the Open(), FeatureSupported() and Close() functions of an RFeatureControl object. </p> </entry> </row> <row><entry><p>TInt static RFeatureRegistry:: QuerySupportS(TUid aFeatureUid, TUint32&amp; aInfo); </p> </entry> <entry><p>TBool static CFeatureDiscovery ::IsFeatureSupportedL( TUid aFeature ) </p> </entry> </row> <row><entry><p>TInt static RFeatureRegistry:: QuerySupportS(TUid aFeatureUid, TUint32&amp; aInfo); </p> </entry> <entry><p>Dynamic calls to the Open(), FeatureSupported() and Close() functions of an RFeatureControl object. </p> </entry> </row> </tbody> </tgroup> </table> </section> <section id="GUID-3F4DFEAF-1EFA-5E73-A582-7C5308361F9E-GENID-1-12-1-27-1-1-4-1-1-4-1-3-4"><title>Migrating to Feature Manager buildtime tooling</title> <p>The transition from Feature Registry to Feature Manager also involves changes to the process of building ROM. Features can be included in ROM as a partial build with the purpose of upgrading features, or as the corresponding section of a full build: the changes to the procedure are the same either way. </p> <p>Two tools are used to automate the process: a new version of the old tool <codeph>buildrom</codeph> and a new tool <codeph>features</codeph>. </p> <p>The procedure for building ROM uses a feature database in the form of an an .xml file to specify the features to be included and an .iby file to specify those to be excluded. The structure of these files has been modified slightly. </p> <p>The old feature database, called featureUIDs.xml is replaced by a new version called featuredatabase.xml with a new XML structure. The old XML tags correspond to the new ones like this. </p> <table id="GUID-6070A53F-F510-58C5-BA9C-75670812FE4D"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><thead><row><entry>Feature Registry</entry> <entry>Feature Manager</entry> </row> </thead> <tbody><row><entry><p>&lt;featureuids&gt; </p> </entry> <entry><p>&lt;featuredatabase&gt; </p> </entry> </row> <row><entry><p>&lt;features&gt; </p> </entry> <entry><p>&lt;featureset&gt; </p> </entry> </row> <row><entry><p>&lt;features&gt;:: uid </p> </entry> <entry><p>&lt;feature&gt;::uid </p> </entry> </row> <row><entry><p>&lt;features&gt;::name </p> </entry> <entry><p>&lt;feature&gt;::name </p> </entry> </row> <row><entry><p>None </p> </entry> <entry><p>&lt;feature&gt;:: statusflags </p> </entry> </row> <row><entry><p>&lt;default&gt; </p> </entry> <entry><p>&lt;defaultfeaturerange&gt; </p> </entry> </row> <row><entry><p>&lt;default&gt;:: min </p> </entry> <entry><p>&lt;defaultfeaturerange&gt;:: loweruid </p> </entry> </row> <row><entry><p>&lt;default&gt;:: max </p> </entry> <entry><p>&lt;defaultfeaturerange&gt;:: higheruid </p> </entry> </row> <row><entry><p>&lt;default&gt;:: support </p> </entry> <entry><p>&lt;defaultfeaturerange&gt;:: support </p> </entry> </row> </tbody> </tgroup> </table> <p>The values of the attributes are the same in both versions of the schema. The new attribute statusflags of &lt;feature&gt; takes the mandatory value of 0x00000001. </p> <p>You can upgrade your XML feature database in three ways. </p> <ul><li id="GUID-EF0C9947-688D-5EC1-B04A-76F0C5DCB285"><p>by upgrading the file manually in accordance with the equivalences given, </p> </li> <li id="GUID-A237CB02-642C-5D85-8E79-51E469424A26"><p>by calling the tool features to perform the conversion automatically, or </p> </li> <li id="GUID-FC07D4B8-BF7C-52A0-A029-99B62EAAED56"><p>by leaving the file as it is and calling the tool buildrom with the flag -fm. </p> </li> </ul> <p>You call the tool features like this: </p> <codeblock id="GUID-5472CE98-470D-5752-9FCF-DB18956E701C" xml:space="preserve">features -c &lt;destination&gt; featureUIDs.xml</codeblock> <p>where -c is a flag forcing the conversion. The output is a file <filepath>featureUIDs_converted.xml</filepath> in the folder specified at &lt;destination&gt;. </p> <p>Whether or not you force the conversion, a call to features will generate the file <filepath>feature.iby</filepath> and the header file <filepath>featureUIDs.h</filepath>. </p> <p>The .iby file, called <filepath>feature.iby</filepath>, has a new extended syntax. There are now two new flags which override the default values for the status flags and user-defined data: </p> <ul><li id="GUID-B386B0A1-3CBA-55EF-91FA-4FFC106F0535"><p>SF followed by a value for the status flags of the feature, and </p> </li> <li id="GUID-836C9FD2-C92A-5192-A6EA-A2B19B724435"><p>UD followed by a value for the user-defined data for the feature. </p> </li> </ul> <p>For example: </p> <codeblock id="GUID-D584D3C2-30BD-5948-9F8F-D11023CF59B5" xml:space="preserve">EXCLUDE_FEATURE Fax SF 0x00000008