为AOSP创建特定的设备树 [英] Create specific device tree for AOSP

问题描述

我遵循了Google的官方教程来构建自己的AOSP，并且在所有步骤中均获得了成功:我在一个连结模拟器上运行了一个纯AOSP版本". https://source.android.com/source/building.html

故事是，我有一些罕见的设备随附一些装有预装应用程序的Android版本，这显然是我所不希望的.我想将Pure AOSP移植到我的设备上-没有任何改进或新功能(例如，我不想知道如何构建CM git repo).

1. 它是否可以正常工作，只需将正确的文件添加到我的本地master分支上方，然后将其添加到/device/vendor/model 中，然后在master分支的 cwd 下执行 $.build/envsetup.sh 吗?

2. 如果是，我需要在/device/vendor/model 下放置哪些文件及其内容?我找到了很多指南，介绍如何提取已存在的CM树或其他内容(用于AOSP的Android设备配置，并查看多个设备的git repo，我试图找出最小的完整文件集&他们的内容，但我没有找到相关性.我认为必须有最小的完整集，并且每个文件都存在编程原因.我在现有的git repo中看到的是每个开发人员出于自己的原因而添加的这套+自定义附加功能.

3. 后果如何确定内部版本名称&执行 $ Lunch< Build name>-< Buildtype> ?

的构建类型

4. 如何集成 $ make otapackage 来构建熟悉的一个zip文件，以通过像CWM这样的恢复来加载?

这是我的上一篇文章之后的内容:移植AOSP特定的硬件设备，但是这里的问题更加具体.

解决方案

1. 将新设备添加到AOSP的过程:首先，设备定义应放在设备/供应商/模型路径中.然后添加带有COMMON_LUNCH_CHOICES的AndroidProducts.mk文件，该文件指定AOSP的名称和构建类型(英文，用户调试，发行版)和PRODUCT_MAKEFILES，该文件应指向您的主设备makefile.

2. 设备/供应商/型号的内容:设备/供应商/模型包含设备本身的核心配置，例如蓝牙配置，audio_policy配置，wpa_supplicant配置，设备树，预构建的硬件固件或用于引导或恢复的预构建映像.它还包含框架叠加层，您可以配置一些框架参数，例如，确定您的android应该具有导航栏或所需的状态栏类型.它还包含SELinux策略，您可以为不同的流程制定规则，定义新的上下文，甚至禁止某些流程运行或访问某些资源.最后它包含makefile，您可以包含所需的AOSP软件包(aosp.mk)或设备配置(BoardConfig.mk)，例如，什么是cpu体系结构，gpu驱动程序名称或是否应使用硬件作曲家或您的系统是否具有wifi，蓝牙，以及是否具有所需驱动程序的地址和名称.另外，我们还有init(如果您想对android启动过程添加一些其他更改)，fstab(描述android分区及其安装方式)和ueventd以及应该在此目录中的一些udev规则.

3. 看数字1.

4. 对于OTA更新软件包，首先需要生成必需的密钥，这对于生成ota更新的zip至关重要.如果您现在开始，我建议您使用fastboot.但是如果您愿意，我会提供一个链接，该链接显示了如何加密所需的程序包.加密完成后，您可以通过以下命令生成OTA映像:

   img_from_target_files签名目标文件.zip签名-img.zip

OTA更新指南: https://source.android.com/devices/tech/ota/sign_builds

5. 我认为您要寻找的不是OTA软件包，而是如何形成统一的zip.一旦安装了系统，OTA软件包将进行更改.我的OTA程序包具有〜500mb的文件(有效负载)等.这是完整更新.增量更新要小得多.但是，当我构建一个可刷新的程序包时，会得到〜2.6gb的文件.闪烁因设备而异.QCom(Qualcomm)需要QFil工具来刷新整个系统.或者，您通过fastboot刷新单个映像.所以我不知道4.如何为您工作.原始答案似乎基于Google提供的不良文档.当涉及到AOSP时，必须有经验，文档永远都不够

I followed official Google`s tutorial to build my own AOSP and succeeded in all steps: I have a "Pure AOSP version" running on a nexus emulator. https://source.android.com/source/building.html

The story is I have some rare device came with some Android version full of a pre-installed app's obviously I don't want. I want to port Pure AOSP to my device - without any improvements or new features (So, for example, I don`t want to know how to build CM git repo).

1. Is it working just add to my local above master branch correct files into /device/vendor/model and then under cwd of master branch execute $ . build/envsetup.sh ?

2. If so, what are the files and their content I need to put under /device/vendor/model? I found a lot of guides how to pull already existing tree of CM or something else (http://xda-university.com/as-a-developer/porting-aosp-roms-using-source-code) and including this Android device configuration for AOSP and looking on some git repo's of several devices, I tried to figure out the minimum complete set of files & their content but I didn't find a correlation. I think there must be the minimum complete set and there is programming reason for the existence of each file. And what I saw in existed git repo`s was this set + custom extras each developer added for his own reasons.

3. Aftermath How do I determine the Build name & Buildtype to execute $ lunch <Build name>-<Buildtype >?

4. How to integrate $ make otapackage in order to build the familiar one zip file to load via recovery like CWM?

This is following my previous post: Porting AOSP to specific hardware device, But here the questions are more specific.

解决方案

1. Process of adding new device to AOSP: First the device definition should be placed in device/vendor/model path. and then you should add AndroidProducts.mk file with COMMON_LUNCH_CHOICES which specify the name and the build type of your AOSP (Eng,userdebug,release) and PRODUCT_MAKEFILES which should point to you main device makefile.

2. What goes to device/vendor/model: device/vendor/model contains the core configuration of the device itself such as Bluetooth configs, audio_policy configs, wpa_supplicant configs, device-tree, prebuilt hardware firmware or prebuilt images for boot or recovery. Also it contains The framework overlays that you can configure some of the framework parameter and for example decide the your android should have a navigation bar or what type of status bar you want. It also contains the SELinux policies that you can make rules for different processes, defines new contexts, and even ban some processes of running or having access to some resources. and at last it contains the makefiles that you can include what packages you need for you AOSP (aosp.mk) or what is you device configuration (BoardConfig.mk) for example what is the cpu architecture, gpu driver name or should it use hardware composer or does you system have wifi, bluetooth and if it has what is the address and the name of the required drivers. Also we have the init (in case that you want to add some additional changes to android boot process), fstab (describes the android partition and how should they be mounted) and ueventd and some udev rules that should be in this directory.

3. Look at the number 1.

4. For OTA update packages, first you need to generate the required keys that is essential for generating a zip for ota updates. if you are starting now , I suggest that you use fastboot. but if you want I put a link that shows how you can encrypt the required packages. when the encryption is done, you can generate your OTA image by this command:

   img_from_target_files signed-target-files.zip signed-img.zip

OTA update guide: https://source.android.com/devices/tech/ota/sign_builds

5. I think what you are looking for are not OTA packages, but how to form the unified zip. OTA packages will have changes made after the system was installed once. My OTA package has ~500mb of files (payload) etc. This was Full Update. Incremental Updates are much smaller. However when I build a flashable package, I get ~2.6gb of files. Flashing varies device to device. QCom (Qualcomm) requires QFil Tool to flash the full system. Or you flash the individual images through fastboot. So I don't know how 4. works for you. Looks like the original Answer was based on the poor documentation from Google. When it comes to AOSP, experience is must, documentation is never enough

这篇关于为AOSP创建特定的设备树的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！