編譯aosp需要什麼條件

㈠ 編譯aosp為什麼要安裝gcc

如果你的源程序是 C 語言的話，而你又是在 linux 系統下開發程序，那你就必須使用 gcc 編譯器；如果你是在 UNIX 系統下開發 C 語言源程序，那麼就要使用 cc 編譯器。所以說，最關鍵的還是要看你的軟體開發平台。

㈡ 自己可以編譯安卓源碼嗎

用最新的Ubuntu 16.04,請首先確保自己已經安裝了Git.沒安裝的同學可以通過以下命令進行安裝:

sudo apt-get install git git config –global user.email 「[email protected]」 git config –global user.name 「test」

其中[email protected]為你自己的郵箱.

簡要說明

android源碼編譯的四個流程:1.源碼下載;2.構建編譯環境;3.編譯源碼;4運行.下文也將按照該流程講述.

源碼下載

由於某牆的原因,這里我們採用國內的鏡像源進行下載.
目前,可用的鏡像源一般是科大和清華的,具體使用差不多,這里我選擇清華大學鏡像進行說明.(參考:科大源,清華源)

repo工具下載及安裝

通過執行以下命令實現repo工具的下載和安裝

mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo

補充說明
這里,我來簡單的介紹下repo工具,我們知道AOSP項目由不同的子項目組成,為了方便進行管理,Google採用Git對AOSP項目進行多倉庫管理.在聊repo工具之前,我先帶你來聊聊多倉庫項目:

我們有個非常龐大的項目Pre,該項目由很多個子項目R1,R2,...Rn等組成,為了方便管理和協同開發,我們為每個子項目創立自己的倉庫,整個項目的結構如下:

這里寫圖片描述

執行完該命令後,再使用make命令繼續編譯.某些情況下,當你執行jack-admin kill-server時可能提示你命令不存在,此時去你去out/host/linux-x86/bin/目錄下會發現不存在jack-admin文件.如果我是你,我就會重新repo sync下,然後從頭來過.

錯誤三:使用emulator時,虛擬機停在黑屏界面,點擊無任何響應.此時,可能是kerner內核問題,解決方法如下:
執行如下命令:

通過使用kernel-qemu-armv7內核 解決模擬器等待黑屏問題.而-partition-size 1024 則是解決警告: system partion siez adjusted to match image file (163 MB >66 MB)

如果你一開始編譯的版本是aosp_arm-eng,使用上述命令仍然不能解決等待黑屏問題時,不妨編譯aosp_arm64-eng試試.

結束吧

到現在為止,你已經了解了整個android編譯的流程.除此之外,我也簡單的說明android源碼的多倉庫管理機制.下面,不妨自己動手嘗試一下.

㈢ 手機支持pt是什麼意思

手機支持「PT」中的「PT」指的是谷歌的「project treble」。

1、Google引入了一個名為 vendor interface1的理念，並用它將 Vender Implementation——由晶元製造商編寫的設備專屬的底層部分，從 Android 系統框架中剝離出來。

2、以往Android智能手機升級的步驟非常繁雜。首先，Android開發團隊以最快速的將最新版本開放源代碼。然後，晶元製造商（高通、MTK）進行修改以滿足特定的硬體，尤其是適配驅動和電源管理機制，再發布給設備製造商。

3、谷歌表示，Android智能手機更新到最新版本的過程非常耗時，而且對大量智能手機廠商來說成本不低，這就是為什麼如今Android操作系統市場份額如此零散的最大原因。

(3)編譯aosp需要什麼條件擴展閱讀：

手機支持project treble的意義

手機如果想要預裝或升級 Android 8.0，都必須先經過 Project Treble 的認證。這個認證過程意味著，在 OEM 廠商對 AOSP 源碼進行定製前，這部手機就已經能夠運行 AOSP 系統並通過 CDD、VTS 等一系列測試了。

Project Treble除了能緩解系統碎片化之外，還能使自定義 Rom 更簡單。曾經便有一位開發者僅在一天內就開發出了華為 Mate 9的 Android Oreo Rom。

㈣ Android學習之Build環境介紹

這里略過對android在手機上的文件系統框架的闡述（google或者都能幫助你找到對應的信息），主要看google是如何把生成合適的rootfs的工作整合到它的build體系當中，同時，會順帶看一下CyanogenMod中對應各種機型的build機制。
首先，來看一下Android的build系統中，使用到的編譯選項和相關工具
具體的目錄在：mydroid/build/tools/下
|-- acp
這是一個稍微改良的cp命令，用來應付在windows/MAC/Linux下的cp命令的缺陷，其中的README很值得一看！
|-- adbs
這是一個用來查看crash問題的工具，詳細請看《Android調試工具之adbs》
|-- Android.mk
|-- apicheck
用來進行發布前的API檢查（參見mydroid/build/core/tasks/apicheck.mk），是否新編譯的系統中有破壞API兼容性或是非法的API
這里的代碼是用java寫的用來檢查編譯時生成的API相關信息的xml文件（mydroid/framework/base/api/中），可以參考裡面對於xml文件解析的代碼
|-- apriori
實現prelink的工具，簡單介紹參見（mydroid/bionic/linker/README.TXT）
|-- atree
為android SDK服務的一個工具，用來按照指定xxx.atree文件中的內容進行一些文件操作
|-- bin2asm
不太明白具體的用處，應該是用來應付mac上編譯android一些與gcc相關的問題
|-- buildinfo.sh
生成target中的各種xxx.prop文件，如system.prop, build.prop等
|-- check_builds.sh
包裝了diff，用來看2個發布版本之間變化
|-- check_prereq
device上進行ota升級時的工具之一
|-- compare_fileslist.py
與check_builds.sh配合完成版本比較的腳本
|-- droiddoc
Android更具javadoc的一些移植
|-- mp-package-stats
簡單的查看一個jar/apk文件內的dex和其它文件的大小信息
|-- event_log_tags.py
處理event-log-tags的內容，關於event-log-tags文件的意義參見《Android學習之event-log-tags是神馬》
|-- fileslist.py
簡化的列出指定目錄下所有文件及大小的腳本 -- 可以放入自己的工具庫了使用：）
|-- findleaves.py
在指定目錄中（可多個）找指定文件的腳本 -- 可以放入自己的工具庫了使用：）
|-- fixlinebreaks.sh
把windows中的換行改為linux下的 -- 可以放入自己的工具庫了使用：大散蘆）
|-- fs_config
列出指定文件夾滾帶及文件的許可權
|-- fs_get_stats
得到指定文件夾下文件的簡單stats信息
|-- iself
判斷文件是否是ELF格式
|-- isprelinked
判斷文件是否是prelink過的
|-- java-event-log-tags.py
處理event-log-tags的內容，關於event-log-tags文件的意義參見《Android學習之event-log-tags是神馬》
|-- kcm
key character map的工具， 相關資料參照：
|-- lsd
!!!!!! ???
|-- merge-event-log-tags.py
處理event-log-tags的內容，關於event-log-tags文件的意掘野義參見《Android學習之event-log-tags是神馬》
|-- mktarball.sh
與fs_get_stats配合而執行的打包工具
|-- print_mole_licenses.sh
顯示當前目錄下所有mole信息
|-- releasetools
-- check_target_files_signatures
|-- common.py
|-- edify_generator.py
|-- img_from_target_files
|-- ota_from_target_files
`-- sign_target_files_apks
|-- rgb2565
rgb轉換工具
|-- signapk
命令行下對jar包簽名的工具
|-- soslim
Android定製的編譯工具之一，簡單介紹參見（mydroid/bionic/linker/README.TXT）
|-- warn.py
解析Android系統編譯log的工具
`-- zipalign
zipfile的對齊工具，參見該文件夾下的README.TXT
#p#副標題#e#
在來看看Android編譯系統中定義的一些通用XXX.mk文件
mydroid/build/core/
|-- armelflib.x
|-- armelf.x
|-- armelf.xsc
|-- base_rules.mk
|-- binary.mk
|-- build_id.mk
|-- build-system.html
|-- checktree
|-- cleanbuild.mk
|-- cleanspec.mk
|-- clear_vars.mk
|-- combo
|-- config.mk
|-- _headers.mk
|-- definitions.mk
|-- device.mk
|-- dex_preopt.mk
|-- distdir.mk
|-- droiddoc.mk
|-- mpvar.mk
|-- dynamic_binary.mk
|-- envsetup.mk
|-- executable.mk
|-- filter_symbols.sh
|-- find-jdk-tools-jar.sh
|-- help.mk
|-- host_executable.mk
|-- host_java_library.mk
|-- host_native_test.mk
|-- host_prebuilt.mk
|-- host_shared_library.mk
|-- host_static_library.mk
|-- java_library.mk
|-- java.mk
|-- legacy_prebuilts.mk
|-- main.mk
|-- Makefile
|-- multi_prebuilt.mk
|-- native_test.mk
|-- node_fns.mk
|-- notice_files.mk
|-- package.mk
|-- pathmap.mk |-- phony_package.mk
|-- prebuilt.mk
|-- process_wrapper_gdb.cmds
|-- process_wrapper_gdb.sh
|-- process_wrapper.sh
|-- proct_config.mk
|-- proct.mk
|-- proguard.flags
|-- proguard_tests.flags
|-- raw_executable.mk
|-- raw_static_library.mk
|-- root.mk
|-- shared_library.mk
|-- static_java_library.mk
|-- static_library.mk
|-- tasks
|-- user_tags.mk
`-- version_defaults.mk
#p#副標題#e#
這里，目錄在mydroid/build/core/tasks/有一些特別的task
|-- apicheck.mk, 判斷api是否符合AOSP的規范
|-- cts.mk cts測試， 可以在代碼根目錄， make cts, 編譯結束之後，進入out/host/linux-x86/bin/下，執行cts命令
|-- ide.mk IDE開發環境
|-- proct-graph.mk
`-- sdk-addon.mk
NDK的build環境沒有包含在標注難得AOSP的/build/目錄下
而是在mydroid/ndk/build下
$ cd ndk/build/tools
$ export ANDROID_NDK_ROOT=aosp-root/ndk
$ ./make-release --help
一些小技巧
如何顯示每次編譯所包含的所有xxx.mk文件
找到build/core/main.mk
把include $（subdir_makefiles）替換為
[plain] view plain $（foreach subdir_makefile, $（subdir_makefiles），
$（info Including $（subdir_makefile））
$（eval include $（subdir_makefile））)
subdir_makefile :=
如果遇見API相關的PACKAGING/checkapi-current-timestamp] Error 38
需要執行：make update-api
如何在AOSP代碼目錄之外編譯
[plain] view plain # Paths and settings
TARGET_PRODUCT = generic
ANDROID_ROOT = /home/karim/android/aosp-2.3.x
BIONIC_LIBC = $（ANDROID_ROOT）/bionic/libc
PRODUCT_OUT = $（ANDROID_ROOT）/out/target/proct/$（TARGET_PRODUCT）
CROSS_COMPILE =
$（ANDROID_ROOT）/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
# Tool names
AS = $（CROSS_COMPILE）as
AR = $（CROSS_COMPILE）ar
CC = $（CROSS_COMPILE）gcc
CPP = $（CC） -E
LD = $（CROSS_COMPILE）ld
NM = $（CROSS_COMPILE）nm
OBJCOPY = $（CROSS_COMPILE）obj
OBJDUMP = $（CROSS_COMPILE）objmp
RANLIB = $（CROSS_COMPILE）ranlib
READELF = $（CROSS_COMPILE）readelf
SIZE = $（CROSS_COMPILE）size
STRINGS = $（CROSS_COMPILE）strings
STRIP = $（CROSS_COMPILE）strip
export AS AR CC CPP LD NM OBJCOPY OBJDUMP RANLIB READELF
SIZE STRINGS STRIP
# Build settings
CFLAGS = -O2 -Wall -fno-short-enums
HEADER_OPS = -I$（BIONIC_LIBC）/arch-arm/include
-I$（BIONIC_LIBC）/kernel/common
-I$（BIONIC_LIBC）/kernel/arch-arm
LDFLAGS = -nostdlib -Wl,-dynamic-linker,/system/bin/linker
$（PRODUCT_OUT）/obj/lib/crtbegin_dynamic.o
$（PRODUCT_OUT）/obj/lib/crtend_android.o
-L$（PRODUCT_OUT）/obj/lib -lc -ldl
# Installation variables
EXEC_NAME = example-app
INSTALL = install
INSTALL_DIR = $（PRODUCT_OUT）/system/bin
# Files needed for the build
OBJS = example-app.o
# Make rules
all: example-app
.c.o:
$（CC） $（CFLAGS） $（HEADER_OPS） -c {1}lt;
example-app: ${OBJS}
$（CC） -o $（EXEC_NAME） ${OBJS} $（LDFLAGS）
install: example-app
test -d $（INSTALL_DIR） || $（INSTALL） -d -m 755 $（INSTALL_DIR）
$（INSTALL） -m 755 $（EXEC_NAME） $（INSTALL_DIR）
clean:
rm -f *.o $（EXEC_NAME） core
distclean:
rm -f *~
rm -f *.o $（EXEC_NAME） core
如何增加一個新的設備
[plain] view plain $ cd ~/android/aosp-2.3.x
$ . build/envsetup.sh
$ mkdir -p device/acme/coyotepad
$ cd device/acme/coyotepad
進入AndroidProcts.mk
PRODUCT_MAKEFILES :=
$（LOCAL_DIR）/full_coyotepad.mk
對於full_coyotepad.mk
$（call inherit-proct, $（SRC_TARGET_DIR）/proct/languages_full.mk）
$（call inherit-proct, $（SRC_TARGET_DIR）/proct/full.mk）
DEVICE_PACKAGE_OVERLAYS :=
PRODUCT_PACKAGES +=
PRODUCT_COPY_FILES +=
PRODUCT_NAME := full_coyotepad
PRODUCT_DEVICE := coyotepad
PRODUCT_MODEL := Full Android on CoyotePad, meep-meep
在BoardConfig.mk中
TARGET_NO_KERNEL := true
TARGET_NO_BOOTLOADER := true
TARGET_CPU_ABI := armeabi
BOARD_USES_GENERIC_AUDIO := true
USE_CAMERA_STUB := true
打開vendorsetup.sh
add_lunch_combo full_coyotepad-eng
#p#副標題#e#

㈤ Android在Ubuntu下編譯完整aosp需要多少硬碟空間

6.0以後的AOSP我沒編譯過，不太了解需要多大空間。
不過5.1.1我倒是編過，你可以參考一下：mac編譯aosp的配置需求？ - 知乎用戶的回答
編譯完了，大概佔用了60G,6.0可能會更大一些。
像你列舉的250G等容量的硬碟，用來編AOSP，容量上是綽綽有餘的。其實如果經濟上允許，推薦你選擇一個SSD，對於編譯速度的提升，效果顯著。

㈥ 大牛們是怎麼閱讀 Android 系統源碼的

由於工作需要大量修改framework代碼, 在AOSP(Android Open Source Project)源碼上花費了不少功夫, Application端和Services端都看和改了不少.
如果只是想看看一些常用類的實現, 在Android包管理器里把源碼下載下來, 隨便一個IDE配好Source Code的path看就行.
但如果想深入的了解Android系統, 那麼可以看下我的一些簡單的總結.

知識
Java
Java是AOSP的主要語言之一. 沒得說, 必需熟練掌握.
熟練的Android App開發
Linux
Android基於Linux的, 並且AOSP的推薦編譯環境是Ubuntu 12.04. 所以熟練的使用並了解Linux這個系統是必不可少的. 如果你想了解偏底層的代碼, 那麼必需了解基本的Linux環境下的程序開發. 如果再深入到驅動層, 那麼Kernel相關的知識也要具備.
Make
AOSP使用Make系統進行編譯. 了解基本的Makefile編寫會讓你更清晰了解AOSP這個龐大的項目是如何構建起來的.
Git
AOSP使用git+repo進行源碼管理. 這應該是程序員必備技能吧.
C++
Android系統的一些性能敏感模塊及第三方庫是用C++實現的, 比如: Input系統, Chromium項目(WebView的底層實現).

硬體
流暢的國際網路
AOSP代碼下載需要你擁有一個流暢的國際網路. 如果在下載代碼這一步就失去耐心的話, 那你肯定沒有耐心去看那亂糟糟的AOSP代碼. 另外, 好程序員應該都會需要一個流暢的Google.
一台運行Ubuntu 12.04的PC.
如果只是閱讀源碼而不做太多修改的話, 其實不需要太高的配置.
一台Nexus設備
AOSP項目默認只支持Nexus系列設備. 沒有也沒關系, 你依然可以讀代碼. 但如果你想在大牛之路走的更遠, 還是改改代碼, 然後刷機調試看看吧.
高品質USB線
要刷機時線壞了, 沒有更窩心的事兒了.
軟體
Ubuntu 12.04
官方推薦, 沒得選.
Oracle Java 1.6
注意不要用OpenJDK. 這是個坑, 官方文檔雖然有寫, 但還是單獨提一下.
安裝:
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java6-installer
sudo apt-get install oracle-java6-set-default

Eclipse
估計會有不少人吐槽, 為什麼要用這個老古董. 其實原因很簡單, 合適. 剛開始搞AOSP時, 為了找到效率最優的工具, 我嘗試過Eclipse, IntelliJ IDEA, Vim+Ctags, Sublime Text+Ctags. 最終結果還是Eclipse. 主要優點有:
有語法分析 (快速准確的類, 方法跳轉).
支持C++ (IntelliJ的C++支持做的太慢了).
嵌入了DDMS, View Hierarchy等調試工具.
為了提高效率, 花5分鍾背下常用快捷鍵非常非常值得.
調整好你的classpath, 不要導入無用的代碼. 因為AOSP項目代碼實在是太多了. 當你還不需要看C++代碼時, 不要為項目添加C++支持, 建索引過程會讓你崩潰.
Intellij IDEA
開發App必備. 當你要調試系統的某個功能是, 常常需要迅速寫出一個調試用App, 這個時候老舊的Eclipse就不好用了. Itellij IDEA的xml自動補全非常給力.
巨人的肩膀

這個一定要先讀. 項目介紹, 代碼下載, 環境搭建, 刷機方法, Eclipse配置都在這里. 這是一切的基礎.

這個其實是給App開發者看的. 但是裡面也有不少關於系統機制的介紹, 值得細讀.

此老羅非彼老羅. 羅升陽老師的博客非常有營養, 基本可以作為指引你開始閱讀AOSP源碼的教程. 你可以按照博客的時間順序一篇篇挑需要的看.但這個系列的博客有些問題:
早期的博客是基於舊版本的Android;
大量的代碼流程追蹤. 讀文章時你一定要清楚你在看的東西在整個系統處於什麼樣的位置.

鄧凡平老師也是為Android大牛, 博客同樣很有營養. 但是不像羅升陽老師的那麼系統. 更多的是一些技術點的深入探討.

Android官方Issue列表. 我在開發過程中發現過一些奇怪的bug, 最後發現這里基本都有記錄. 當然你可以提一些新的, 有沒有人改就是另外一回事了.

一定要能流暢的使用這個工具. 大量的相關知識是沒有人系統的總結的, 你需要自己搞定.
其它
代碼組織
AOSP的編譯單元不是和git項目一一對應的, 而是和Android.mk文件一一對應的. 善用mmm命令進行模塊編譯將節省你大量的時間.
Binder
這是Android最基礎的進程間通訊. 在Application和System services之間大量使用. 你不僅要知道AIDL如何使用, 也要知道如何手寫Binder介面. 這對你理解Android的Application和System services如何交互有非常重要的作用. Binder如何實現的倒不必著急看.
HAL
除非你對硬體特別感興趣或者想去方案公司上班, 否則別花太多時間在這一層.
CyanogenMod
這是一個基於AOSP的第三方Rom. 從這個項目的wiki里你能學到很多AOSP官方沒有告訴你的東西. 比如如何支持Nexus以外的設備.
DIA
這是一個Linux下畫UML的工具, 能夠幫你梳理看過的代碼.
XDA

這里有最新資訊和最有趣的論壇.
想到了再補充.

㈦ 如何編譯一個可以燒寫進手機中的ROM，Android安卓開發者

首先．還是跟其它文章講的一樣．先下載ANDORID的源碼．在下源碼之前．請看下面第一步
----------
增加代碼，下真機配置

1
vim .repo/local_manifest.xml

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project path="kernel" name="kernel/msm" revision="refs/heads/android-msm-2.6.29"/>
<project path="hardware/htc/dream" name="platform/hardware/htc/dream" revision="master"/>

</manifest>

增加上面這段代碼，為一個配置．告訴伺服器．我們下的代碼．是要裝進真機的．
（就為了多下載一個KERNEL下來。。還有下載DREAM的真機配置參數..）

小哈在這里折騰了很久．很久．．非常久．．回憶起來內牛滿面

-----
下相關的代碼

2.

repo sync

-----
3.
vim env_rc
加入:
export EMU=/home/coconut/cupcake/out/host/linux-x86/bin
export ARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=$PATH:/home/coconut/cupcake/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin:${EMU}

source env_rc

4.

編譯內核及無線網路驅動

$ cd $ANDROID/kernel
$ make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- msm_defconfig # 設定默認的msm配置

#編譯內核
make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

#編譯無線網路驅動
cd $ANDROID/system/wlan/ti/sta_dk_4_0_4_32
make ARCH=arm CROSS_COMPILE=$ANDROID/prebuilt/linux-86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- KERNEL_DIR=$ANDROID/kernel

//內核拷到目錄下
$ cp $ANDROID/kernel/arch/arm/boot/zImage $ANDROID/vendor/htc/dream-open/kernel
$ cp $ANDROID/system/wlan/ti/sta_dk_4_0_4_32/wlan.ko $ANDROID/vendor/htc/dream-open/wlan.ko

5.
在HTC網站(developer.htc.com/adp.html)
下載名為signed-dream_devphone_userdebug-ota-14721.zip的包，並把它放在$ANDROID目錄下
$ cd $ANDROID
$ source build/envsetup.sh

$ lunch aosp_dream_us-eng # 指明機型
這樣編譯出來.就會在OUT下出來一個DREAM_OPEN的目錄.裡面就有相關的鏡像文件了.

$ cd vendor/htc/dream-open
$ ./unzip-files.sh ＃ 解壓htc相關驅動
$ cd $ANDROID
$ vi buildspec.mk ＃ 新建配置文件

－－－－
Vim htc_dream.mk

vim /oracle/android/src/vendor/htc/dream-open/htc_dream.mk

在頭部增加
PRODUCT_PACKAGES := \
Calculator \
Email \
ImProvider \
SdkSetup \
VoiceDialer

完成。
回到根目錄

cd /oracle/android/src
vim buildspec.mk
加入( 2010.7.7 不需要加入)：
#TARGET_PRODUCT:=htc_dream
#TARGET_PREBUILT_KERNEL:=kernel/arch/arm/boot/zImage

增加:
CUSTOM_LOCALES:=zh_CN

然後：

其中增加環境：
ubuntu 8.10 , sudo apt-get libelf-dev

make clean

// 保證PC有 1280 內存, 加上 1000 SWAP空間..虛擬機也是如此.
然後開始編譯 BOOT.IMG SYSTEM.IMG USERDATA.IMG:
make -j2

接下來
mmm -B $ANDROID/packages/apps/Luancher/ snod

cd out/target/proct/dream-open/

//先測試:
emulator -system . -kernel ~/cupcake/prebuilt/android-arm/kernel/kernel-qemu -data userdata.img
因為出來了BOOT.IMG.這個是真機的..所以不能用BOOT做為內核.要用模擬器來做內核.

//然後開始燒機
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash userdata userdata.img

fastboot reboot

㈧ 鴻蒙抄襲安卓看這一篇就夠了

01

什麼是 AOSP ？

很多人都說鴻蒙是 AOSP 套殼，那麼我們首先得明白什麼是 AOSP？

AOSP 是"Android Open Source Project"的縮寫，中文意為"安卓開放源代碼項目"， AOSP 是基於 Linux 開的。

AOSP 是由谷歌主導的一個開源項目，通過 AOSP 可以編譯出一個比較純凈的，可以用於智能設備的操作系統。

而 Android，尤其是首字母 A 大寫的時候，是屬於谷歌的一個商標，不屬於 AOSP 所有，未經允許不能隨意在商業產品中使用。

Android 系統是開源的 AOSP 和額外的閉源部分（其中包括 GMS ）的組合而成，所以可以認為 Android=AOSP+GMS 。

網友有一個通俗的比喻： AOSP 是個毛坯房，Android 是個精裝房 。

由於 AOSP 是開源的，一些第三方機構就可以以 AOSP 為基礎，做出自己的改進，並對不同機型適配，然後自己取一個名字。

比如小米的 MIUI、華為的 EMUI、或者魅族的 Flyme。

02

什麼是鴻蒙？

鴻蒙是一個面向全場景的分布式操作系統，蒙是基於微內核的全場景分布式操作系統，目前華為已經將鴻蒙捐獻給了 開放原子開源基金會 。

有人說鴻蒙是基於 2012 年華為的 LiteOS 開發而來，LiteOS 是輕量級物聯網操作系統，目前也以及完全開源。

從客觀上來講，鴻蒙肯定借鑒了 LiteOS 開發中所積累的經驗，所以 華為鴻蒙OS 算是 LiteOS 的一個發展產物 ，但它們是兩款完全不同的操作系統。

這里還需要和大家明確，區分一個概念，說實話如果不是為了給大家寫這篇文章，查了很多資料，不然我也混淆的。

Openharmony 和 HarmonyOS（鴻蒙操作系統） 是兩個完全不同的概念！

HarmonyOS 是華為研發的面向萬物互聯時代的全新的、獨立的智能終端操作系統，為不同設備的智能化、互聯與協同提供統一的語言。

華為把 HarmonyOS 中基礎功能提取出來，打包成功一個項目叫做：Openharmony ，把 Openharmony 捐獻給原子開源基金會。

華為這次發布的 HarmonyOS 2 是華為基於開源項目 OpenHarmony 2.0 開發的面向多種全場景智能設備的商用版本。

OpenHarmony 是華為主要貢獻的，不屬於華為，屬於開源組織；而 HarmonyOS 是華為的商業系統，屬於華為擁有。

03

國產廠商為什麼不跟進？

大家如果明白上面這兩個概念的區別之後，就應該很容易明白，為什麼國內廠商沒有跟進鴻蒙？

上面說的有點繞，做一個簡單的比喻大家應該就明白了：

HarmonyOS 2 = Openharmony 2 + 華為的 EMUI + 兼容安卓部分

根據這個公式，我們可以回答好幾個問題：

1、Openharmony 是不兼容安卓的，也沒有什麼 AOSP 的事情，是一個純正、獨立的開源操作系統。

2、 HarmonyOS 2 是不開源的，是華為基於 Openharmony 2 開發的一個商業版本。

為了兼容安卓應用，必定使用了一些 AOSP 的內容，同時華為是不可能將 EMUI 開放給同行的，所以同行廠商沒辦法直接使用 HarmonyOS 2 。

3、如果讓國內同行都兼容鴻蒙的話，他們需要做的工作是：基於 Openharmony 2 開發自己的 UI。

比如 MIUI + 兼容以前應用，工作量巨大，可能不是一時半會就可以搞定，同時他們還需要考慮谷歌在國外對他們制裁的風險。

可以套用上面的比如： Openharmony 2 是個毛坯房，而 HarmonyOS 2 是個精裝房。

而小米OV等廠商要使用鴻蒙，至少需要他們自己來裝修吧，全部用 HarmonyOS 2 ，大家體驗完全一致沒有差異化，也沒有什麼意思。

並且，小米OV他們肯定也不會放棄自己的 MUUI、Flyme，因為這是他們的核心競爭力和收入來源呀。

說實話，現在硬要小米、VIVO、OPPO等支持鴻蒙，也有一點強人所難，可能需要有一個過程慢慢來准備吧。