android編譯命令的說(shuō)明

android源碼目錄下的build/envsetup.sh文件，描述編譯的命令

- m:?????? Makes from the top of the tree.

- mm:????? Builds all of the modules in the current directory.

- mmm:???? Builds all of the modules in the supplied directories.

要想使用這些命令，首先需要設(shè)置android腳本編譯環(huán)境，在源碼根目錄執(zhí)行 source build/envsetup.sh

m：編譯所有的模塊

mm：編譯當(dāng)前目錄下的模塊，當(dāng)前目錄下要有Android.mk文件

mmm：編譯指定路徑下的模塊，指定路徑下要有Android.mk文件

下面舉個(gè)例子說(shuō)明，假設(shè)我要編譯android下的\framework\av\cmds\screenrecord模塊，

當(dāng)前目錄為源碼根目錄，方法如下：

1、source build/envsetup.sh

2、mmm framework/av/cmds/screenrecord

或者 ：

1、source build/envsetup.sh

2、cd framework/av/cmds/screenrecord

3、mm

android:screenOrientation的說(shuō)明

?? ??? ?// android:screenOrientation="unspecified"

?? ??? ?// android:screenOrientation="landscape"

?? ??? ?// android:screenOrientation="portrait"

?? ??? ?// android:screenOrientation="user"

?? ??? ?// android:screenOrientation="behind"

?? ??? ?// android:screenOrientation="sensor"

?? ??? ?// android:screenOrientation="nosensor"

?? ??? ?// android:screenOrientation="sensorLandscape"

?? ??? ?// android:screenOrientation="sensorPortrait"

?? ??? ?// android:screenOrientation="reverseLandscape"

?? ??? ?// android:screenOrientation="reversePortrait"

?? ??? ?// android:screenOrientation="fullSensor"

## 第二種方式：在A(yíng)ctivity中設(shè)置或者通過(guò)mActivity = pActivity來(lái)設(shè)置，如果在本Activity中設(shè)置可使用##

?? ??? ?// 如：setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT)，這方法中省略了this；

?? ??? ?// 如果在其它地方，可以使用形如：mActivity.setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT)

?? ??? ?setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);

"unspecified"默認(rèn)值，由系統(tǒng)來(lái)選擇方向。它的使用策略，以及由于選擇時(shí)特定的上下文環(huán)境，可能會(huì)因?yàn)樵O(shè)備的差異而不同。

"user"使用用戶(hù)當(dāng)前首選的方向。

"behind"使用Activity堆棧中與該Activity之下的那個(gè)Activity的相同的方向。

"landscape"橫向顯示（寬度比高度要大）

"portrait"縱向顯示（高度比寬度要大）

"reverseLandscape"與正常的橫向方向相反顯示，在A(yíng)PI Level 9中被引入。

"reversePortrait"與正常的縱向方向相反顯示，在A(yíng)PI Level 9中被引入。

"sensorLandscape"橫向顯示，但是基于設(shè)備傳感器，既可以是按正常方向顯示，也可以反向顯示，在A(yíng)PI Level 9中被引入。

"sensorPortrait"縱向顯示，但是基于設(shè)備傳感器，既可以是按正常方向顯示，也可以反向顯示，在A(yíng)PI Level 9中被引入。

"sensor"顯示的方向是由設(shè)備的方向傳感器來(lái)決定的。顯示方向依賴(lài)與用戶(hù)怎樣持有設(shè)備；當(dāng)用戶(hù)旋轉(zhuǎn)設(shè)備時(shí)，顯示的方向會(huì)改變。但是，默認(rèn)情況下，有些設(shè)備不會(huì)在所有的四個(gè)方向上都旋轉(zhuǎn)，因此要允許在所有的四個(gè)方向上都能旋轉(zhuǎn)，就要使用fullSensor屬性值。

"fullSensor"顯示的方向（4個(gè)方向）是由設(shè)備的方向傳感器來(lái)決定的，除了它允許屏幕有4個(gè)顯示方向之外，其他與設(shè)置為“sensor”時(shí)情況類(lèi)似，不管什么樣的設(shè)備，通常都會(huì)這么做。例如，某些設(shè)備通常不使用縱向倒轉(zhuǎn)或橫向反轉(zhuǎn)，但是使用這個(gè)設(shè)置，還是會(huì)發(fā)生這樣的反轉(zhuǎn)。這個(gè)值在A(yíng)PI Level 9中引入。

"nosensor"屏幕的顯示方向不會(huì)參照物理方向傳感器。傳感器會(huì)被忽略，所以顯示不會(huì)因用戶(hù)移動(dòng)設(shè)備而旋轉(zhuǎn)。除了這個(gè)差別之外，系統(tǒng)會(huì)使用與“unspecified”設(shè)置相同的策略來(lái)旋轉(zhuǎn)屏幕的方向。

注意：在給這個(gè)屬性設(shè)置的值是“l(fā)andscape”或portrait的時(shí)候，要考慮硬件對(duì)Activity運(yùn)行的方向要求。正因如此，這些聲明的值能夠被諸如Google Play這樣的服務(wù)所過(guò)濾，以便應(yīng)用程序只能適用于那些支持Activity所要求的方向的設(shè)備。例如，如果聲明了“l(fā)andscape”、“reverseLandscape”、或“sensorLandscape”，那么應(yīng)用程序就只能適用于那些支持橫向顯示的設(shè)備。但是，還應(yīng)該使用uses-feature元素來(lái)明確的聲明應(yīng)用程序所有的屏幕方向是縱向的還是橫行的。例如：uses-feature android:name=”android.hardware.screen.portrait”/。這個(gè)設(shè)置由Google Play提供的純粹的過(guò)濾行為，并且在設(shè)備僅支持某個(gè)特定的方向時(shí)，平臺(tái)本身并不控制應(yīng)用程序是否能夠被按照。

Android 10（29）適配方案簡(jiǎn)要說(shuō)明

Android 10（29）適配方案簡(jiǎn)要說(shuō)明

1、根據(jù)Google官方文檔說(shuō)明，Android10引入了大量變更

官方文檔：

1.1、Android 10 中的隱私權(quán)變更

1.1.1重大隱私權(quán)變更

分區(qū)存儲(chǔ)

針對(duì)外部存儲(chǔ)的過(guò)濾視圖，可提供對(duì)特定于應(yīng)用的文件和媒體集合的訪(fǎng)問(wèn)權(quán)限 訪(fǎng)問(wèn)和共享外部存儲(chǔ)中的文件的應(yīng)用 使用特定于應(yīng)用的目錄和媒體集合目錄

增強(qiáng)了用戶(hù)對(duì)位置權(quán)限的控制力

僅限前臺(tái)權(quán)限，可讓用戶(hù)更好地控制應(yīng)用對(duì)設(shè)備位置信息的訪(fǎng)問(wèn)權(quán)限 在后臺(tái)時(shí)請(qǐng)求訪(fǎng)問(wèn)用戶(hù)位置信息的應(yīng)用 確保在沒(méi)有后臺(tái)位置信息更新的情況下優(yōu)雅降級(jí)

使用 Android 10 中引入的權(quán)限在后臺(tái)獲取位置信息

系統(tǒng)執(zhí)行后臺(tái) Activity

針對(duì)從后臺(tái)啟動(dòng) Activity 實(shí)施了限制 不需要用戶(hù)互動(dòng)就啟動(dòng) Activity 的應(yīng)用 使用通知觸發(fā)的 Activity

不可重置的硬件標(biāo)識(shí)符

針對(duì)訪(fǎng)問(wèn)設(shè)備序列號(hào)和 IMEI 實(shí)施了限制 訪(fǎng)問(wèn)設(shè)備序列號(hào)或 IMEI 的應(yīng)用 使用用戶(hù)可以重置的標(biāo)識(shí)符

無(wú)線(xiàn)掃描權(quán)限

訪(fǎng)問(wèn)某些 WLAN、WLAN 感知和藍(lán)牙掃描方法需要獲得精確位置權(quán)限 使用 WLAN API 和藍(lán)牙 API 的應(yīng)用 針對(duì)相關(guān)使用場(chǎng)景請(qǐng)求?ACCESS_FINE_LOCATION?權(quán)限

1.1.2更多隱私權(quán)變更

標(biāo)識(shí)符和數(shù)據(jù)： 針對(duì)硬件標(biāo)識(shí)符（如 IMEI、序列號(hào)、MAC 和類(lèi)似數(shù)據(jù)）實(shí)施了新限制。

?移除了聯(lián)系人親密程度信息

?隨機(jī)分配 MAC 地址

?對(duì) /proc/net 文件系統(tǒng)的訪(fǎng)問(wèn)權(quán)限實(shí)施了限制

?對(duì)不可重置的設(shè)備標(biāo)識(shí)符實(shí)施了限制

?限制了對(duì)剪貼板數(shù)據(jù)的訪(fǎng)問(wèn)權(quán)限

?保護(hù) USB 設(shè)備序列號(hào)

攝像頭和連接性： 針對(duì)攝像頭元數(shù)據(jù)和連接 API 提供了更強(qiáng)大的保護(hù)措施。 ?對(duì)訪(fǎng)問(wèn)攝像頭詳情和元數(shù)據(jù)的權(quán)限實(shí)施了限制

?對(duì)啟用和停用 WLAN 實(shí)施了限制

?對(duì)直接訪(fǎng)問(wèn)已配置的 WLAN 網(wǎng)絡(luò)實(shí)施了限制

?一些電話(huà) API、藍(lán)牙 API 和 WLAN API 需要精確位置權(quán)限

權(quán)限 ： 針對(duì)權(quán)限模型和要求的一些變更。

?限制對(duì)屏幕內(nèi)容的訪(fǎng)問(wèn)

?面向用戶(hù)的權(quán)限檢查（針對(duì)舊版應(yīng)用）

?身體活動(dòng)識(shí)別

?從界面中移除了權(quán)限組

1.2影響應(yīng)用的行為變更

文檔：

限制非 SDK 接口： 為了幫助確保應(yīng)用的穩(wěn)定性和兼容性，Android 平臺(tái)開(kāi)始限制應(yīng)用在 Android 9（API 級(jí)別 28）中使用非 SDK 接口。Android 10 包含更新后的受限制非 SDK 接口列表（基于與 Android 開(kāi)發(fā)者之間的協(xié)作以及最新的內(nèi)部測(cè)試）。我們的目標(biāo)是在限制使用非 SDK 接口之前確保有可用的公開(kāi)替代方案。

手勢(shì)導(dǎo)航： 從 Android 10 開(kāi)始，用戶(hù)可以在設(shè)備中啟用手勢(shì)導(dǎo)航。用戶(hù)啟用后，手勢(shì)導(dǎo)航會(huì)影響設(shè)備上的所有應(yīng)用，無(wú)論應(yīng)用是否以 API 級(jí)別 29 為目標(biāo)平臺(tái)。例如，如果用戶(hù)從屏幕邊緣向內(nèi)滑動(dòng)，系統(tǒng)會(huì)將該手勢(shì)解讀為“返回”導(dǎo)航，除非應(yīng)用針對(duì)屏幕的相應(yīng)部分明確替換該手勢(shì)。

NDK 方面的變更

?共享對(duì)象不得包含文本重定位

?Bionic 庫(kù)和動(dòng)態(tài)鏈接器路徑變更

?系統(tǒng)二進(jìn)制文件/庫(kù)會(huì)映射到只執(zhí)行內(nèi)存

安全方面的變更

??TLS 1.3 默認(rèn)處于啟用狀態(tài)

?TLS 不信任使用 SHA-1 簽名的證書(shū)

?KeyChain 行為變更和改進(jìn)

?其他 TLS 和加密更改

WLAN 直連廣播

在 Android 10 中，以下與 WLAN 直連相關(guān)的廣播不具有粘性：

WIFI_P2P_CONNECTION_CHANGED_ACTION

WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

如果的應(yīng)用依賴(lài)于在注冊(cè)時(shí)接收這些廣播（因?yàn)槠渲耙恢本哂姓承裕?，?qǐng)?jiān)诔跏蓟瘯r(shí)使用適當(dāng)?shù)?get() 方法獲取信息。

WLAN 感知功能 ?

Android 10 擴(kuò)大了支持范圍，現(xiàn)在可以使用 WLAN 感知數(shù)據(jù)路徑輕松創(chuàng)建 TCP/UDP 套接字。要?jiǎng)?chuàng)建連接到 ServerSocket 的 TCP/UDP 套接字，客戶(hù)端設(shè)備需要知道服務(wù)器的 IPv6 地址和端口。這在之前需要通過(guò)頻外方式進(jìn)行通信（例如使用 BT 或 WLAN 感知第 2 層消息傳遞），或者使用其他協(xié)議（例如 mDNS）通過(guò)頻內(nèi)方式發(fā)現(xiàn)。而借助 Android 10，可以將此類(lèi)消息作為網(wǎng)絡(luò)設(shè)置的一部分進(jìn)行傳遞。

Go 設(shè)備上的 SYSTEM_ALERT_WINDOW

在 Android 10（Go 版本）設(shè)備上運(yùn)行的應(yīng)用無(wú)法獲得 SYSTEM_ALERT_WINDOW 權(quán)限。這是因?yàn)槔L制疊加層窗口會(huì)使用過(guò)多的內(nèi)存，這對(duì)低內(nèi)存 Android 設(shè)備的性能十分有害。

如果在搭載 Android 9 或更低版本的 Go 版設(shè)備上運(yùn)行的應(yīng)用獲得了 SYSTEM_ALERT_WINDOW 權(quán)限，則即使設(shè)備升級(jí)到 Android 10，也會(huì)保留此權(quán)限。不過(guò)，尚不具有此權(quán)限的應(yīng)用在設(shè)備升級(jí)后便無(wú)法獲得此權(quán)限了。

如果 Go 設(shè)備上的應(yīng)用發(fā)送具有 ACTION_MANAGE_OVERLAY_PERMISSION 操作的 intent，則系統(tǒng)會(huì)自動(dòng)拒絕此請(qǐng)求，并將用戶(hù)轉(zhuǎn)到設(shè)置屏幕，上面會(huì)顯示不允許授予此權(quán)限，原因是它會(huì)減慢設(shè)備的運(yùn)行速度。如果 Go 設(shè)備上的應(yīng)用調(diào)用 Settings.canDrawOverlays()，則此方法始終返回 false。同樣，這些限制不適用于在設(shè)備升級(jí)到 Android 10 之前便已收到 SYSTEM_ALERT_WINDOW 權(quán)限的應(yīng)用。

關(guān)于以舊版 Android 系統(tǒng)為目標(biāo)平臺(tái)的應(yīng)用的警告

在搭載 Android 10 或更高版本的設(shè)備上，如果用戶(hù)首次運(yùn)行以 Android 5.1（API 級(jí)別 22）或更低版本為目標(biāo)平臺(tái)的應(yīng)用，則會(huì)看到警告。如果此應(yīng)用要求用戶(hù)授予權(quán)限，則系統(tǒng)會(huì)先向用戶(hù)提供調(diào)整應(yīng)用權(quán)限的機(jī)會(huì)，然后才會(huì)允許此應(yīng)用首次運(yùn)行。

由于 Google Play 的目標(biāo) API 方面的要求，用戶(hù)只有在運(yùn)行最近未更新的應(yīng)用時(shí)才會(huì)看到這些警告。對(duì)于通過(guò)其他商店分發(fā)的應(yīng)用，我們也將于 2019 年引入類(lèi)似的目標(biāo) API 方面的要求。如需詳細(xì)了解這些要求，請(qǐng)參閱在 2019 年擴(kuò)展目標(biāo) API 級(jí)別方面的要求。

移除了 SHA-2 CBC 加密套件

以下 SHA-2 CBC 加密套件已從平臺(tái)中移除：

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

這些加密套件不如使用 GCM 的類(lèi)似加密套件安全，并且大多數(shù)服務(wù)器要么同時(shí)支持這些加密套件的 GCM 變體和 CBC 變體，要么二者均不支持。

應(yīng)用使用情況的變更

?UsageStats 應(yīng)用使用情況方面的改進(jìn) - 當(dāng)在分屏或畫(huà)中畫(huà)模式下使用應(yīng)用時(shí)，Android 10 現(xiàn)在能夠使用 UsageStats 準(zhǔn)確地跟蹤應(yīng)用使用情況。此外，Android 10 可以正確地跟蹤免安裝應(yīng)用的使用情況。

?按應(yīng)用開(kāi)啟灰度模式 - Android 10 可針對(duì)各個(gè)應(yīng)用設(shè)置灰度顯示模式。

?按應(yīng)用開(kāi)啟干擾模式 - Android 10 可以選擇性地將應(yīng)用設(shè)置為“干擾模式”，此時(shí)系統(tǒng)會(huì)禁止顯示其通知，并且不會(huì)將其顯示為推薦的應(yīng)用。

?暫停和播放 - 在 Android 10 中，暫停的應(yīng)用無(wú)法播放音頻。

HTTPS 連接變更

如果在 Android 10 上運(yùn)行的應(yīng)用將 null 傳遞給 setSSLSocketFactory()，則會(huì)出現(xiàn) IllegalArgumentException。在以前的版本中，將 null 傳遞給 setSSLSocketFactory() 與傳入當(dāng)前的默認(rèn) SSL 套接字工廠(chǎng)效果相同。

android.preference 庫(kù)已棄用

從 Android 10 開(kāi)始，將棄用 android.preference 庫(kù)。開(kāi)發(fā)者應(yīng)該改為使用 AndroidX preference 庫(kù)，這是 Android Jetpack 的一部分。如需獲取其他有助于遷移和開(kāi)發(fā)的資源，請(qǐng)查看經(jīng)過(guò)更新的設(shè)置指南以及我們的公開(kāi)示例應(yīng)用和參考文檔。

ZIP 文件實(shí)用程序庫(kù)變更

Android 10 對(duì) java.util.zip 軟件包（用于處理 ZIP 文件）中的類(lèi)進(jìn)行了以下變更。這些變更會(huì)讓庫(kù)的行為在 Android 和使用 java.util.zip 的其他平臺(tái)之間更加一致。

?Inflater

在以前的版本中，如果在調(diào)用 end() 之后調(diào)用 Inflater 類(lèi)中的某些方法，這些方法會(huì)拋出 IllegalStateException。在 Android 10 中，這些方法會(huì)改為拋出 NullPointerException。

?ZipFile

在 Android 10 及更高版本中，如果所提供的 ZIP 文件不包含任何文件，則 ZipFile 的構(gòu)造函數(shù)（采用的參數(shù)類(lèi)型為 File、int 和 Charset）不會(huì)拋出 ZipException。

?ZipOutputStream

在 Android 10 及更高版本中，如果 ZipOutputStream 中的 finish() 方法嘗試為不包含任何文件的 ZIP 文件寫(xiě)入輸出流，則此方法不會(huì)拋出 ZipException。

攝像頭變更

很多使用攝像頭的應(yīng)用都會(huì)假定如果設(shè)備采用縱向配置，則物理設(shè)備也會(huì)處于縱向，正如攝像頭方向中所述。在過(guò)去可以做出這樣的假定，但隨著可用的設(shè)備類(lèi)型（例如可折疊設(shè)備）的擴(kuò)展，這一情況發(fā)生了變化。針對(duì)這些設(shè)備做出這樣的假定可能導(dǎo)致相機(jī)取景器的顯示產(chǎn)生錯(cuò)誤的旋轉(zhuǎn)和/或縮放。

以 API 級(jí)別 24 或更高級(jí)別為目標(biāo)平臺(tái)的應(yīng)用應(yīng)該明確設(shè)置 android:resizeableActivity，并提供必要的功能來(lái)處理多窗口操作。

電池用量跟蹤

從 Android 10 開(kāi)始，只要在發(fā)生重大充電事件之后拔下設(shè)備電源插頭，SystemHealthManager 就會(huì)重置其電池用量統(tǒng)計(jì)信息。一般來(lái)說(shuō)，重大充電事件指的是設(shè)備電池已充滿(mǎn)，或者設(shè)備電量從幾乎耗盡變?yōu)榧磳⒊錆M(mǎn)。

在 Android 10 之前，無(wú)論何時(shí)拔下設(shè)備電源插頭，無(wú)論電池電量有多微小的變化，電池用量統(tǒng)計(jì)信息都會(huì)重置。

Android Beam 已棄用

在 Android 10 中，我們正式棄用了 Android Beam，這是一項(xiàng)舊版功能，可通過(guò)近距離無(wú)線(xiàn)通信 (NFC) 在多個(gè)設(shè)備之間啟動(dòng)數(shù)據(jù)共享。我們還棄用了一些相關(guān)的 NFC API。Android Beam 仍可供需要的設(shè)備制造商合作伙伴使用，但它已不再處于積極的開(kāi)發(fā)階段。不過(guò)，Android 仍將繼續(xù)支持其他的 NFC 功能和 API，并且從標(biāo)簽和付款中讀取數(shù)據(jù)等使用場(chǎng)景仍將繼續(xù)按預(yù)期執(zhí)行。