android通知許可權

❶ oppo怎麼關閉android系統通知欄

通知管理可以管理所有應用的通知許可權，您可以自行選擇各應用通知的展開方式。
1、前往設置 > 通知與狀態欄 > 通知管理。
2、選擇應用 > 開啟或關閉允許通知，還可以在這里選擇來通知時在桌面圖標上顯示數字角標、圓點角標或無角標。
開啟應用的通知許可權後，應用的常規推送會集中展示在通知中心。
在解鎖後的任意屏幕下，從屏幕頂部向下輕掃，即可看到通知中心的消息。
若通知中心裡有您不感興趣的消息，您可以通過以下兩種方式刪除通知：1、向左/向右滑動單個通知，出現刪除圖標後，點擊刪除圖標進行刪除，或繼續向左滑動直接刪除。
2、點擊通知中心右下角全部清除，將通知一次性全部刪除。
本回答適用於OPPO所有機型。

❷ Android 服務的限制

Google官網將Android服務分為了三種，前台服務，後台服務和綁定服務：

前台服務執行一些用戶能注意到的操作。例如，音頻應用會使用前台服務來播放音頻曲目。前台服務必須顯示 通知 。即使用戶停止與應用的交互，前台服務仍會繼續運行。

後台服務執行用戶不會直接注意到的操作。例如，如果應用使用某個服務來壓縮其存儲空間，則此服務通常是後台服務。

當應用組件通過調用 bindService() 綁定到服務時，服務即處於 綁定 狀態。綁定服務會提供客戶端-伺服器介面，以便組件與服務進行交互、發送請求、接收結果，甚至是利用進程間通信 (IPC) 跨進程執行這些操作。僅當與另一個應用組件綁定時，綁定服務才會運行。多個組件可同時綁定到該服務，但全部取消綁定後，該服務即會被銷毀。

我個人理解服務可以分為兩種， 前台 和 後台 ，而 綁定 應該是被當作一種狀態，因為 前台服務 和 後台服務 都可以進行綁定。

基於這個理解，我們將限制分成了前台和後台兩個部分：

從 Android 5.0（API 級別 21）開始，如果使用隱式 Intent 調用 bindService() ，則系統會拋出異常。為確保應用的安全性，在啟動 Service 時，請始終使用顯式 Intent，且不要為服務聲明 Intent 過濾器。

在後台中運行的 Service 會消耗設備資源，這可能會降低用戶體驗。 為了緩解這一問題，系統對這些 Service 施加了一些限制。

處於前台時，應用可以自由創建和運行前台與後台 Service。

Android 8.0 開始：系統不允許後台應用創建後台 Service。否則該函數將引發一個 IllegalStateException。

Android 8.0 開始：進入後台時，在一個持續數分鍾的時間窗內，應用仍可以創建和使用 Service。 在該時間窗結束後，應用將被視為處於 空閑 狀態。 此時，系統將停止應用的後台 Service，就像應用已經調用 Service 的 Service.stopSelf() 方法一樣。

為了解除這種限制，可以使用 JobScheler 作業替換後台 Service。

在 Android 8.0 之前，創建前台 Service 的方式通常是先創建一個後台 Service，然後將該 Service 推到前台。

而在Android 8.0 之後，系統不允許後台應用創建後台 Service。

解決方案：調用 startForegroundService() ，以在前台啟動新 Service。

在系統創建 Service 後，應用有五秒的時間來調用該 Service 的 startForeground() 方法以顯示新 Service 的用戶可見通知。 如果應用在此時間限制內 未 調用 startForeground() ，則系統將停止此 Service 並聲明此應用為 ANR 。

前台服務必須顯示優先順序為 PRIORITY_LOW 或更高的 狀態欄通知 ，這有助於確保用戶知道應用正在執行的任務。如果某操作不是特別重要，因而您希望使用最低優先順序通知，則可能不適合使用服務；相反，您可以考慮使用 計劃作業 。

在 Android 9 (API 28)之後，使用前台服務必須申請 FOREGROUND_SERVICE 許可權，否則會報 SecurityException 。 這是普通許可權，因此，系統會自動為請求許可權的應用授予此許可權。

每個運行服務的應用都會給系統帶來額外負擔，從而消耗系統資源。如果應用嘗試使用低優先順序通知隱藏其服務，則可能會降低用戶正在主動交互的應用的性能。因此，如果某個應用嘗試運行擁有最低優先順序通知的服務，則系統會在抽屜式通知欄的底部調用出該應用的行為。

以 Android 12 為目標平台的應用在後台運行時無法再啟動 前台服務 。

在 Android 11 及以後，系統對前台服務何時可以訪問設備的位置、攝像頭或麥克風進行了限制。

如果您的應用以 Android 11 或更高版本為目標平台，且在前台服務中訪問攝像頭或麥克風，則必須添加 前台服務類型 camera 和 microphone 。

如果你的應用 在後台運行時啟動了某項前台服務 ：

如果某服務的功能（位置、麥克風 和 相機）受到了限制，則Logcat中會列印如下語句：

❸ Notification 通知使用

在 Android 8.0 後，通知需要添加 channel ，所以需要添加版本區別

在應用啟動時請求通知監聽許可權

這樣，在允許了許可權後，應用發送通知，當成功後， Listener 就會產生回調。

❹ Android通知欄許可權是否開啟

需要分系統版本來操作
4.4版本一下不處理，4.4到8.0,8.0以上

跳轉到手機設置界面：

設置界面返回處理：

如果解決問題，是不是要打賞一波呢

❺ OPPO Reno可嘗鮮Android Q：教程如下

5月8日凌晨，Android Q在谷歌I/O開發者大會上正式亮相。在I/O大會現場， 谷歌公布了首批Android Q升級名單，其中OPPO Reno成為首批可適配Android Q的國產手機。

官方介紹，OPPO Reno從今天起就可以體驗到Android Q Beta版。

OPPO Reno如何嘗鮮Android Q？

備份1、確認你的機型為OPPO Reno（PCAM00）並備份你的手機數據：設置-其他設置-備份與恢復-新建備份；

拷貝2、備份完成後，文件位於手機存儲根目錄-backup文件夾，請將該文件拷貝至電腦或其他存儲設備保存。

下載3、下載Android Q Beta版升級固件包，並將該升級固件包拷貝到手機存儲目錄中；

安裝4、手機關機，關機後長按"電源鍵"與"音量下鍵"進入Recovery模式，選擇安裝升級文件，找到對應升級固件包，點擊"安裝"升級即可；

成功5、升級過程中請勿操作手機，升級完成後會彈出"安裝成功"彈框，點擊"重啟"鍵，手機重啟後成功升級到Android Q Beta版。

Android Q Beta新特性

一、安全與隱私：

1、應用許可權通知

Android Q 再次改進APP的許可權管理；定位許可權可設置為"僅在使用時允許"，減少地理位置泄露風險，降低設備功耗；

在設置或通知欄中，可輕松查看哪些APP在使用可能涉及隱私的許可權；

許可權管理交互界面進行重新設計，按鈕更大，縱向分布，有效減少誤觸的可能。

2、隨機MAC地址

在 Android Q 系統中，可選擇隨機 MAC 地址連接 Wi-Fi ，防止廣告商通過嗅探 MAC 地址，匹配用戶手機號碼、消費記錄等私密信息，阻止利用隱私信息的定向廣告。

3、內部存儲許可權管理

Android Q 為每個 APP 提供"隔離存儲沙盒" ，其他應用無法直接訪問沙盒中的文件，有效阻止風險程序檢索隱私文件；

部分共享文件可以申請訪問許可權，例如照片和視頻、音樂和下載內容。

4、剪貼板許可權

剪貼板許可權也被嚴格管控，第三方 APP 將無法隨意讀取你復制的內容。

二、ANGLE渲染器：

ANGLE 渲染器可以將APP中的WebGL和OpenGL ES代碼，轉化接入本地硬體支持的Vulkan API ，加速軟體生態向Vulkan遷移，提升2D/3D渲染的流暢度，動畫更順滑、 游戲 更流暢。

三、氣泡：

氣泡是 Android Q 中的一項新功能。通過氣泡，你可以輕松地從設備上的任何位置進行多任務處理。

氣泡內置於通知系統中，浮動在其他應用內容之上，在不使用時呈折疊狀態。你可以輕敲氣泡以顯示應用程序功能和信息，並且可以通過將其移動或通過向下拖動將其取消。

OPPO官方介紹，在去年的谷歌I/O開發者大會上，在谷歌發布Android P的同時， OPPO就宣布開放OPPO R15夢鏡版，可以運行體驗的Android P開發者預覽版。也因此OPPO成為了國內首批支持Android P的手機廠商。

此次OPPO亮相谷歌I/O大會，也體現了OPPO在軟體、5G等諸多領域的綜合技術實力。隨著OPPO與谷歌雙方的合作升級，OPPO也將不斷提升其軟體綜合實力，在5G時代為消費者帶來更多突破性的技術成果。

❻ Android推送通知許可權判斷及跳轉到許可權設置界面(完善兼容8.0)

有時候產品要求增加一個推送通知的開關（有些還要求具體到哪些通知，比如廣告類？ 比如重大熱點等？）。

我們首先想到的肯定就是再推送回調介面裡面判斷開啟的狀態，進而進行過濾！沒錯，如果對於關閉通知肯定沒問題。但是對於開啟通知有個問題？就是即使你開啟了這個狀態值，但是如果 系統關閉了該應用的通知許可權 ，那麼你開啟了其實也沒有用對吧？

所以正常的邏輯是：

1. 如果關閉，則不用判斷許可權，直接關閉就行

2. 如果開啟，首先判斷是否有通知許可權，如果有則走關閉邏輯就行；如果沒有，則把開關狀態重置回來，然後申請通知許可權 - 通知許可權開啟後再次開啟就沒有問題了

**a> **直接給判斷許可權的工具類：

b> 跳轉到通知設置的界面（自己做了下完善和測試）

啊哈！！目前就是醬紫，這個應該有官方的吧，我找找看...有相關類的說明，但是具體的案例沒有。不過有具體的一些個解釋：

比如： Settings | Android Developers

再比如判斷的方式：

意思就是說：當一個NotificationChannel 被阻塞時，這個getImportance()的值就是IMPORTANCE_NONE，其他情況則不是。所以8.0也就可以根據這個狀態來做判斷.8.0以下的話採用的是反射的方式 - 這個具體的大家可以研究一下。小白暫時不研究了,先做個記錄和簡單學習。

最後使用邏輯：Switch控制項(selector_thumb， selector_track就是slector,裡面就是一些個shape文件...)

剩下的你可以測測了喲...小寶貝...

❼ android 通知欄發送通知需要許可權嗎

不需要，只用獲取通知欄管理器就可以了

❽ Android許可權目錄

android:name="android.permission.INTERNET"————訪問網路

android:name="android.permission.ACCESS_NETWORK_STATE"————獲取網路狀態

android:name="android.permission.ACCESS_WIFI_STATE"————獲取WiFi狀態

android:name="android.permission.WRITE_EXTRNAL_STORAGE"————寫入外部儲存

android:name="android.permission.READ_EXTRNAL_STORAGE"————讀取外部儲存

android:name="android.permission.WRITE_EXTRNAL_STORAGE"————寫入外部儲存

android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEM"

tools:ignore="ProtectedPermission"————掛載卸載文件系統

android:name="android.permission.READ_PHONE_STATE"————讀取電話狀態

android:name="android.permission.VIBRATE"————允許震動

android:name="android.permission.WAKE_LOCK"————允許後台運行

android:name="android.permission.READ_LOGS"

tools:ignore="ProtectedPermission"————讀取系統文件

android:name="android.permission.CAMERA"————調用相機許可權

android:name="android.permission.CALL_PHONE"————調用打電話許可權

android:name="com.fingerprints.service.ACCESS_FINGERPRINT_MANAGER"————指紋識別

android:name="com.samsung.android.providers.context.permission.WRITE_USE_APP_FEATURE_SURVEY"————

android:name="com.samsung.android.providers.context.permission.EXPAND_STATUS_BAR"————通知欄伸縮

android:name="android.permission.REQUEST_INSTALL_PACKGES"————允許請求未知來源許可權

❾ Android 13 適配指南

2022 的Google I/O 發布了 Android 13 beta 2 和 Android 13 Beta 1 國內廠商的設備支持列表，雖然按照慣例， Android 13 應該是年末才發布正式版，但是相信有的開發者已經收到了平台的 Android13 的適配要求，所以本篇也是結合 Oppo 的 Android 13 應用兼容性適配指導 和官方提供的一些文檔內容做一個整理測試。

目前 Android 13 主要的兼容問題還是在於隱私許可權上，所以本次的適配指南相關內容也是著重在這一部分， 這里涉及面比較廣的應該就是相冊和通知許可權 。

這個動圖大家可能看到過， 這是 Android 13 上提供的系統圖片選擇器，通過 Intent(MediaStore.ACTION_PICK_IMAGES); 就可以打開，支持視頻、音頻、圖片分類，支持多選和單選 ，另外官方也表示過，這個特性不僅僅會在 Android 13 中出現，谷歌還會將其放置到 Play 商店中，向 Android 11 和 Android 12 設備推送。

我們通過調整 TargetSDK 設置為 PreView ，然後運行到 Tiramisu 的模擬器上進行測試，主要測試 TargetSDK 在低於 "Tiramisu" 和等於 "Tiramisu" 時的不同情況。

如下圖所示：

總結： 所以如果是 TargetSDK 在 Android 13 以下，不需要處理，如果在 Android 13 以及以上 ，需要增加申請許可權 。

在 Android R 上設置里開始支持在設置里對應用的通知許可權進行管理，但是應用自身是無法修改應用級別的通知許可權，所以 App 無法知道自身有沒有發送通知的許可權

所以在 Android 13 里增加了通知的運行時許可權 ，其中 Android 13 (33) 的通知會根據正在運行的應用程序的目標 API 級別進行不同的處理， 不過不管應用程序的目標API級別如何，Android 13 都會提示用戶授予應用程序發送通知的許可權 。

例如下圖，是 targetSdk 30 運行在 Android 13 模擬器上，依然會彈出讓用戶是否允許推送 。

當然，系統也會根據應用程序的目標 API 級別處理通知訪問:

如果是 現有應用更新 ，程序的目標 API 級別為：

最後測試和總結一下：

由於 Android 之前可以通過跟蹤附近的 Wi-Fi AP 和藍牙設備來推斷設備的位置，所以這次谷歌決定禁止應用程序 訪問藍牙 結果，除非這類應用需要聲明 ACCESS_FINE_LOCATION 許可權。

在 Android 13 中，Google 將 Wi-Fi 掃描與位置相關內容分離， Android 13 為管理設備與周圍 Wi-Fi 熱點連接的應用添加 NEARBY_WIFI_DEVICES 運行時許可權 (屬於 NEARBY_DEVICES 許可權組)，從而在不需要 ACCESS_FINE_LOCATION 許可權的情況下，也可以讓應用訪問附近的 Wi-Fi 設備。

此前，對於僅需要連接 Wi-Fi 設備，但實際上並不需要了解設備位置的應用來說，以 Android 13 (33)為目標平台的應用現在可以通過 「 neverForLocation 」 屬性來完善申請 NEARBY_WIFI_DEVICES 許可權。

這項新許可權會影響幾個不同的 Wi-Fi 用例，包括以下用例：

所以開發需要區分不同api對應的許可權；

由於 NEARBY_WIFI_DEVICES 許可權僅適用於 Android 13 或更高版本， 如果是 Android12L(32) 以及以下的 App 應保留對 ACCESS_FINE_LOCATION 的所有聲明：

以 Android 13(33) 為目標平台時，如果應用不會通過 Wi-Fi API 推導物理位置，請在清單文件中將 usesPermissionFlags 屬性設為 neverForLocation。

所以總結： 以 Android 13(33) 為目標平台的應用程序，訪問附近的 WI-FI 設備。除特例API需要申請ACCESS_FINE_LOCATION外，其他需要申請 android.permission.NEARBY_WIFI_DEVICES 運行時許可權 ；

Android 13 中引入了 「在使用時」 訪問身體感測器（例如心率、體溫和血氧飽和度）的概念，此訪問模式與 Android 10（API 級別 29）系統為位置信息 引入的模式非常相似。

如果你的 App 以 Android 13(33) 為目標平台，並且在後台運行時需要訪問身體感測器信息，那麼除了現有的 BODY_SENSORS 許可權外，還必須聲明新的 BODY_SENSORS_BACKGROUND 許可權 。

當 App 以 Android 13(33) 或更高版本為 Target 的其他應用的導出組件發送 intent 時，僅當該 intent 與接收應用中的 <intent-filter> 元素匹配時，系統才會傳送該 intent，換言之系統會屏蔽所有不匹配的 intent，但以下情況除外：

為了幫助提高運行時接收器的安全性，Android 13 允許你指定 App 中的特定廣播接收器是否應被導出以及是否對設備上的其他應用可見，此變更是 Android 12 更安全的組件 的延續；

以 Android 13(33) 或更高版本為目標平台的應用，必須為每個廣播接收器指定 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED ，否則當 App 嘗試注冊廣播接收器時，系統會拋出 SecurityException

在 Android 13中，谷歌添加了一個新的API，允許開發者降級許可權。

應用程序可以觸發撤銷授予調用 API 的包的一個或多個運行時許可權，不需要訪問特定運行時許可權控制 API 的應用程序可以自行撤銷這些許可權，這樣用戶就可以確保這些應用程序不會在不知情的情況下使用這些API。

如需撤消特定運行時許可權，請將該許可權的名稱傳入 revokeOwnPermissionOnKill() 方法，如需同時撤消一組運行時許可權，請將這組許可權的名稱傳入 revokeOwnPermissionsOnKill() 。

系統只有在安全的情況下才會觸發撤消操作，也就是當有應用組件仍在前台運行，或者有另一個應用正在訪問你應用的組件（如 content provider）時不會發生撤消。

Android 之前一直提供了一個剪貼板服務，所有 App 都可以使用它來放置和檢索文本。

盡管從技術上講，任何應用都可以清除全局剪貼板中的主內容（只要它們是前台應用或 Android 10+ 上的默認輸入法），但 Android 本身不會自動清除剪貼板。

這意味著任何留在全局剪貼板中的剪貼板內容，都可以在以後被應用程序讀取，盡管 Android 的剪貼板訪問有 toast 消息可能會提醒用戶。

Android 13 增加了剪貼板自動清除功能，此功能在默認情況下處於禁用狀態，在經過設定的時間後，將自動從全局剪貼板中清除主剪輯， 默認情況下經過3600000毫秒（60分鍾）後，剪貼板將被清除。

每次執行復制/讀取（寫入剪貼板 setPrimaryClip ，讀 getPrimaryClip ）時，會重置一個消息 timeout（60min），之後會自動清除剪貼板內存中的內容，即60min內，如果一直沒有寫入剪貼板的操作，剪貼板的內容會被自動清除。

Android 13 的新前台服務（ Foreground Services：FGS）任務管理器顯示當前運行前台服務的應用程序列表，此列表稱為活動應用程序，可以通過下拉通知抽屜並點擊啟示來訪問，這時候每個應用程序旁邊都會有一個「停止」按鈕。

利用 JobScheler，應用可使用 JobInfo.Builder.setPrefetch() 將特定作業標記為「預提取」，這意味著理想情況下這些作業應該在應用下一次啟動前提前一點運行，以提升用戶體驗。

過去，JobScheler 僅使用該信號讓預提取作業有機會使用免費或多餘的數據，在 Android 13 中系統現在會嘗試確定應用下次啟動的時間，並根據該估算值運行預提取作業，應用應嘗試使用「預提取」來完成他們想要在下次應用啟動前完成的任何工作。

Android 13 中引入了 電池資源利用率 功能，以便為系統提供多種方法來更好地管理設備電池續航時間：