android編譯命令的說明

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.

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

m：編譯所有的模塊

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

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

下面舉個例子說明，假設我要編譯android下的\framework\av\cmds\screenrecord模塊，

當前目錄為源碼根目錄，方法如下：

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的說明

?? ??? ?// 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"

## 第二種方式：在Activity中設置或者通過mActivity = pActivity來設置，如果在本Activity中設置可使用##

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

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

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

"unspecified"默認值，由系統(tǒng)來選擇方向。它的使用策略，以及由于選擇時特定的上下文環(huán)境，可能會因為設備的差異而不同。

"user"使用用戶當前首選的方向。

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

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

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

"reverseLandscape"與正常的橫向方向相反顯示，在API Level 9中被引入。

"reversePortrait"與正常的縱向方向相反顯示，在API Level 9中被引入。

"sensorLandscape"橫向顯示，但是基于設備傳感器，既可以是按正常方向顯示，也可以反向顯示，在API Level 9中被引入。

"sensorPortrait"縱向顯示，但是基于設備傳感器，既可以是按正常方向顯示，也可以反向顯示，在API Level 9中被引入。

"sensor"顯示的方向是由設備的方向傳感器來決定的。顯示方向依賴與用戶怎樣持有設備；當用戶旋轉設備時，顯示的方向會改變。但是，默認情況下，有些設備不會在所有的四個方向上都旋轉，因此要允許在所有的四個方向上都能旋轉，就要使用fullSensor屬性值。

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

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

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

Android 10（29）適配方案簡要說明

Android 10（29）適配方案簡要說明

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

官方文檔：

1.1、Android 10 中的隱私權變更

1.1.1重大隱私權變更

分區(qū)存儲

針對外部存儲的過濾視圖，可提供對特定于應用的文件和媒體集合的訪問權限 訪問和共享外部存儲中的文件的應用 使用特定于應用的目錄和媒體集合目錄

增強了用戶對位置權限的控制力

僅限前臺權限，可讓用戶更好地控制應用對設備位置信息的訪問權限 在后臺時請求訪問用戶位置信息的應用 確保在沒有后臺位置信息更新的情況下優(yōu)雅降級

使用 Android 10 中引入的權限在后臺獲取位置信息

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

針對從后臺啟動 Activity 實施了限制 不需要用戶互動就啟動 Activity 的應用 使用通知觸發(fā)的 Activity

不可重置的硬件標識符

針對訪問設備序列號和 IMEI 實施了限制 訪問設備序列號或 IMEI 的應用 使用用戶可以重置的標識符

無線掃描權限

訪問某些 WLAN、WLAN 感知和藍牙掃描方法需要獲得精確位置權限 使用 WLAN API 和藍牙 API 的應用 針對相關使用場景請求?ACCESS_FINE_LOCATION?權限

1.1.2更多隱私權變更

標識符和數(shù)據(jù)： 針對硬件標識符（如 IMEI、序列號、MAC 和類似數(shù)據(jù)）實施了新限制。

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

?隨機分配 MAC 地址

?對 /proc/net 文件系統(tǒng)的訪問權限實施了限制

?對不可重置的設備標識符實施了限制

?限制了對剪貼板數(shù)據(jù)的訪問權限

?保護 USB 設備序列號

攝像頭和連接性： 針對攝像頭元數(shù)據(jù)和連接 API 提供了更強大的保護措施。 ?對訪問攝像頭詳情和元數(shù)據(jù)的權限實施了限制

?對啟用和停用 WLAN 實施了限制

?對直接訪問已配置的 WLAN 網(wǎng)絡實施了限制

?一些電話 API、藍牙 API 和 WLAN API 需要精確位置權限

權限 ： 針對權限模型和要求的一些變更。

?限制對屏幕內容的訪問

?面向用戶的權限檢查（針對舊版應用）

?身體活動識別

?從界面中移除了權限組

1.2影響應用的行為變更

文檔：

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

手勢導航： 從 Android 10 開始，用戶可以在設備中啟用手勢導航。用戶啟用后，手勢導航會影響設備上的所有應用，無論應用是否以 API 級別 29 為目標平臺。例如，如果用戶從屏幕邊緣向內滑動，系統(tǒng)會將該手勢解讀為“返回”導航，除非應用針對屏幕的相應部分明確替換該手勢。

NDK 方面的變更

?共享對象不得包含文本重定位

?Bionic 庫和動態(tài)鏈接器路徑變更

?系統(tǒng)二進制文件/庫會映射到只執(zhí)行內存

安全方面的變更

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

?TLS 不信任使用 SHA-1 簽名的證書

?KeyChain 行為變更和改進

?其他 TLS 和加密更改

WLAN 直連廣播

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

WIFI_P2P_CONNECTION_CHANGED_ACTION

WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

如果的應用依賴于在注冊時接收這些廣播（因為其之前一直具有粘性），請在初始化時使用適當?shù)?get() 方法獲取信息。

WLAN 感知功能 ?

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

Go 設備上的 SYSTEM_ALERT_WINDOW

在 Android 10（Go 版本）設備上運行的應用無法獲得 SYSTEM_ALERT_WINDOW 權限。這是因為繪制疊加層窗口會使用過多的內存，這對低內存 Android 設備的性能十分有害。

如果在搭載 Android 9 或更低版本的 Go 版設備上運行的應用獲得了 SYSTEM_ALERT_WINDOW 權限，則即使設備升級到 Android 10，也會保留此權限。不過，尚不具有此權限的應用在設備升級后便無法獲得此權限了。

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

關于以舊版 Android 系統(tǒng)為目標平臺的應用的警告

在搭載 Android 10 或更高版本的設備上，如果用戶首次運行以 Android 5.1（API 級別 22）或更低版本為目標平臺的應用，則會看到警告。如果此應用要求用戶授予權限，則系統(tǒng)會先向用戶提供調整應用權限的機會，然后才會允許此應用首次運行。

由于 Google Play 的目標 API 方面的要求，用戶只有在運行最近未更新的應用時才會看到這些警告。對于通過其他商店分發(fā)的應用，我們也將于 2019 年引入類似的目標 API 方面的要求。如需詳細了解這些要求，請參閱在 2019 年擴展目標 API 級別方面的要求。

移除了 SHA-2 CBC 加密套件

以下 SHA-2 CBC 加密套件已從平臺中移除：

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 的類似加密套件安全，并且大多數(shù)服務器要么同時支持這些加密套件的 GCM 變體和 CBC 變體，要么二者均不支持。

應用使用情況的變更

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

?按應用開啟灰度模式 - Android 10 可針對各個應用設置灰度顯示模式。

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

?暫停和播放 - 在 Android 10 中，暫停的應用無法播放音頻。

HTTPS 連接變更

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

android.preference 庫已棄用

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

ZIP 文件實用程序庫變更

Android 10 對 java.util.zip 軟件包（用于處理 ZIP 文件）中的類進行了以下變更。這些變更會讓庫的行為在 Android 和使用 java.util.zip 的其他平臺之間更加一致。

?Inflater

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

?ZipFile

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

?ZipOutputStream

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

攝像頭變更

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

以 API 級別 24 或更高級別為目標平臺的應用應該明確設置 android:resizeableActivity，并提供必要的功能來處理多窗口操作。

電池用量跟蹤

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

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

Android Beam 已棄用

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