整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
業(yè)網(wǎng)頁推廣時出現(xiàn)網(wǎng)頁兼容問題，不僅在pc端開發(fā)中會碰到，而且在APP開發(fā)當(dāng)中也會經(jīng)常碰到。
1、禁止圖片點(diǎn)擊放大
部分安卓手機(jī)點(diǎn)擊圖片會放大，如需要禁止放大，只需要設(shè)置css屬性，這樣會讓img標(biāo)簽的點(diǎn)擊事件失效，如果想要給圖片添加點(diǎn)擊事件就要給上面再寫一層。
方案：img{ pointer-events:none; }
2、禁止iOS設(shè)別長串?dāng)?shù)字為電話
方案：<meta name="format-detection" content="telephone=no" />
3、禁止賦值、選中文本
方案：設(shè)置CSS屬性，-webkit-user-select:none
4、一些情況下對非可點(diǎn)擊元素如（label,span）監(jiān)聽點(diǎn)擊事件，不會在iOS下觸發(fā)
方案：css屬性增加 cursor:pointer
5、上下拉動滾動條時卡頓、慢
方案：body{ -webkit-overflow-scrolling:touch;overflow-scrolling:touch; }
6、安卓不會自動播放視頻
安卓手機(jī)的autoplay沒有生效，需要手動觸發(fā)一下
方案：window.addEventListener('touchstart',()=>{ audio.play(); },false)
7、半透明的遮罩層改為全透明
在iOS上，當(dāng)點(diǎn)擊一個鏈接或者通過js綁定了點(diǎn)擊事件的元素時，會出現(xiàn)一個半透明的背景，當(dāng)手指離開屏幕，灰色背景消失，出現(xiàn)“閃屏”
方案：html,body{ -webkit-tap-highlight-color:rgba(0,0,0,0); }
8、ios系統(tǒng)全屏狀態(tài)下瀏覽器上下滾動時會出現(xiàn)底色問題
移動端項(xiàng)目要求是全屏滾動，用的是 fullpage，上下滾動時安卓正常，蘋果手機(jī)瀏覽器上下滾動時會出現(xiàn)底色問題
方案：document.body.addEventListener('touchmove',function(e) { e.preventDefault();}, {passive:false})。
個功能也是很常見了，一般都是為了方便用戶操作，比如復(fù)制訂單編號。不廢話，下面就來看看具體是怎么操作的。
tv_order_copy.setOnClickListener {
//獲取剪切板管理器
val cm: ClipboardManager = context.getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager
//設(shè)置內(nèi)容到剪切板
cm.primaryClip = ClipData.newPlainText(null, item.orderId)
ToastUtils.show(context, "已復(fù)制")
}
非常簡單，首先獲取剪切板管理器，然后設(shè)置內(nèi)容即可可以設(shè)置的內(nèi)容有3種類型：
tv_order_clear.setOnClickListener {
val cm: ClipboardManager = context.getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
//要api28以上
cm.clearPrimaryClip()
} else {
cm.primaryClip = ClipData.newPlainText(null, null)
}
}
在api等級28以上，直接調(diào)用clearPrimaryClip()即可，以下，重新設(shè)置為空即可。
iv_order_get.setOnClickListener {
val cm: ClipboardManager = context.getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager
if (cm.hasPrimaryClip() && cm.primaryClip != null) {
//cm.primaryClip.itemCount
val text = cm.primaryClip.getItemAt(0).text
ToastUtils.show(context, text.toString())
}
}
在有內(nèi)容的情況下，這里的代碼是取的第一個，即getItemAt(0).text，如果有多個的情況下，且有取多個的需求，這里的下標(biāo)取值就要根據(jù)cm.primaryClip.itemCount來動態(tài)設(shè)置了。
代在進(jìn)步，第三套少兒廣播體操！不好意思，搞錯頻道了，重來！時代在進(jìn)步，Android的版本也是快速的進(jìn)行著迭代著，從我們以前最常見的Android 4.4一直發(fā)展到了今天的Android 11版本(即Android K到Android R)，Android版本的快速迭代對于消費(fèi)者來說是一件普天同慶的大好事情，但是對于我們開發(fā)者來說各種適配各種改造有時候吃翔的心情都有了。而對于Android版本的適配和各種改造的第一步就是從編譯Android源碼開始，可是不幸的是隨著Android版本的迭代連編譯Android源碼的相關(guān)流程都發(fā)生了翻天覆地的變化，正所謂工欲利其事必先利器，所以我們今天的這篇博客將帶領(lǐng)讀者一起來到Android各個版本的源碼編譯發(fā)展和編譯具體操作步驟！
這里我們需要注意一下Android各個版本的對應(yīng)關(guān)系如下:
Android 5.x (Lollipop)簡稱Android L版本Android 6.0 (MarshMallow) 簡稱Android M版本Android 7.x (Nougat)簡稱Android N版本Android 8.x (Oreo)簡稱Android O版本Android 9.0 (Pie)簡稱Android P版本Android 10.0 (Q)簡稱Android Q版本Android 11.0 （R)簡稱Android R版本
并且這里還有一點(diǎn)需要特別注意，本文演示的Android R版本是以高通平臺為基準(zhǔn)進(jìn)行的。
??俗話說天時地利人和缺一不可，而這其中的地利翻譯過來說的就是環(huán)境因素了，人的成長離不開環(huán)境因素，而我們的Android編譯也離不開編譯環(huán)境的構(gòu)建！雖然我們本篇博客的主題是Android源碼編譯指南，但是我們還是有必要抽出一個章節(jié)來簡單說明下Android編譯環(huán)境的構(gòu)建和初始化過程，以及初始化完畢后常見的命令。
本章節(jié)重點(diǎn)偏向的是Android編譯環(huán)境的構(gòu)建，而不是編譯環(huán)境構(gòu)建的原理分析(如果是原理分析，那內(nèi)容就多了,關(guān)于Android編譯墻裂推薦一篇博客來自IBM社區(qū)理解 Android Build 系統(tǒng)，你值得擁有！)。
雖然Android的版本一直在迭代著，但是Android編譯環(huán)境的構(gòu)建步驟還是比較良心的依然沒有多大的變化(注意這里的措辭，只是步驟)，對于有過Android源碼開發(fā)經(jīng)驗(yàn)的讀者來說是再為熟悉不過的了，通常是如下二部曲:
$ source build/envsetup.sh
$ lunch aosp-eng
12雖然各位對上述的命令應(yīng)該已經(jīng)爛熟于心了，但是這里我還是簡單說明一下:
這里補(bǔ)充一點(diǎn)對Android的源碼編譯類型簡單說明一下，它可以分為如下三種功能，每種類型的特點(diǎn)如下:
在編譯環(huán)境初始化完成后，我們就可以使用各種各種編譯環(huán)境提供的指令和make編譯命令族來開啟Android的構(gòu)建之旅了，這里我簡單的總結(jié)了下，我們在Android編譯中可能會用到的編譯環(huán)境提供的指令和make編譯命令族，如下:
指令說明??croot ??切到Android源碼樹的根目錄(當(dāng)你深入Android源碼樹的子目錄，想回到根目錄的時候此命令就非常實(shí)用了)m相當(dāng)于在源碼樹的根目錄執(zhí)行make，并且該命令不一定要在根目錄下執(zhí)行mm編譯當(dāng)前目錄路徑下的所有模塊(包括include進(jìn)來的，但是不包括存在依賴關(guān)系模塊)mma編譯當(dāng)前目錄路徑下的所有模塊(包括include進(jìn)來的，且包括存在依賴關(guān)系模塊)mmm[module_path]編譯指定目錄路徑下的所有模塊(包括include進(jìn)來的，但是不包括存在存在依賴關(guān)系模塊)mmma[module_path]編譯指定目錄路徑下的所有模塊(包括include進(jìn)來的，包括存在存在依賴關(guān)系模塊)cgrep對C/C++文件執(zhí)行g(shù)rep(即grep的時候只搜尋C/C++文件類型，注意這里也包括.h文件類型)jgrep對Java文件執(zhí)行g(shù)rep(即grep的時候只搜尋Java文件類型)resgrep在所有res/.xml文件上執(zhí)行 grep即grep的時候只搜尋res/.xml文件類型)printconfig顯示當(dāng)前Android編譯的相關(guān)配置信息add_lunch_combo在lunch命令的的菜單中添加一個條目
這里我們對上述表格中的"不包括存在依賴關(guān)系的模塊"簡單解釋一下:
1.依賴關(guān)系模塊這個要怎么說呢，這里我們舉個例子！譬如模塊A的編譯需要依賴模塊B，此時的B是一個so庫。
2.假如我們通過mm或者mmm編譯模塊A的時候，此時B模塊還沒有編譯那么此時就會報(bào)錯
3.假如我們使用的是mma或者mmma編譯模塊A，假如依賴的模塊B還沒有編譯，那么會先將模塊B編譯OK，然后編譯模塊A(當(dāng)然這里只是舉栗子，可能A還依賴C,D同理也會先編譯)
Android的Build編譯系統(tǒng)處理常見的make單命令之外，還提供了其它的一系列make命令族，這里我們簡單過下:
指令說明make update-api更新API文件，在framework API改動之后，需要首先執(zhí)行該命令來更新API，公開的API記錄在frameworks/base/api目錄下makeAndroid默認(rèn)系統(tǒng)編譯指令，會編譯出整個系統(tǒng)的所有鏡像(其實(shí)質(zhì)最終執(zhí)行的是make droid)make droid同上make sdk編譯出Android的SDK開發(fā)套件make clean-sdk清理SDK的編譯產(chǎn)物make dist執(zhí)行整個編譯，并將 MAKECMDGOALS變量定義的輸出文件拷貝到 /out/dist目錄下，
這個命令在實(shí)際中用的比較少make all編譯所有內(nèi)容，不管當(dāng)前產(chǎn)品的定義中是否會包含,官方解釋如下:
builds everything make droid does,plus everything whose LOCAL_MODULE_TAGS do not include the “droid” tag. The build server runs this to make sure that everything that is in the tree and has an Android.mk builds.make help幫助信息命令，顯示當(dāng)前Android版本主要支持的make命令make snod從已經(jīng)編譯出的包快速構(gòu)建系統(tǒng)鏡像(譬如你重新單獨(dú)編譯了某個模塊，然后想快速進(jìn)行打包到system.img，可以使用此命令加快速度)make clean-$(LOCAL_MODULE)Let you selectively clean one target. For example, you can type make clean-libutils and t will delete libutils.so and all of the intermediate files.
即清理掉一個指定模塊的編譯結(jié)果和中間產(chǎn)物make clean-$(LOCAL_PACKAGE_NAME)Let you selectively clean one target. For example, you can type
make clean-Home and it will clean just the Home app…
即清理掉一個指定模塊的編譯結(jié)果和中間產(chǎn)物make cleandeletes all of the output and intermediate files for this configuration. This is the same as rm -rf out/<configuration>/
通常刪除的是整個Android源碼工程的out/*目錄make clobberdeletes all of the output and intermediate files for all configurations. This is the same as rm -rf out/.
這個命令在實(shí)際中，應(yīng)用得比較少make datacleandeletes contents of the data directory inside the current combo
directory. This is especially useful on the simulator and emulator, where the persistent data remains present between builds.
這個命令在實(shí)際中應(yīng)用得也比價少make installclean當(dāng)我們在執(zhí)行切換編譯目標(biāo)時可以執(zhí)行make installclean，用以清除之前編譯生成的文件，但是又不會將整個out目錄清空，這樣可以加快編譯目標(biāo)的構(gòu)建速度make LOCAL_MODULE編譯一個指定的模塊，LOCAL_MODULE 為模塊的名稱，這種編譯方法通常運(yùn)用在整個Android工程沒有構(gòu)建，但是想快速編譯一個模塊時可以使用，可以加快單個模塊構(gòu)建速度make targetswill print a list of all of the LOCAL_MODULE names you can make.make libandroid_runtime編譯所有JNI framework內(nèi)容。make framework編譯所有Javaframework內(nèi)容(做Android framework開發(fā)的小伙們對這條命令應(yīng)該是再熟悉不過的了)。make services編譯系統(tǒng)服務(wù)和相關(guān)內(nèi)容make bootimage編譯生成boot.imgmake recoveryimage編譯生成recovey.imgmake cacheimage編譯生成cache.imgmake systemimage編譯生成system.imgmake vendorimage編譯生成vendor.imgmake superimage編譯生成superi.img
對上述的make命令有幾點(diǎn)需要注意:
1.可能在不同的Android版本有不同表現(xiàn)，且有的可能已經(jīng)不支持了
2.讀者最好對于每個make編譯命令，自行使用一番，然后慢慢品嘗
??有過一定Android開發(fā)經(jīng)驗(yàn)的讀者應(yīng)該知道Android最初是用Android.mk配置來編譯源碼的(這里的Android.mk本質(zhì)上有點(diǎn)類似Makefile文件)。但是隨著Android版本的迭代，源碼工程文件越來越大，包含的模塊越來越多，而以Android.mk組織的項(xiàng)目編譯花費(fèi)的時間越來越多。面對這個嚴(yán)峻的問題，Android的媽咪谷歌終于在在Android7.0開始引入了ninja編譯系統(tǒng)。相對于make來說ninja在大的項(xiàng)目管理中速度和并行方面有突出的優(yōu)勢，因此Google采用了ninja來取代之前使用的make。由于Android.mk的數(shù)量巨大且復(fù)雜，不可能把所有的Android.mk改寫成ninja的構(gòu)建規(guī)則，因此Google搞了個kati工具，用于將Androd.mk轉(zhuǎn)換成ninja的構(gòu)建規(guī)則文件build.ninja，再使用ninja來進(jìn)行構(gòu)建工作。
??Android編譯的發(fā)展依然沒有停止進(jìn)化，果不其然Android8.0開始，Google引入了Android.bp文件來替代之前的Android.mk文件，Android.bp只是純粹的配置文件，不包括分支、循環(huán)等流程控制，本質(zhì)上就是一個json配置文件。同時還引入Soong這個工具，用于將Android.bp轉(zhuǎn)換為ninja的構(gòu)建規(guī)則文件build.ninja，再使用ninja來進(jìn)行構(gòu)建工作。但之前的模塊全部是用Android.mk來定義的，google不可能一下子把所有模塊都修改成Android.bp，只能逐步替換。無論是Android.mk還是Android.bp最后都是轉(zhuǎn)化成ninja的構(gòu)建規(guī)則，再進(jìn)行編譯的。
如果你對上述的概述，還是覺得太啰嗦了，沒有關(guān)系。這里我們用更加簡單的文字來整體來概括一下Android build系統(tǒng)隨著Android版本相應(yīng)的發(fā)展演變過程:
通過前面的章節(jié)，我們簡單介紹了Android編譯系統(tǒng)的發(fā)展史！讀者會發(fā)現(xiàn)，其中突然一下子冒出了許多的概念，這里我們先暫且不對其中涉及的概念深入了解，我們先說說上述幾個概念Soong、Blueprint、Kati、Ninja之間的關(guān)系，它們之間的關(guān)系圖如下:
上圖是一個靜態(tài)的整體的關(guān)系圖，但是在Android源碼工程構(gòu)建過程中的它們之間可以使用如下的轉(zhuǎn)換關(guān)系圖來表示:
關(guān)系圖已經(jīng)給各位看官擺出來了，那么它們之間的轉(zhuǎn)換關(guān)系是怎么來的呢，這里我們來說說:
不容易啊，這里我們對涉及到Ninja, kati, Soong, bp關(guān)系搞清楚了(各種三角戀)！那么關(guān)于它們的概念，接下來我們也得簡單介紹介紹，安排上才行！
Kati是專為Android開發(fā)的一個基于Golang和C++的工具，主要功能是把Android中的Android.mk文件轉(zhuǎn)換成 Ninja文件。代碼路徑是build/kati，編譯后的產(chǎn)物是ckati。
Kati代碼是開源的，可以把它c(diǎn)lone下來，如果感興趣可以查看下其實(shí)現(xiàn)原理
這里我們構(gòu)建一個通過Android.mk配置的LOCAL_MODULE模塊，然后通過top命令就可以查看在編譯的過程中執(zhí)行了ckati的命令。
ninja是一個編譯框架，會根據(jù)相應(yīng)的ninja格式的配置文件進(jìn)行編譯，但是ninja文件一般不會手動修改，而是通過將Android.bp文件轉(zhuǎn)換成ninja格文件來編譯。
Android.bp的出現(xiàn)就是為了替換Android.mk文件。而bp跟mk文件不同，它是純粹的配置，沒有分支、循環(huán)等流程控制，不能做算數(shù)邏輯運(yùn)算。如果需要控制邏輯，那么只能通過Go語言編寫。Android的媽咪谷歌為了讓開發(fā)者能更加的快速掌握Android.bp特意提供了androidmk命令(關(guān)于它的詳細(xì)介紹可以參見博客Android.bp入門指南之Android.mk轉(zhuǎn)換成Android.bp，這里就不過多的戲說了)用于Android.mk轉(zhuǎn)換成Android.bp使用，如下轉(zhuǎn)換命令:
$ androidmk Android.mk > Android.bp
1Soong類似于之前的Makefile編譯系統(tǒng)的核心，負(fù)責(zé)提供Android.bp語義解析，并將之轉(zhuǎn)換成Ninja文件。Soong還會編譯生成一個androidmk命令，用于將Android.mk文件轉(zhuǎn)換為Android.bp文件，不過這個轉(zhuǎn)換功能僅限于沒有分支、循環(huán)等流程控制的Android.mk才有效。
Blueprint是生成、解析Android.bp的工具，是Soong的一部分。Soong負(fù)責(zé)Android編譯而設(shè)計(jì)的工具，而Blueprint只是解析文件格式，Soong解析內(nèi)容的具體含義。Blueprint和Soong都是由Golang寫的項(xiàng)目，從Android 7.0，prebuilts/go/目錄下新增Golang所需的運(yùn)行環(huán)境，在編譯時使用。并且因?yàn)镾oong和Blueprint是Google谷歌為Android.bp特別定制的工具，所以不需要要摘出來單獨(dú)來操作。
??通過前面的章節(jié)我們了解了Android編譯環(huán)境的構(gòu)建和編譯的發(fā)展史(前面的章節(jié)都是為了后面章節(jié)服務(wù)做的整體鋪墊)，那么從本章節(jié)開始就要契合本篇博客的主題了將重點(diǎn)分析Android O之后高階版本的編譯的不同之處了。在本篇的博客開始就有說到過是以高通版本的Android R為基線來進(jìn)行分析的。所以在開始本章節(jié)的博客前，有兩個知識點(diǎn)需要提前介紹下，一個是Android Q以及之后的動態(tài)分區(qū)概念，另外一個就是高通Q之后引入的QSSI(或者qssi)的概念！
動態(tài)分區(qū)是Android的用戶空間分區(qū)系統(tǒng)。使用此分區(qū)系統(tǒng)，您可以在無線下載(OTA)更新期間創(chuàng)建、銷毀分區(qū)或者調(diào)整分區(qū)大小。借助動態(tài)分區(qū)，供應(yīng)商無需擔(dān)心各個分區(qū)（例如system、vendor和product）的大小。取而代之的是，設(shè)備分配一個super分區(qū)，其中的子分區(qū)可動態(tài)地調(diào)整大小。單個分區(qū)映像不再需要為將來的OTA預(yù)留空間。相反，super中剩余的可用空間還可用于所有動態(tài)分區(qū)(關(guān)于動態(tài)分區(qū)詳見谷歌官方Android實(shí)現(xiàn)動態(tài)分區(qū))。
QSSI 是 Qualcomm Single System Image 的縮寫，并且高通平臺從Android Q開始支持。高通的官方文檔對此的解釋是引入QSSI的概念是為了解決Android碎片化問題，把system.img和vendor.img進(jìn)一步拆分。
并且其編譯也和Android原生編譯有差別，其差別如下:
高版本Android非QSSI特性的編譯流程,依然和以前的版本Android編譯變化不大，通常是如下的步驟(這個也是讀者最為熟悉的了):
source build/envsetup.sh
lunch xx-userdebug
make
123這里需要注意的的是通用版本的Android還是可以直接通過make相關(guān)的分區(qū)進(jìn)行直接編譯的，譬如make superimage或者直接執(zhí)行make編譯
通過前面看到QSSI特性的固件編譯流程也和通用版本的有一定的區(qū)別，這里的編譯分為兩種模式，第一種Android的標(biāo)準(zhǔn)編譯模式，另外一種就是高通提供的編譯腳本。
source build/envsetup.sh
1lunch qssi-userdebug
make target-files-package
12lunch xx-userdebug
make target-files-package
12source build/envsetup.sh
lunch XX-userdebug
./build.sh dist -j32
123source build/envsetup.sh
lunch xx-userdebug
./build.sh dist qssi_only -j32
123source build/envsetup.sh
lunch xx-userdebug
./build.sh dist merge_only -j32
123source build/envsetup.sh
lunch xx-userdebug
./build.sh vendorimage dist target_only -j32
1234由于Android Q版本以及以上將system和vendor分區(qū)合并為super分區(qū)，無法通過adb reboot bootloader模式單獨(dú)刷動態(tài)分區(qū)里面的img，例如system,vendor,product,odm等鏡像，只能刷super.img和其他的分區(qū)，但是super.img分區(qū)動輒幾個G的大小，每次刷機(jī)幾乎都要等上個好大幾分鐘，這個酸爽你懂的。
這里有一點(diǎn)需要注意并不是說真的在bootloader模式下不能刷入system分區(qū)鏡像，可以看到下面的截圖是可以刷入的，但是只是鏡像沒有真的燒錄生效，所以讀者在實(shí)際開發(fā)中一定不要做無用功，否則一直燒錄，會發(fā)現(xiàn)咋咋我修改的東西沒有生效呢！
那有沒有方法單刷呢，當(dāng)然有了，不然我也不會多提一句不是。我們可以在fastboot模式下可以單獨(dú)刷動態(tài)分區(qū)里面的img，其方法如下:
#推薦進(jìn)入fastboot模式刷機(jī):
adb reboot fastboot
fastboot getvar is-userspace
is-userspace: yes
Finished. Total time: 0.002s
fastboot flash vendor vendor.img
fastboot flash system system.img
fastboot flash vbmeta vbmeta.img
fastboot flash vbmeta_system vbmeta_system.img
#fastbootd是用戶空間的代碼，因?yàn)閯討B(tài)的邏輯分區(qū)只能在應(yīng)用空間識別
123456789101.如果是在linux下fastboot刷機(jī)出現(xiàn)權(quán)限問題，需要將fastboot的所有者屬性改成root
sudo chown root:root fastboot
sudo chmod +s fastboot
2.如果是在windows環(huán)境下使用fastboot，很大概率可能不識別fastboot，此時推薦下載360的手機(jī)助手借助它安裝對應(yīng)的驅(qū)動，這樣就能進(jìn)行相關(guān)的識別了，此處是個人經(jīng)驗(yàn)
3.并且我們在實(shí)際操作中需要，注意fastboot是否處于鎖定模式，否則會報(bào)一下錯誤(我調(diào)試的終端，已經(jīng)強(qiáng)制鎖定了,所以那怕我強(qiáng)制執(zhí)行了解鎖也一直報(bào)remote: 'Command not available on locked devices’的異常)
4.我們來使用一個可以動態(tài)解鎖的fastboot，大功告成！
對于從事Android偏向現(xiàn)Framework開發(fā)的讀者來說，編譯Android的Framework層是再常見不過的操作了，在Android R之上的Framework的編譯已經(jīng)和之前有所不同，具體參見下面解釋:
make -j8 framework
make -j8 services
12make -j8 framework-minus-apex
make -j8 services
12??對于Android開發(fā)者來說，當(dāng)然希望自己在服務(wù)器上分配到的資源越多越好，特別是固態(tài)硬盤的容量，但是公司當(dāng)開發(fā)者過多的時候，公司就會盡量壓縮ssd固態(tài)硬盤的盤符空間，只給分配了250G的固態(tài)硬盤容量，如果是同時開發(fā)編譯幾個Android低版本的源碼，那肯定是夠了，但是切到Android R之后，250G肯定是遠(yuǎn)遠(yuǎn)不夠的，這里我們通過du命令查看一下Android R編譯出來之后的情況，如下:
ityuan@pd:~/ssd$ du -sh *
260G qcm2290
ityuan@pd:~/ssd$
ityuan@pd:~/ssd$ ls
qcm2290
ityuan@pd:~/ssd$ cd qcm2290/
ityuan@pd:~/ssd/qcm2290$ du -sh *
8.0K about.html
0 Android.bp
85M art
64M bionic
218M bootable
0 bootstrap.bash
24M build
0 build.sh
3.4M compatibility
1.7G cts
26M dalvik
222M developers
150M development
635M device
4.0K disregard
7.1G external
1.9G frameworks
81M hardware
1.4G kernel
87M libcore
420K libnativehelper
4.0K Makefile
186G out
1.1G packages
3.4G xxxdroid
896K pdk
16M platform_testing
32G prebuilts
12K product
4.0K readme.md
232K resources.arsc
30M sdk
444K shortcut-fe
8.0K sync.sh
704M system
408M test
16K TEST_BP
9.7M toolchain
704M tools
6.9G vendor
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849這里可以看到一個Android R的源碼工程就將整個的ssd硬盤空間占滿了，那么有什么辦法精簡呢。當(dāng)然有了，我們可以對Android 的out目錄進(jìn)行軟連接，鏈接到其它的分區(qū)之中。說干就干！下面我來記錄一下具體的步驟:
ityuan@pd:~$ mkdir out
ityuan@pd:~$ ls out/
ityuan@pd:~$
123ityuan@pd:~$ ln -s /home/tangkw/out /home/tangkw/ssd/qcm2290/out
ityuan@pd:~$ cd ssd/qcm2290/
ityuan@pd:~/ssd/qcm2290$ ll out
lrwxrwxrwx 1 tangkw pd 16 Jan 5 16:54 out -> /home/tangkw/out/
ityuan@pd:~/ssd/qcm2290$
12345并且在創(chuàng)建軟鏈接中強(qiáng)烈建議使用絕對路徑，否則會提示Too many levels of symbolic links的錯誤
ityuan@pd:~$ cd out/
ityuan@pd:~/out$ ls -l
total 12684
-rw-r--r-- 1 ityuan pd 0 Jan 5 16:56 Android.mk
-rw-r--r-- 1 ityuan pd 160 Jan 5 16:59 build-bengal-cleanspec.ninja
-rwxr-xr-x 1 ityuan pd 10 Jan 5 16:56 build_date.txt
-rw-r--r-- 1 ityuan pd 10 Jan 5 16:56 build.trace.gz
-rwxr-xr-x 1 ityuan pd 1 Jan 5 16:56 casecheck.txt
-rwxr-xr-x 1 ityuan pd 1 Jan 5 16:56 CaseCheck.txt
-rw-r--r-- 1 ityuan pd 0 Jan 5 16:56 CleanSpec.mk
drwxr-xr-x 2 ityuan pd 4096 Jan 5 16:59 empty
-rw-r--r-- 1 ityuan pd 39 Jan 5 16:59 env-bengal-cleanspec.sh
-rw-r--r-- 1 ityuan pd 0 Jan 5 16:56 error.log
drwxr-xr-x 3 ityuan pd 4096 Jan 5 17:00 host
-rwxr-xr-x 1 ityuan pd 4309565 Jan 5 16:56 microfactory_Linux
-rwxr-xr-x 1 ityuan pd 121 Jan 5 16:59 ninja-bengal-cleanspec.sh
-rw-r--r-- 1 ityuan pd 0 Jan 5 16:56 ninja_build
drwxr-xr-x 6 ityuan pd 4096 Jan 5 16:59 soong
-rw-r--r-- 1 ityuan pd 19743 Jan 5 17:00 soong.log
-rwxr-xr-x 1 ityuan pd 8580360 Jan 5 16:56 soong_ui
drwxr-xr-x 3 ityuan pd 4096 Jan 5 16:59 target
-rw-r--r-- 1 ityuan pd 24970 Jan 5 17:00 verbose.log.gz
ityuan@pd:~/out$
1234567891011121314151617181920212223ityuan@pd:~/ssd$ du -sh *
75G qcm2290
ityuan@pd:~/ssd$ cd qcm2290/
ityuan@pd:~/ssd/qcm2290$
ityuan@pd:~/ssd/qcm2290$
ityuan@pd:~/ssd/qcm2290$ du -sh *
8.0K about.html
0 Android.bp
85M art
64M bionic
218M bootable
0 bootstrap.bash
24M build
0 build.sh
3.4M compatibility
1.7G cts
26M dalvik
222M developers
150M development
635M device
4.0K disregard
7.1G external
1.9G frameworks
81M hardware
1.4G kernel
87M libcore
420K libnativehelper
4.0K Makefile
0 out
1.1G packages
3.4G xxxdroid
896K pdk
16M platform_testing
32G prebuilts
12K product
4.0K readme.md
232K resources.arsc
30M sdk
444K shortcut-fe
8.0K sync.sh
704M system
408M test
16K TEST_BP
9.7M toolchain
704M tools
6.9G vendor
ityuan@pd:~/ssd/qcm2290$
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647大功告成，當(dāng)然如果讀者是土豪公司，那這個就可以跳過不看了。
??在前面我們簡單說了下動態(tài)分區(qū)的概念，即在Android Q以及以后得編譯包中，我們找不到了對應(yīng)的system,vendor等img文件，但是多了一個super.img，system，vendor，product，ODM合并為super分區(qū)，這個就是動態(tài)分區(qū)了。簡單來說就是為了在ota的時候能夠靈活創(chuàng)建分區(qū)和修改分區(qū)大小，將system,vendor,odm,product合并成super分區(qū)，并在super分區(qū)上預(yù)留出一定量的free space，這樣就可以動態(tài)調(diào)整這些分區(qū)的大小，解決了ota的時候分區(qū)不足，以及調(diào)整分區(qū)的風(fēng)險(xiǎn).。
當(dāng)OTA升級之后，需要重新調(diào)整分區(qū)大小：
碼字不易，覺得對你有幫助的話記得收藏順便小編點(diǎn)個贊哦 ^_^
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
