| <html devsite><head> |
| <title>Como adicionar um novo dispositivo</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>Use as informações apresentadas nesta página para criar os makefiles para seu dispositivo e produto. Observe que, diferente das outras páginas desta seção, o conteúdo aqui é aplicável somente ao criar um tipo de dispositivo totalmente novo e destina-se apenas às equipes de produto e criação da empresa.</p> |
| |
| <h2 id="build-layers">Compreender as camadas de criação</h2> |
| |
| <p>A hierarquia de criação inclui as camadas de abstração que correspondem à composição física de um dispositivo. Essas camadas são descritas na tabela abaixo. |
| Cada camada se relaciona com aquela acima em um relacionamento um para muitos. Por exemplo, uma arquitetura pode ter mais de uma placa e cada placa pode ter mais de um produto. Você pode definir um elemento em uma determinada camada como uma especialização de um elemento na mesma camada eliminando, assim, a cópia e simplificando a manutenção.</p> |
| |
| <table> |
| <tbody><tr> |
| <th>Camada</th> |
| <th>Exemplo</th> |
| <th>Descrição</th> |
| </tr> |
| <tr> |
| <td>Produto</td> |
| <td>myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk</td> |
| <td>A camada de produto define a especificação de recurso de um produto de venda, como os módulos a serem criados, as localidades aceitas e a configuração de várias localidades. Em outras palavras, esse é o nome do produto geral. Variáveis específicas de produto são definidas nos makefiles de definição do produto. Um produto pode ter heranças de outras definições de produtos, o que simplifica a manutenção. Um método comum é criar um produto base contendo recursos aplicáveis a todos os produtos e, em seguida, criar variantes de produto com base nele. Por exemplo, você pode ter dois produtos que diferem apenas nos rádios (CDMA versus GSM) herdados do mesmo produto base que não define um rádio. |
| </td> |
| |
| </tr> |
| <tr> |
| <td>Placa/Dispositivo</td> |
| <td>sardine, trout, goldfish</td> |
| <td>A camada de dispositivo/placa representa a camada física de plástico no dispositivo (ou seja, o design industrial do dispositivo). Por exemplo, os dispositivos norte-americanos provavelmente incluem teclados QWERTY, enquanto os dispositivos vendidos na França provavelmente incluem teclados AZERTY. Essa camada também representa o esquema cru de um produto. Isso inclui os periféricos na placa e sua configuração. Os nomes usados são meramente códigos para diferentes configurações de placa/dispositivo.</td> |
| </tr> |
| <tr> |
| <td>Arquitetura</td> |
| <td>arm, x86, mips, arm64, x86_64, mips64</td> |
| <td>A camada de arquitetura descreve a configuração do processador e a interface binária de aplicativo (ABI, na sigla em inglês) em execução na placa. </td> |
| </tr> |
| </tbody></table> |
| |
| <h2 id="build-variants">Usar variantes de criação</h2> |
| |
| <p>Ao criar um produto específico, geralmente é útil ter pequenas variações sobre aquela que será a versão final. Em uma definição de módulo, o módulo pode especificar tags com <code>LOCAL_MODULE_TAGS</code>, que podem ser um ou mais valores entre <code>optional</code> (padrão), <code>debug</code> e <code>eng</code>.</p> |
| |
| <p>Se um módulo não especificar uma tag (por <code>LOCAL_MODULE_TAGS</code>), a tag dele será <code>optional</code> por padrão. Um módulo opcional é instalado somente se for exigido pela configuração do produto com <code>PRODUCT_PACKAGES</code>. |
| |
| </p><p>Estas são as variantes de criação definidas atualmente:</p> |
| |
| <table border="1"> |
| <tbody><tr> |
| <td> |
| <code>eng</code> |
| </td> |
| <td> |
| Este é o estilo padrão. |
| <ul> |
| <li>Instala os módulos marcados com: <code>eng</code> e/ou <code>debug</code>.</li> |
| <li>Instala módulos de acordo com os arquivos de definição do produto, além dos módulos marcados.</li> |
| <li><code>ro.secure=0</code></li> |
| <li><code>ro.debuggable=1</code></li> |
| <li><code>ro.kernel.android.checkjni=1</code></li> |
| <li><code>adb</code> é ativado por padrão.</li> |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| <code>user</code> |
| </td> |
| <td> |
| Este é o estilo escolhido para ser a versão final. |
| <ul> |
| <li>Instala os módulos marcados com o <code>user</code>.</li> |
| <li>Instala módulos de acordo com os arquivos de definição do produto, além dos módulos marcados.</li> |
| <li><code>ro.secure=1</code> </li> |
| <li><code>ro.debuggable=0</code> </li> |
| <li><code>adb</code> é desativado por padrão.</li> |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| <code>userdebug</code> |
| </td> |
| <td> |
| O mesmo que <code>user</code>, exceto o seguinte: |
| <ul> |
| <li>Também instala módulos marcados com <code>debug</code>.</li> |
| <li><code>ro.debuggable=1</code></li> |
| <li><code>adb</code> é ativado por padrão.</li> |
| </ul> |
| </td> |
| </tr> |
| </tbody></table> |
| |
| <h3 id="userdebug-guidelines">Diretrizes de userdebug</h3> |
| |
| <p>A execução de versões do userdebug nos testes ajuda os desenvolvedores de dispositivos a entenderem o desempenho e a potência das versões em desenvolvimento. Para manter a consistência entre as versões de usuário e de userdebug e para receber métricas confiáveis nas versões usadas para depuração, os desenvolvedores de dispositivos precisam seguir estas diretrizes:</p> |
| |
| <ul> |
| <li>O userdebug deve ser definido como uma versão de usuário com acesso raiz ativado, exceto: |
| <ul> |
| <li>apps somente para o userdebug que são executados apenas sob demanda pelo usuário;</li> |
| <li>operações que são executadas apenas durante a manutenção ociosa (no carregador / totalmente carregado), como o uso de <code>dex2oatd</code> versus <code>dex2oat</code> para compilações em segundo plano.</li> |
| </ul> |
| </li> |
| <li>Não deve haver recursos que dependam do tipo de versão para serem habilitados por padrão ou não. Não é recomendável que os desenvolvedores usem qualquer forma de log que afete a vida útil da bateria, como o log de depuração ou o despejo de heap.</li> |
| <li>Quaisquer recursos de depuração habilitados por padrão no userdebug precisam ser claramente definidos e compartilhados com todos os desenvolvedores que trabalham no projeto. Ative esses recursos de depuração apenas temporariamente até que o problema seja resolvido.</li> |
| </ul> |
| |
| <h2 id="use-resource-overlays">Personalizar a criação com sobreposições de recursos</h2> |
| |
| <p>O sistema de criação do Android usa sobreposições de recursos para personalizar um produto no momento da criação. As sobreposições de recursos especificam arquivos de recursos aplicados sobre os padrões. Para usar sobreposições de recursos, modifique o arquivo de criação do projeto para definir o <code>PRODUCT_PACKAGE_OVERLAYS</code> como um caminho relativo para seu diretório de nível superior. Esse caminho se torna uma raiz paralela pesquisada junto com a raiz atual quando o sistema de criação procura por recursos.</p> |
| |
| <p>As configurações mais comumente personalizadas estão no arquivo <a href="https://android.googlesource.com/platform/frameworks/base/+/master/core/res/res/values/config.xml">frameworks/base/core/res/res/config.xml</a>.</p> |
| |
| <p> Para configurar uma sobreposição de recurso nesse arquivo, adicione o diretório de sobreposição ao arquivo de criação do projeto da seguinte maneira:</p> |
| |
| <pre class="devsite-click-to-copy"> |
| PRODUCT_PACKAGE_OVERLAYS := device/<var>DEVICE_IMPLEMENTER</var>/<var>DEVICE_NAME</var>/overlay |
| </pre> |
| |
| <p>ou</p> |
| |
| <pre class="devsite-click-to-copy"> |
| PRODUCT_PACKAGE_OVERLAYS := vendor/<var>VENDOR_NAME</var>/overlay |
| </pre> |
| |
| <p> Em seguida, adicione um arquivo de sobreposição ao diretório, por exemplo:</p> |
| |
| <pre class="devsite-click-to-copy"> |
| vendor/foobar/overlay/frameworks/base/core/res/res/config.xml |
| </pre> |
| |
| <p> Todas as strings ou matrizes de strings encontradas no arquivo <code>config.xml</code> de sobreposição substituem aquelas encontradas no arquivo original.</p> |
| |
| <h2 id="build-a-product">Criar um produto</h2> |
| |
| <p> |
| Há muitas maneiras de organizar os arquivos de origem para seu dispositivo. Como exemplo, examinaremos brevemente como a implementação do Nexus 6 foi organizada, mas você pode organizar seus arquivos de origem e versão da maneira que preferir. |
| </p> |
| <p> |
| O Nexus 6 foi implementado com um configurador de dispositivo principal denominado <code>shamu</code>. Com base nessa configuração de dispositivo, um produto é criado com um makefile de definição de produto que declara informações específicas do produto sobre o dispositivo, como o nome e o modelo. Consulte o diretório <code>device/moto/shamu</code> para ver como tudo isso é configurado. |
| </p> |
| <h3 id="makefiles">Escrever os makefiles</h3> |
| <p> |
| As etapas a seguir descrevem como configurar makefiles de produtos de maneira semelhante à linha de produtos Nexus 6: |
| </p> |
| <ol> |
| <li>Crie um diretório <code>device/<company_name>/<device_name></code> para seu produto. Por exemplo, <code>device/moto/shamu</code>. Esse diretório conterá o código-fonte do seu dispositivo e os makefiles para criá-los. |
| </li> |
| |
| <li>Crie um makefile <code>device.mk</code> que declara os arquivos e módulos necessários para o dispositivo. Para ver um exemplo, consulte <code>device/moto/shamu/device.mk</code>. |
| </li> |
| |
| <li>Crie um makefile de definição de produto para criar um produto específico com base no dispositivo. O makefile a seguir foi retirado de <code>device/moto/shamu/aosp_shamu.mk</code> como exemplo. |
| Observe que o produto herda dos arquivos <code>device/moto/shamu/device.mk</code> e <code>vendor/moto/shamu/device-vendor.mk</code> por meio do makefile, além de declarar as informações específicas do produto, como nome, marca e modelo. |
| |
| <pre class="devsite-click-to-copy"> |
| # Inherit from the common Open Source product configuration |
| $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk) |
| |
| PRODUCT_NAME := aosp_shamu |
| PRODUCT_DEVICE := shamu |
| PRODUCT_BRAND := Android |
| PRODUCT_MODEL := AOSP on Shamu |
| PRODUCT_MANUFACTURER := motorola |
| PRODUCT_RESTRICT_VENDOR_FILES := true |
| |
| $(call inherit-product, device/moto/shamu/device.mk) |
| $(call inherit-product-if-exists, vendor/moto/shamu/device-vendor.mk) |
| |
| PRODUCT_NAME := aosp_shamu |
| |
| PRODUCT_PACKAGES += \ |
| Launcher3 |
| </pre> |
| |
| <p> |
| Consulte <a href="#prod-def">Variáveis de definição do produto</a> para ver outras variáveis específicas do produto que você pode incluir nos seus arquivos. |
| </p> |
| </li> |
| |
| <li>Crie um arquivo <code>AndroidProducts.mk</code> que aponte para os makefiles do produto. Neste exemplo, apenas o makefile de definição do produto é necessário. O exemplo abaixo é do <code>device/moto/shamu/AndroidProducts.mk</code>: |
| <pre class="devsite-click-to-copy"> |
| # |
| # This file should set PRODUCT_MAKEFILES to a list of product makefiles |
| # to expose to the build system. LOCAL_DIR will already be set to |
| # the directory containing this file. |
| # |
| # This file may not rely on the value of any variable other than |
| # LOCAL_DIR; do not use any conditionals, and do not look up the |
| # value of any variable that isn't set in this file or in a file that |
| # it includes. |
| # |
| |
| PRODUCT_MAKEFILES := \ |
| $(LOCAL_DIR)/aosp_shamu.mk |
| </pre> |
| </li> |
| |
| <li>Crie um makefile <code>BoardConfig.mk</code> contendo as configurações específicas da placa. |
| Para ver um exemplo, consulte <code>device/moto/shamu/BoardConfig.mk</code>. |
| </li> |
| |
| <li>Crie um arquivo <code>vendorsetup.sh</code> para adicionar seu produto (um "combo de almoço") à versão com uma <a href="#build-variants">variante de criação</a> separada por um traço. Exemplo: |
| <pre class="devsite-click-to-copy"> |
| add_lunch_combo <var><PRODUCT_NAME></var>-userdebug |
| </pre> |
| </li> |
| |
| <li>Nesse ponto, você pode criar mais variantes de produtos com base no mesmo dispositivo. |
| </li> |
| |
| </ol> |
| <h3 id="prod-def">Definir variáveis de definição de produto</h3> |
| <p> |
| Variáveis específicas de produto são definidas no makefile do produto. As variáveis mantidas em um arquivo de definição de produto são: |
| </p> |
| <table> |
| <tbody> |
| <tr> |
| <th> |
| Parâmetro |
| </th> |
| <th> |
| Descrição |
| </th> |
| <th> |
| Exemplo |
| </th> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_AAPT_CONFIG |
| </td> |
| <td> |
| Configurações de <code>aapt</code> a serem usadas ao criar pacotes. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_BRAND |
| </td> |
| <td> |
| A marca (por exemplo, da operadora) de personalização do software, se houver. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_CHARACTERISTICS |
| </td> |
| <td> |
| Características do <code>aapt</code> para permitir a inclusão de recursos específicos da variante para um pacote. |
| </td> |
| <td> |
| tablet,nosdcard |
| </td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_COPY_FILES |
| </td> |
| <td> |
| Lista de palavras como <code>source_path:destination_path</code>. O arquivo no caminho de origem precisa ser copiado para o caminho de destino ao criar esse produto. As regras para as etapas de cópia são definidas em config/makefile. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_DEVICE |
| </td> |
| <td> |
| Nome do design industrial. Esse também é o nome da placa, e o sistema de criação o utiliza para localizar o <code>BoardConfig.mk.</code>. |
| </td> |
| <td> |
| <code>tuna</code> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_LOCALES |
| </td> |
| <td> |
| Uma lista separada por espaço de código de idioma de duas letras, pares de códigos de país de duas letras que descrevem várias configurações para o usuário, como o idioma da IU e a formatação de data, hora e moeda. A primeira localidade listada em PRODUCT_LOCALES é usada como a padrão do produto. |
| </td> |
| <td> |
| <code>en_GB de_DE es_ES fr_CA</code> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_MANUFACTURER |
| </td> |
| <td> |
| Nome do fabricante. |
| </td> |
| <td> |
| <code>acme</code> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_MODEL |
| </td> |
| <td> |
| Nome visível para o usuário final do produto final. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_NAME |
| </td> |
| <td> |
| Nome visível para o usuário final do produto geral. Aparece na tela Configurações > Sobre. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_OTA_PUBLIC_KEYS |
| </td> |
| <td> |
| Lista de chaves públicas Over the Air (OTA) para o produto. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_PACKAGES |
| </td> |
| <td> |
| Lista os APKs e os módulos a serem instalados. |
| </td> |
| <td> |
| <code>Calendar Contacts</code> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_PACKAGE_OVERLAYS |
| </td> |
| <td> |
| Indique se os recursos padrão precisam ser usados ou se alguma sobreposição específica do produto precisa ser adicionada. |
| </td> |
| <td> |
| <code>vendor/acme/overlay</code> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| PRODUCT_PROPERTY_OVERRIDES |
| </td> |
| <td> |
| Lista de atribuições de propriedades do sistema no formato "chave=valor". |
| </td> |
| <td></td> |
| </tr> |
| </tbody> |
| </table> |
| |
| <h3 id="ANDROID_VENDOR_KEYS">Definir ANDROID_VENDOR_KEYS para conexão por USB</h3> |
| |
| <p>A variável de ambiente <code>ANDROID_VENDOR_KEYS</code> permite que os fabricantes de dispositivos acessem as versões de produção por <code>adb</code>. Gere uma chave para cada versão que cada dispositivo aceitará, armazene-as internamente (como em <code>vendor/oem-name/security/adb/</code>) e use <code>ANDROID_VENDOR_KEYS</code> para dizer ao <code>adb</code> para usar essas chaves canônicas em vez de chaves aleatórias.</p> |
| |
| <p>Use a variável de ambiente <code>ANDROID_VENDOR_KEYS</code> para apontar para o diretório que contém as chaves públicas e privadas <code>adb</code> geradas utilizadas para criptografia. A chave privada é armazenada no arquivo. A chave pública é armazenada no arquivo .pub. A variável de ambiente <code>ANDROID_VENDOR_KEYS</code> aponta para um arquivo ou diretório onde os pares de chaves gerados são armazenados.</p> |
| |
| <p>Essa variável é definida como um arquivo ou diretório que contém pares de chaves de autenticação RSA de 2.048 bits gerados com o comando de arquivo <code>adb keygen</code>. |
| Esses pares de chaves são adicionais aos pares de chaves RSA gerados pelo servidor ADB. Um par de chaves RSA é necessário quando você usa o <code>adb</code> para se conectar via USB pela primeira vez.</p> |
| |
| <p>É preciso aceitar a chave RSA do computador host para conceder explicitamente o acesso <code>adb</code> ao dispositivo. Por padrão, os pares de chaves gerados pelo servidor ADB ficam nos seguintes diretórios de armazenamento de chaves como <code>adbkey</code> (chave privada) e <code>adbkey.pub</code> (chave pública):</p> |
| |
| <p>Para locais de arquivos, no MacOS, ele provavelmente será: <code>$HOME/.android</code>. No Windows e Linux, ele será: <code>%USERPOFILE%\.android</code>. No Windows, as chaves de autenticação RSA também podem estar em <code>C:\Windows\System32\config\systemprofile\.android</code> em alguns casos. Quando o servidor ADB precisar de uma chave, ele primeiro pesquisará no diretório de armazenamento de chaves do servidor ADB. Se nenhuma chave for encontrada, ela verificará a variável de ambiente <code>ANDROID_VENDOR_KEYS</code>. Se nenhuma chave for encontrada, o servidor local do ADB gerará e salvará um novo par de chaves no diretório de armazenamento de chaves do servidor ADB.</p> |
| |
| <p class="note"><strong>Observação</strong>: você pode modificar o diretório padrão onde o servidor ADB armazena as chaves RSA configurando a variável de ambiente <code>ANDROID_SDK_HOME</code>. No dispositivo, as chaves são armazenadas no arquivo <code>/data/misc/adb/adb_keys/</code>, e novas chaves autorizadas são anexadas ao mesmo arquivo à medida que você as aceita.</p> |
| |
| </body></html> |
