前言

在这篇文章中，主要是搭建好之后的系统环境，最终实现的效果为

1、编译出android13_r44的模拟器，支持Android studio唤起，方便后续对系统修改的验证。

2、samba文件共享，支持本地使用android studio阅读和修改源码

最终目的是配置好Android framework后续学习的基础环境，建议各位跟着实操一遍。有更好的环境推荐的话，欢迎分享！

关于源码下载

1、如果你电脑本地空间不足？请参考上一篇文章”Android13源码下载，非Linux系统?存储空间不足?“

2、如果你用的是云端的Linux系统或本地的Linux虚拟机。请参考上一篇文章”Android13源码下载，非Linux系统?存储空间不足?“其中的”安装工具与拉取“部分。

本文的运行环境是本地MacOS，构建和存放源码的Linux系统在服务器上

关于源码阅读 & 后续系统开发

如果你的源码是拉取到本地的，可以跳过这一步。

实际上，很多人是基于window系统，macOS系统。建议使用samba来实现文件共享。这样既能基于本地熟悉的android studio环境去阅读和修改源码，也能利用好android studio提供的avd管理功能（后文运行模拟器时有提到），方便后续修改系统后的快速验证。

强烈建议源码拉取和系统构建的Linux系统版本和官方保持一致，这能省去很多问题！！

关于文件共享

没有图形界面的linux系统阅读起android源码那可是地狱级的。使用Samba进行文件共享。

sudo apt-get install samba
sudo vim /etc/samba/smb.conf
# 在文件尾部添加以下内容,其中 path = "/codes/aosp" 是你的源码存放路径
# vim，按i是编辑，编辑好后按esc退出编辑模式，键入:wq保存并退出~
[aosp]
   comment = aosp directory
   path = /codes/aosp
   browseable = yes
   public = yes
   writable = yes
# 保存并退出
sudo service smbd restart
# 结束

Mac访问

打开Finder，按 command + k。smb://服务器ip地址。登录即可

Window访问

Windows徽标+R 在弹出的运行窗口中输入 \\服务器ip地址  即可访问。

关于编译构建

# 初始化环境
source build/envsetup.sh
# 查看设备菜单，选择对应序号的编译配置
lunch 
# 选择71(sdk_pc_x86_64-userdebug) 【模拟器一定要选择这个否则不会生成userdata.img】
# 开始编译
m
# 第一次编译，漫长的等待，中间可能会被中断，重新运行即可
# 其它，查看当前编译配置
echo "TARGET_PRODUCT-TARGET_BUILD_VARIANT"

关于模拟器

正常编译后的生成产物目录在out/target/product/目录下。
1、模拟器必须编译sdk_pc_x86_64-userdebug（我这里序号是71）才能正常生产userdata.img并在电脑上运行。
2、最终生产了/codes/aosp/out/target/product/emulator64_x86_64/

# 运行一遍emulator（为后面打包成zip）
emulator &
# 找不到指令则执行m sdk 获取android sdk

报错了？猜测可能是由于我编译的系统是不支持图形界面的Linux系统。因此这里选择打包成zip，拉到本地电脑下来运行。

# 打包成zip
m emu_img_zip

最终生产在/codes/aosp/out/target/product/emulator64_x86_64/sdk-repo-linux-system-images-eng.[用户名].zip

拷贝到本地电脑，解压。

打开Android studio随便创建一个模拟器test13(为了后面方便启动模拟器)

# 临时启动系统，emulator指令在android sdk platform-tools目录下
# emulator -sysdir [解压路径] -avd [创建的模拟器名称]
emulator -sysdir ~/Downloads/x86_64 -avd test13

一键启动，通过android studio启动，将解压的内容全部复制到avd的目录下，在用户根目录~/.android/avd目录下

最后点击模拟器运行，Cold boot now

运行截图

关于lunch

当我们初始化编译环境，执行lunch指令时会有许多可选编译的配置，如下

You're building on Linux
Lunch menu .. Here are the common combinations:
     1. aosp_arm-eng
     ......
     44. arm_krait-eng
     ......
     61. poplar-eng
     62. poplar-user
     63. poplar-userdebug
     ......
     71. sdk_pc_x86_64-userdebug
     ......
Which would you like? [aosp_arm-eng]
Pick from common choices above (e.g. 13) or specify your own (e.g. aosp_barbet-eng):

user：一般用于生产环境，性能测试的构建，无法进行adb root，忽略了许多log日志。
userdebug：调试环境，具有root，shell执行的高级权限。
eng：调试环境在userdebug的基础上，有更高的日志打印权限，且能使用额外的调试工具。

菜单从何而来？

我们执行lunch前会先执行source build/envsetup.sh，而这个sh文件只执行了以下三步，基本上能从命名大致猜到是什么情况

validate_current_shell
source_vendorsetup
addcompletions

先看关键的source_vendorsetup,搜索的是device vendor product三个目录。

# 执行命令
find -L device -maxdepth 4 -name "vendorsetup.sh"
find -L vendor -maxdepth 4 -name "vendorsetup.sh"
find -L product -maxdepth 4 -name "vendorsetup.sh"
# 搜索都为空，目前都没有vendor目录，
# 而且执行初始化环境时并没有打印including xxx的字样，先猜测这种方式应该是后续厂商定制设备

那lunch menu从何而来？ 查看源码prin_lunch_menu函数的值

# 菜单是通过遍历choices来的
# choices是COMMON_LUNCH_CHOICES字段的值
# 搜索COMMON_LUNCH_CHOICES字段
find /codes/aosp/device/ -type f | grep -r "COMMON_LUNCH_CHOICES"
# 输出结果是在一个AndroidProducts.mk的文件进行赋值的

发现是由AndroidProducts.mk文件来进行赋值的，那搜索这个文件

# 搜索AndroidProducts.mk文件
find /codes/aosp/device/ -name "AndroidProducts.mk"

至此可以粗略判断lunch指令生成的菜单的由来。由device下AndroidProducts.mk通过追加赋值COMMON_LUNCH_CHOICES字段来的，且支持扩展。 暂时了解到这里吧，至于如何自定义自己的定制设备，就后面再细说了。

下一篇，系统内核的编译实操~

标签：环境基础教程详细系统安培