1 page.title=Configuring the Products 2 @jd:body 3 4 <!-- 5 Copyright 2015 The Android Open Source Project 6 7 Licensed under the Apache License, Version 2.0 (the "License"); 8 you may not use this file except in compliance with the License. 9 You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13 Unless required by applicable law or agreed to in writing, software 14 distributed under the License is distributed on an "AS IS" BASIS, 15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 See the License for the specific language governing permissions and 17 limitations under the License. 18 --> 19 <div id="qv-wrapper"> 20 <div id="qv"> 21 <h2>In this document</h2> 22 <ol id="auto-toc"> 23 </ol> 24 </div> 25 </div> 26 27 <p>Use the information in this page to create the Makefiles for your device and product.</p> 28 29 <h2 id="build-layers">Understand Build Layers</h2> 30 31 <p>The build hierarchy includes the abstraction layers that correspond to the 32 physical makeup of a device. These layers are described in the table below. 33 Each layer relates to the one above it in a one-to-many relationship. For 34 example, an architecture can have more than one board and each board can have 35 more than one product. You may define an element in a given layer as a 36 specialization of an element in the same layer, thus eliminating copying and 37 simplifying maintenance.</p> 38 39 <table> 40 <tbody><tr> 41 <th>Layer</th> 42 <th>Example</th> 43 <th>Description</th> 44 </tr> 45 <tr> 46 <td>Product</td> 47 <td>myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk</td> 48 <td><p>The product layer defines the feature specification of a shipping product such as the modules to build, 49 locales supported, and the configuration for various locales. In other words, this is the name of the 50 overall product. Product-specific variables are defined in product definition Makefiles. A product 51 can inherit from other product definitions, 52 which simplifies maintenance. A common method is to create a base product that contains features that apply 53 for all products, then creating product variants based on that base product. For example, you can have 54 two products that differ only by their radios (CDMA vs GSM) inherit from the same base product that does not define a radio. 55 </td> 56 57 </tr> 58 <tr> 59 <td>Board/Device</td> 60 <td>sardine, trout, goldfish</td> 61 <td>The device/board layer represents the physical layer of plastic on the 62 device (i.e. the industrial design of the device). For example, North American 63 devices probably include QWERTY keyboards whereas devices sold in France 64 probably include AZERTY keyboards. This layer also represents the bare 65 schematics of a product. These include the peripherals on the board and their 66 configuration. The names used are merely codes for different board/device configurations.</td> 67 </tr> 68 <tr> 69 <td>Arch</td> 70 <td>arm, x86, mips, arm64, x86_64, mips64</td> 71 <td>The architecture layer describes the processor configuration and ABI (Application Binary Interface) running on the board. </td> 72 </tr> 73 </table> 74 75 <h2 id="build-variants">Use Build Variants</h2> 76 77 <p>When building for a particular product, it's often useful to have minor 78 variations on what is ultimately the final release build. In a module 79 definition, the module can specify tags with <code>LOCAL_MODULE_TAGS</code>, 80 which can be one or more values of <code>optional</code> (default), 81 <code>debug</code>, <code>eng</code>.</p> 82 83 <p>If a module doesn't specify a tag (by <code>LOCAL_MODULE_TAGS</code>), its 84 tag defaults to <code>optional</code>. An optional module is installed only if 85 it is required by product configuration with <code>PRODUCT_PACKAGES</code>. 86 87 <p>These are the currently-defined build variants:</p> 88 89 <table border=1> 90 <tr> 91 <td> 92 <code>eng<code> 93 </td> 94 <td> 95 This is the default flavor. 96 <ul> 97 <li>Installs modules tagged with: <code>eng</code> and/or <code>debug</code>. 98 <li>Installs modules according to the product definition files, in addition to tagged modules.</li> 99 <li><code>ro.secure=0</code> 100 <li><code>ro.debuggable=1</code> 101 <li><code>ro.kernel.android.checkjni=1</code> 102 <li><code>adb</code> is enabled by default. 103 </td> 104 </tr> 105 <tr> 106 <td> 107 <code>user<code> 108 </td> 109 <td> 110 This is the flavor intended to be the final release bits. 111 <ul> 112 <li>Installs modules tagged with <code>user</code>.</li> 113 <li>Installs modules according to the product definition files, in addition to tagged modules.</li> 114 <li><code>ro.secure=1</code> </li> 115 <li><code>ro.debuggable=0</code> </li> 116 <li><code>adb</code> is disabled by default.</li> 117 </td> 118 </tr> 119 <tr> 120 <td> 121 <code>userdebug<code> 122 </td> 123 <td> 124 The same as <code>user</code>, except: 125 <ul> 126 <li>Also installs modules tagged with <code>debug</code>. 127 <li><code>ro.debuggable=1</code> 128 <li><code>adb</code> is enabled by default. 129 </td> 130 </tr> 131 </table> 132 133 <h2 id="build-a-product">Build a Product</h2> 134 135 <p> 136 There are many ways to organize the source files for your device. We'll briefly 137 go over how the Nexus 6 implementation was organized as an example, but you can 138 organize your source files and build the way you see fit. 139 </p> 140 <p> 141 Nexus 6 was implemented with a main device configuration named 142 <code>shamu</code>. From this device configuration, a product is created with a 143 product definition Makefile that declares product-specific information about 144 the device such as the name and model. You can view the 145 <code>device/moto/shamu</code> directory to see how all of this is setup. 146 </p> 147 <h3 id="makefiles">Write the Makefiles</h2> 148 <p> 149 The following steps describe how to set up product Makefiles in a way similar 150 to that of the Nexus 6 product line: 151 </p> 152 <ol> 153 <li>Create a <code>device/<company_name>/<device_name></code> directory for your 154 product. For example, <code>device/moto/shamu</code>. This directory will contain source code 155 for your device along with the Makefiles to build them. 156 </li> 157 158 <li>Create a <code>device.mk</code> Makefile that declares the files and modules needed for the 159 device. For an example, see <code>device/moto/shamu/device.mk</code>. 160 </li> 161 162 <li>Create a product definition Makefile to create a specific product based on the device. The 163 following Makefile is taken from <code>device/moto/shamu/aosp_shamu.mk</code> as an example. 164 Notice the product is inheriting from the 165 <code>device/moto/shamu/device.mk</code> and 166 <code>vendor/moto/shamu/device-vendor.mk</code> files via the Makefile while 167 also declaring the product-specific information such as name, brand, and model. 168 169 <pre> 170 # Inherit from the common Open Source product configuration 171 $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk) 172 173 PRODUCT_NAME := aosp_shamu 174 PRODUCT_DEVICE := shamu 175 PRODUCT_BRAND := Android 176 PRODUCT_MODEL := AOSP on Shamu 177 PRODUCT_MANUFACTURER := motorola 178 PRODUCT_RESTRICT_VENDOR_FILES := true 179 180 $(call inherit-product, device/moto/shamu/device.mk) 181 $(call inherit-product-if-exists, vendor/moto/shamu/device-vendor.mk) 182 183 PRODUCT_NAME := aosp_shamu 184 185 PRODUCT_PACKAGES += \ 186 Launcher3 187 </pre> 188 189 <p> 190 See <a href="#prod-def">Product Definition Variables</a> for additional product-specific 191 variables you can add to your Makefiles. 192 </p> 193 </li> 194 195 <li>Create an <code>AndroidProducts.mk</code> file that points to the product's Makefiles. In 196 this example, only the product definition Makefile is needed. The example below is from 197 <code>device/moto/shamu/AndroidProducts.mk</code>: 198 <pre> 199 # 200 # This file should set PRODUCT_MAKEFILES to a list of product makefiles 201 # to expose to the build system. LOCAL_DIR will already be set to 202 # the directory containing this file. 203 # 204 # This file may not rely on the value of any variable other than 205 # LOCAL_DIR; do not use any conditionals, and do not look up the 206 # value of any variable that isn't set in this file or in a file that 207 # it includes. 208 # 209 210 PRODUCT_MAKEFILES := \ 211 $(LOCAL_DIR)/aosp_shamu.mk 212 </pre> 213 </li> 214 215 <li>Create a <code>BoardConfig.mk</code> Makefile that contains board-specific configurations. 216 For an example, see <code>device/moto/shamu/BoardConfig.mk</code>. 217 </li> 218 219 <li>Create a <code>vendorsetup.sh</code> file to add your product (a "lunch combo") to the build 220 along with a <a href="#build-variants">build variant</a> separated by a dash. For example: 221 <pre> 222 add_lunch_combo <product_name>-userdebug 223 </pre> 224 </li> 225 226 <li>At this point, you can create more product variants based on the same device. 227 </li> 228 229 </ol> 230 <h3 id="prod-def">Set Product Definition Variables</h3> 231 <p> 232 Product-specific variables are defined in the product's Makefile. Variables maintained in a 233 product definition files include: 234 </p> 235 <table> 236 <tbody> 237 <tr> 238 <th> 239 Parameter 240 </th> 241 <th> 242 Description 243 </th> 244 <th> 245 Example 246 </th> 247 </tr> 248 <tr> 249 <td> 250 PRODUCT_AAPT_CONFIG 251 </td> 252 <td> 253 <code>aapt</code> configurations to use when creating packages 254 </td> 255 <td></td> 256 </tr> 257 <tr> 258 <td> 259 PRODUCT_BRAND 260 </td> 261 <td> 262 The brand (e.g., carrier) the software is customized for, if any 263 </td> 264 <td></td> 265 </tr> 266 <tr> 267 <td> 268 PRODUCT_CHARACTERISTICS 269 </td> 270 <td> 271 <code>aapt</code> characteristics to allow adding variant-specific resources to a package. 272 </td> 273 <td> 274 tablet,nosdcard 275 </td> 276 </tr> 277 <tr> 278 <td> 279 PRODUCT_COPY_FILES 280 </td> 281 <td> 282 List of words like <code>source_path:destination_path</code>. The file at the source path 283 should be copied to the destination path when building this product. The rules for the copy 284 steps are defined in config/Makefile 285 </td> 286 <td></td> 287 </tr> 288 <tr> 289 <td> 290 PRODUCT_DEVICE 291 </td> 292 <td> 293 Name of the industrial design. This is also the board name, and the build system uses it to locate the <code>BoardConfig.mk.</code> 294 </td> 295 <td> 296 <code>tuna</code> 297 </td> 298 </tr> 299 <tr> 300 <td> 301 PRODUCT_LOCALES 302 </td> 303 <td> 304 A space-separated list of two-letter language code, two-letter country code pairs that 305 describe several settings for the user, such as the UI language and time, date and currency 306 formatting. The first locale listed in PRODUCT_LOCALES is used as the product's default locale. 307 </td> 308 <td> 309 <code>en_GB de_DE es_ES fr_CA</code> 310 </td> 311 </tr> 312 <tr> 313 <td> 314 PRODUCT_MANUFACTURER 315 </td> 316 <td> 317 Name of the manufacturer 318 </td> 319 <td> 320 <code>acme</code> 321 </td> 322 </tr> 323 <tr> 324 <td> 325 PRODUCT_MODEL 326 </td> 327 <td> 328 End-user-visible name for the end product 329 </td> 330 <td></td> 331 </tr> 332 <tr> 333 <td> 334 PRODUCT_NAME 335 </td> 336 <td> 337 End-user-visible name for the overall product. Appears in the Settings > About screen. 338 </td> 339 <td></td> 340 </tr> 341 <tr> 342 <td> 343 PRODUCT_OTA_PUBLIC_KEYS 344 </td> 345 <td> 346 List of Over the Air (OTA) public keys for the product 347 </td> 348 <td></td> 349 </tr> 350 <tr> 351 <td> 352 PRODUCT_PACKAGES 353 </td> 354 <td> 355 Lists the APKs and modules to install. 356 </td> 357 <td> 358 <code>Calendar Contacts</code> 359 </td> 360 </tr> 361 <tr> 362 <td> 363 PRODUCT_PACKAGE_OVERLAYS 364 </td> 365 <td> 366 Indicate whether to use default resources or add any product specific overlays 367 </td> 368 <td> 369 <code>vendor/acme/overlay</code> 370 </td> 371 </tr> 372 <tr> 373 <td> 374 PRODUCT_PROPERTY_OVERRIDES 375 </td> 376 <td> 377 List of system property assignments in the format "key=value" 378 </td> 379 <td></td> 380 </tr> 381 </tbody> 382 </table> 383
