Android12 為企業提供的新功能
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本頁概要列出 Android 12 (API 級別 31) 所提供的全新企業 API、功能和行為變更。
工作資料夾
Android 12 工作資料夾提供以下新功能。
工作資料夾安全性與隱私權強化功能
在搭載 Android 12 的個人裝置上,如果設有工作資料夾,則可使用下列功能:
- 密碼複雜度功能會以預先定義的複雜度類別 (高、中、低和無) 形式,設定裝置的密碼要求。如有需要,您可以改為對工作資料夾安全防護驗證設定嚴格的密碼規定。
- 我們簡化了工作資料夾安全防護挑戰的導入程序,設定程序現在會考量裝置密碼是否符合管理員規定,並讓使用者輕鬆選擇是否要提高裝置密碼強度,或使用工作資料夾安全問題。
- 註冊專屬 ID:提供專屬 ID,用來識別特定機構的工作資料夾註冊,且在恢復原廠設定後仍會保持穩定。搭載 Android 12 並設有工作資料夾的個人裝置,將無法存取裝置的其他硬體 ID (IMEI、MEID、序號)。
- 公司擁有的裝置 (無論是否設有工作資料夾) 可以採用上述清單項目列出的功能,但 Android 12 並未強制採用這些功能。
- 您可以設定和擷取工作資料夾網路記錄。您可以將工作資料夾的網路記錄委派給其他工作應用程式。你無法使用網路記錄功能監控個人資料夾的流量。
- 使用者可以進一步控管工作資料夾應用程式的隱私權。除非 IT 管理員拒絕,否則使用者可以授予工作資料夾應用程式下列權限。使用者可以允許或拒絕工作設定檔中每個應用程式的下列權限:
公司擁有的裝置
公司擁有的裝置可使用下列新功能。「公司擁有的裝置」一詞是指全代管裝置和公司擁有的工作資料夾裝置。
其他
以下章節說明企業 API 的變更,這些變更不屬於工作資料夾或公司擁有的裝置。
非受管裝置憑證管理
未受管理的裝置現在可以利用 Android 的裝置端金鑰產生功能管理憑證:
- 使用者可以授予憑證管理應用程式權限,管理自己的憑證 (不包括 CA 憑證)。
- 憑證管理應用程式可以使用 Android 的裝置端金鑰產生功能。
- 憑證管理應用程式可以宣告應用程式和 URI 清單,這些應用程式和 URI 可使用憑證進行驗證。
新版 API 提供的新功能:
全代管裝置的隱私權和資訊公開強化功能
IT 管理員可以管理授權,或在佈建期間選擇不管理感應器相關授權。如果管理員選擇管理權限,使用者會在設定精靈中看到明確訊息。如果管理員選擇停用,使用者首次使用應用程式時,系統會提示他們接受或拒絕應用程式內權限。管理員隨時可以拒絕授權。
網路設定
裝置政策控制器 (DPC) 可以使用新的 API getCallerConfiguredNetworks,取得裝置設定的網路清單,而不必使用現有的 API getConfiguredNetworks (需要位置資訊權限)。傳回的網路清單僅限於工作網路。
全代管裝置上的 DPC 可確保裝置只會設定管理員提供的網路,且不需要位置資訊存取權。
管理員可以授予 Wi-Fi 子系統 KeyChain 金鑰,以便進行驗證,並設定使用該金鑰的企業 Wi-Fi 網路,透過安全硬體產生的金鑰進行 Wi-Fi 驗證。
連結的應用程式自動授予權限
為提供更優質的使用體驗,部分預先載入的應用程式已自動授予「設定」,可共用個人和工作資料。
Android 11 以上版本:
- 視裝置 OEM 而定,預先載入的輔助應用程式或預先載入的預設 IME
- Google 應用程式 (如果已預先載入)。
- Gboard 應用程式 (如果預先載入且為預設的 IME 應用程式)。
Android 12 以上版本:
- Android Auto 應用程式 (如果已預先載入)。
應用程式完整清單視裝置 OEM 而定。
淘汰項目
Android 12 包含下列重要的 API 淘汰項目:
setPasswordQuality()
和 getPasswordQuality()
已淘汰,不再用於在工作資料夾裝置上設定裝置層級密碼。這類裝置屬於個人裝置,而非公司裝置。DPC 應改用 setRequiredPasswordComplexity()
。
- Android 12 已全面淘汰
setOrganizationColor()
和 getOrganizationColor()
。
android.app.action.PROVISION_MANAGED_DEVICE
不再支援 Android 12。
DPC 必須實作活動,並為 ACTION_GET_PROVISIONING_MODE
和 ACTION_ADMIN_POLICY_COMPLIANCE
意圖動作使用意圖篩選器。使用 ACTION_PROVISION_MANAGED_DEVICE
啟動佈建會導致佈建失敗。如要繼續支援 Android 11 以下版本,EMM 應繼續支援 PROVISION_MANAGED_DEVICE
常數。
- 如果所有工作資料夾裝置都以 Android 12 以上版本為目標,系統會停用
setPermissionPolicy()
和 setPermissionGrantState()
,改用其他方式授予感應器相關權限。淘汰作業會造成下列變更:
- 如果裝置從 Android 11 升級至 Android 12,現有的權限授予狀態會保留,但無法授予新權限。
- 使用者仍可拒絕授予權限。
- 如果您開發及發布的應用程式需要管理員授予權限,請務必按照建議方式要求權限。
- 如果應用程式採用建議方式要求權限,則會繼續正常運作。系統會提示使用者授予權限,應用程式必須能處理任何結果。
- 如果應用程式依賴管理員授予的權限,並明確存取受權限保護的資源,但未遵循相關規範,可能會導致當機。
瞭解詳情
如要瞭解其他可能影響應用程式的變更,請參閱 Android 12 行為變更頁面 (指定 Android 12 為目標版本的應用程式和所有應用程式)。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-08-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-08-27 (世界標準時間)。"],[],[],null,["This page provides an overview of the new enterprise APIs, features, and\nbehavior changes introduced in Android 12 (API level 31).\n\nWork profile\n\nThe following new features are available in Android 12 for work\nprofiles.\n\nSecurity and privacy enhancements for work profile\n\nThe following features are available in Android 12 for personal\ndevices with a work profile:\n\n- The [password\n complexity](/reference/android/app/admin/DevicePolicyManager#setRequiredPasswordComplexity(int)) feature sets device-wide password requirements in the form of predefined complexity buckets (High, Medium, Low, and None). If required, strict password requirements can instead be placed on the [work profile security\n challenge](/work/dpc/security#work_profile_security_challenge).\n- Work profile security challenge onboarding has been streamlined. Setup now takes into account whether device passcode meets admin requirements, and makes it easy for the user to choose whether to increase the strength of their device passcode or to use the work profile security challenge.\n- [An enrollment-specific\n ID](/reference/android/app/admin/DevicePolicyManager#setOrganizationId(java.lang.String)) provides a unique ID that identifies the work profile enrollment in a particular organization, and will remain stable across factory resets. Access to other hardware identifiers of the device (IMEI, MEID, serial number) are removed for personal devices with a work profile in Android 12.\n- [Company-owned devices](#company-owned), with and without work profiles, can adopt the features listed in the preceding list items, but are not required to adopt them in Android 12.\n- You can [set](/reference/android/app/admin/DevicePolicyManager#setNetworkLoggingEnabled(android.content.ComponentName,%20boolean)) and [retrieve](/reference/android/app/admin/DevicePolicyManager#retrieveNetworkLogs(android.content.ComponentName,%20long)) work profile network logging. You can [delegate](/reference/android/app/admin/DevicePolicyManager#DELEGATION_NETWORK_LOGGING) network logging on the work profile to another work application. You can't use network logging to monitor traffic in the personal profile.\n- Users have additional privacy controls for work profile apps. Users can grant the following permissions to work profile apps unless denied by their IT administrator. For each app in the work profile, the user can allow or deny the following permissions:\n - Location\n - Camera\n - Microphone\n - Body sensor\n - Physical activity\n\nCompany-owned devices\n\nThe following new features are available for company-owned devices. The term\n*company-owned device* refers to both [fully managed\ndevices](https://developers.google.com/android/work/requirements/fully-managed-device)\nand [work profile devices that are\ncompany-owned](/reference/android/app/admin/DevicePolicyManager#isOrganizationOwnedDeviceWithManagedProfile()).\n\n- An IT administrator can [disable\n USB](/reference/android/app/admin/DevicePolicyManager#setUsbDataSignalingEnabled(boolean)),\n except for charging functions, on company-owned devices. This feature includes\n the capability to [check if this feature is\n supported](/reference/android/app/admin/DevicePolicyManager#canUsbDataSignalingBeDisabled())\n on the device and to [check if it is currently\n enabled](/reference/android/app/admin/DevicePolicyManager#isUsbDataSignalingEnabled()).\n\n- Company-owned devices with a work profile can [limit the input methods used in\n the personal\n profile](/reference/android/app/admin/DevicePolicyManager#setPermittedInputMethods(android.content.ComponentName,%20java.util.List%3Cjava.lang.String%3E))\n to allow only system input methods.\n\n- In Android 12 you can create a delegation scope. Enable and collect security\n log events by calling\n [`setDelegatedScopes()`](/reference/android/app/admin/DevicePolicyManager#setDelegatedScopes(android.content.ComponentName,%20java.lang.String,%20java.util.List%3Cjava.lang.String%3E))\n and passing\n [`DELEGATION_SECURITY_LOGGING`](/reference/android/app/admin/DevicePolicyManager#DELEGATION_SECURITY_LOGGING).\n Security logging helps organizations gather usage data from devices that can be parsed and programmatically evaluated for malicious or risky behavior. Delegate apps can [enable security\n logging](/reference/android/app/admin/DevicePolicyManager#setSecurityLoggingEnabled(android.content.ComponentName,%20boolean)),\n [verify that logging is\n enabled](/reference/android/app/admin/DevicePolicyManager#isSecurityLoggingEnabled(android.content.ComponentName)),\n and [retrieve the security\n logs](/reference/android/app/admin/DevicePolicyManager#retrieveSecurityLogs(android.content.ComponentName)).\n\nOther\n\nThe following section describes changes in enterprise APIs that are not specific\nto work profiles or company-owned devices.\n\nUnmanaged device certificate management\n\nDevices without management are now able to take advantage of Android's on-device\nkey generation to manage certificates:\n\n- The user can grant permission to a certificate management app to manage their credentials (not including CA certificates).\n- The certificate management app can use Android's on-device key generation.\n- The certificate management app can declare a list of apps and URIs where the credentials can be used for authentication.\n\nNew APIs provide new functionality:\n\n- Check if the existing device-wide password is [compliant against explicit\n device password\n requirements](/reference/android/app/admin/DevicePolicyManager#isActivePasswordSufficientForDeviceRequirement()).\n- Check whether a certificate and private key are [installed under a given\n alias](/reference/android/app/admin/DevicePolicyManager#hasKeyPair(java.lang.String)).\n\nPrivacy and transparency enhancements for fully-managed devices\n\nIT administrators can manage permission grants or choose to opt out of managing\nsensor-related permission grants during provisioning. If the administrator\nchooses to manage permissions, users see an explicit message during the setup\nwizard. If the administrator chooses to opt out, users are prompted to accept or\ndeny permissions in-app when the app is first used. Administrators can always\ndeny permissions.\n\nNetwork configuration\n\nA [device policy controller](/work/dpc/build-dpc) (DPC) can get the list of a\ndevice's configured networks without requiring the location permission by using\na new API [getCallerConfiguredNetworks](/reference/android/net/wifi/WifiManager#getCallerConfiguredNetworks())\nrather than using the existing API\n[getConfiguredNetworks](/reference/android/net/wifi/WifiManager#getConfiguredNetworks())\n(which requires location permission). The list of networks returned is limited\nto work networks.\n\nA DPC on fully-managed devices can ensure only admin-provided networks are\nconfigured on the device, also without requiring the location permission.\n\nAdministrators can use the keys generated in secure hardware for Wi-Fi\nauthentication by\n[granting](/reference/android/app/admin/DevicePolicyManager#grantKeyPairToWifiAuth(java.lang.String))\na KeyChain key to the Wi-Fi subsystem for authentication and\n[configuring](/reference/android/net/wifi/WifiEnterpriseConfig#getClientKeyPairAlias())\nan enterprise Wi-Fi network with that key.\n\nConnected apps auto-granting\n\nTo allow a better user experience, a few preloaded applications have\nauto-granted the\n[configuration to share personal and work data](https://support.google.com/work/android/answer/10064639).\n\nOn Android 11+:\n\n- depending on the device OEM, preloaded assist apps or preloaded default IMEs\n- Google app, if it's preloaded.\n- Gboard app, if it's preloaded and the out-of-box default IME app.\n\nOn Android 12+:\n\n- Android Auto app, if it's preloaded.\n\nThe full list of application depends on the device OEM.\n| **Note:** IT admins cannot revoke these auto-granted configurations.\n\nDeprecations\n\nAndroid 12 includes the following notable API deprecations:\n\n- `setPasswordQuality()` and `getPasswordQuality()` are deprecated for setting device-wide passcode on work profile devices that are personal devices rather than company-owned. DPCs should use `setRequiredPasswordComplexity()` instead.\n- `setOrganizationColor()` and `getOrganizationColor()` are fully deprecated in Android 12.\n- `android.app.action.PROVISION_MANAGED_DEVICE` no longer works on Android 12. DPCs must implement activities with intent filters for the `ACTION_GET_PROVISIONING_MODE` and `ACTION_ADMIN_POLICY_COMPLIANCE` intent actions. Using `ACTION_PROVISION_MANAGED_DEVICE` to start provisioning causes the provisioning to fail. To continue to support Android 11 and lower, EMMs should continue to support the `PROVISION_MANAGED_DEVICE` constant.\n- `setPermissionPolicy()` and `setPermissionGrantState()` are deprecated for granting sensor-related permissions for all work profile devices targeting Android 12 and higher. The deprecations cause the following changes:\n - On devices upgrading from Android 11 to Android 12, existing permission grants remain, but new permission grants are not possible.\n - Ability to deny permissions remains.\n - If you develop and distribute applications relying on admin-granted permissions, you must ensure these follow the recommended way of requesting permissions.\n - Applications that follow the recommended way of requesting permissions continue to work as expected. Users are prompted to grant the permission; the app must be able to handle any outcome.\n - Applications that rely on admin-granted permissions and explicitly access permission-protected resources, without following the guidelines, may crash.\n\nLearn more\n\nTo learn about other changes that might affect your app, read the Android 12\nbehavior changes pages (for [apps targeting Android 12](/about/versions/12/behavior-changes-12)\nand [for all apps](/about/versions/12/behavior-changes-all))."]]