鍍金池/ 教程/ Android/ 已知的問(wèn)題
下載源碼
根據設備構建
Git 資源
構建系統
Android 平臺 64 位構建指導
初始化編譯環(huán)境
Android 源代碼
品牌指南
已知的問(wèn)題
Repo 命令手冊
構建內核
Bug 的生命周期
代碼主線(xiàn)、分支和版本
使用 Eclipse
提交補丁
下載與構建
參與
項目角色
補丁的生命周期
提交 Bugs
關(guān)于代碼風(fēng)格的指導
開(kāi)發(fā)
代碼名稱(chēng),標簽和版本號

已知的問(wèn)題

即使是在我們最好的照看下,也會(huì )偶爾出現小的問(wèn)題。這篇文章會(huì )持續追蹤在使用 Android 源碼的過(guò)程中出現的問(wèn)題。

構建問(wèn)題

在 toro 構建中丟失 CellBroadcastReceiver

癥狀

在 AOSP 給 toro 的構建中(Jelly Bean 4.2.1 之后的版本),CellBroadcastReceiver 并不會(huì )包括在系統中。

原因:

vendor/samsung/toro/device-partial.mk 中的 PRODUCT_PACKAGES 有一個(gè)排版錯誤:有一個(gè) H 替代了 K。

修復:

使用 4.2.2 的最后一個(gè)版本包,或者手工的修改排版。

丟失 CTS 原生 XML 生成器

癥狀:

在有些 IceCreamSandwich 或之后的版本構造中,在構造中會(huì )先打印下面的警告:
/bin/bash: line 0: cd: cts/tools/cts-native-xml-generator/src/res: No such file or directory

原因:

有些 makefile 依賴(lài)的路徑并不存在。

修復:

無(wú)。這是一個(gè)無(wú)害的警告。

Black Gingerbread 模擬器

癥狀:

這個(gè)模擬器直接由 gingerbread 分支構造而且沒(méi)有啟動(dòng),一直卡死在綠屏狀態(tài)下。

原因:

gringerbread 分支使用的是 R7 版本的模擬器,該模擬器并沒(méi)有所有必要的特征來(lái)運行最近版本的 gingerbread。

修復:

使用 R12 版本的模擬器,以及一個(gè)新的匹配工具的核心。不需要清理 build。

$ repo forall platform/external/qemu -c git checkout aosp/tools_r12
$ make
$ emulator -kernel prebuilt/android-arm/kernel/kernel-qemu-armv7

構建在 MacOS 10.7 Lion 上的模擬器不工作

癥狀:

構建在 MacOS 10.7 Lion 或者 XCode 4.x 上的模擬器(任何版本)不工作。

原因:

一些在開(kāi)發(fā)環(huán)境的更改導致了模擬器不能從工作環(huán)境中編譯。

修復:

使用一個(gè) SDK 中的二進(jìn)制文件,該文件可以構建在用 XCode 6 的 MacOS 10.6 上,并且可以在 MacOS 10.7 上工作。

WITH_DEXPREOPT=true 以及模擬器構建。

癥狀:

在模擬器的構建中,當部分行為的構建以及同步(使系統沒(méi)有依賴(lài))時(shí),結果構建沒(méi)有生效。

原因:

默認情況下,現在所有模擬器構建都會(huì )進(jìn)行 Dex 優(yōu)化,這就會(huì )導致每次框架改變都會(huì )請求跟隨所有的依賴(lài),用來(lái)重新優(yōu)化應用。

修復:

export WITH_DEXPREOPT=false 使本地的 Dex 優(yōu)化失效,用 make installclean 刪除已經(jīng)存在的優(yōu)化版本,然后運行一個(gè)完整的構造,重新生成沒(méi)有優(yōu)化的版本。在進(jìn)行完上述操作之后,部分的構造將會(huì )開(kāi)始工作。

構造過(guò)程中出現 Permission Denied

癥狀:

所有的構建失敗都伴隨著(zhù) Permission Denied,可能伴隨著(zhù)反病毒警告。

原因:

有些反病毒程序會(huì )將一些 Android 源碼樹(shù)中的文件錯誤的識別成包含病毒。

修復:

經(jīng)過(guò)確認沒(méi)有病毒存在后,讓反病毒程序在 Android 源碼樹(shù)中失效。這樣做對減少構建次數有好處。

構建錯誤與使用錯誤的編譯器

特征:

構建錯誤有許多的特征。其中一個(gè)特征是: cc1: error: unrecognized command line option "-m32”

原因:

在 PATH 中 Android 構建系統使用的是默認的編譯器,假設在 host 中有合適的編譯器生成的二進(jìn)制文件。其他情況(比如使用 Android NDK 或者構建內核)將會(huì )導致默認的編譯器不是主編譯器。

修復:

使用 “clean” 腳本,確保沒(méi)有別的操作會(huì )更改默認的編譯器。

由于無(wú)默認工具設置導致的構造錯誤

特征:

構造失敗有很多特征,可能是由于文件丟失或者文件格式錯誤。其中一個(gè)的特征是 member [...] in archive is not an object。

原因:

Android 構建系統往往使用很多 host 工具并依賴(lài)于他們默認的行為。有些設置更改了工具的行為并使他們的行為干擾到了系統構建。已知會(huì )導致問(wèn)題的變量是 CDPATHGREP_OPTIONS。

修復:

在盡可能少的自定義環(huán)境中構建 Android。

在 MacOS 10.7 上構建 4.0.x 以及之前版本的錯誤

特征:

在 MacOS 10.7 上構建 IceCreamSandwich 4.0.x(和更老的版本)失敗,并提示下面的錯誤信息: Undefined symbols for architecture i386: "_SDL_Init”

原因:

在 MacOS 10.7 上不能適配 4.0.x

修復:

降級電腦系統到 MacOS 10.6 或者是在 MacOS 10.7 上構造當前版本。

$ repo init -b master
$ repo sync

在 MacOS 上用 XCode 4.3 的構建錯誤

特征:

當使用 XCode 4.3 時(shí)所有的構造都失敗

原因:

XCode 4.3 的默認編譯器從 gcc 改成了 llvm,而 llvm 拒絕過(guò)去可以在 gcc 上通過(guò)的代碼。

修復:

使用 XCode 4.2。

在 Ubuntu 11.10 上構造 4.0.x 或更早版本的錯誤

特征:

在 Ubuntu 11.10 或之后的版本中構建 IceCreamSandwich 4.0.x(或者其之前的版本)會(huì )出現類(lèi)似 <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default] 的錯誤。

原因:

Ubuntu 11.10 使用 gcc 標記是默認的,而 Android 也會(huì )定義一個(gè)默認的標記,這樣導致了沖突。

修復:

可以選擇降級到 Ubuntu 10.04 或者使用當前分支,這樣就可以在 Ubuntu 11.10 或者之后的版本中使用。

$ repo init -b master
$ repo sync

源文件同步問(wèn)題

復雜同步源代碼(代理問(wèn)題)

特征:

在 http 錯誤的時(shí)候 repo 或者是 repo sync 失敗,通常是 403 或者是 500。

原因

有很多引起錯誤的原因,其中最常見(jiàn)的是關(guān)聯(lián)到了 http 代理,這是傳輸大數據的時(shí)候比較困難。

修復:

暫時(shí)還沒(méi)有通用解決方法,使用 python 2.7 以及明確的使用 repo sync -jl 來(lái)改善一些用戶(hù)的使用情況。

復雜同步源代碼(VituralBox 以太網(wǎng)問(wèn)題)

特征:

當在一些 VituralBox 安裝中運行 repo sync,進(jìn)程伴隨著(zhù)可能的特征掛起或者失敗。其中一種特征是:DownloadError: HTTP 500 (Internal Server Error: Server got itself in trouble)。

原因:

默認的 VirualBox 的網(wǎng)絡(luò )行為是使用 NAT(Network Addrss Translation)連接客戶(hù)系統來(lái)連接網(wǎng)絡(luò )。繁重的網(wǎng)絡(luò )行為將會(huì )引發(fā) NAT 中的某些代碼。

修復:

配置 VirtualBox 讓其使用橋連接來(lái)代替 NAT。

復雜同步源代碼(NDS 問(wèn)題)

特征:

當運行 repo sync 時(shí),由于無(wú)法識別 hostname 伴隨著(zhù)一些錯誤導致進(jìn)程失敗。其中一個(gè)錯誤是: <urlopen error [Errno -2] Name or service not known>。

原因:

有些 DNS 系統在應對大數量的請求時(shí)需要同步源碼樹(shù)而導致運行緩慢(在最壞的假設情況下可能有好幾百請求)

修復:

手工移除相關(guān)的 hostname,并在本地硬編碼那些結果。

你可以用 nslookup 命令來(lái)移除,這可以給你一系列的數字 IP 地址(通常是在輸出中的 “Address” 部分)。

$ nslookup googlesource.com
$ nslookup android.googlesource.com

之后你可以在本地硬編碼他們到 /etc/hosts,再在這個(gè)文件中以下面的格式添加兩行:

aaa.bbb.ccc.ddd googlesource.com
eee.fff.ggg.hhh android.googlesource.com

需要注意的是這只在服務(wù)的地址沒(méi)有改變的情況下,所以如果他們更改了地址而你又無(wú)法連接,這時(shí)候你就要重新的獲取 hostname,相應的你還要更改 etc/hosts。

復雜同步源代碼(TCP 問(wèn)題)

特征:

在同步時(shí) repo sync 掛起,通常都是在已經(jīng)同步了 99% 的情況下。

原因:

在 TCP/IP 堆的設置會(huì )使一些網(wǎng)絡(luò )環(huán)境變的很糟糕,比如 repo sync 會(huì )既不編譯,也不失敗。

修復:

在 Linux 上執行 sysctl -w net.ipv4.tcp_window_scaling=0。在 MacOS 上,使 rfc 1323 擴展失效。

運行問(wèn)題

照相機和 GSP 在 Galaxy Nexus 上失效

特征:

照相機和 GSP 在 Galaxy Nexus 上失效。舉個(gè)例子,照相機應用一啟動(dòng)就崩潰。

原因:

在 Android 開(kāi)源項目中不提供這些硬件外設需要專(zhuān)有庫。

修復:

無(wú)。