1. 项目概述为什么Unity开发者必须掌握动态权限申请如果你用Unity开发过Android应用并且发布到应用商店那你大概率遇到过这个场景应用在某个新设备上崩溃了后台日志显示一个PermissionDenied异常而你的代码里明明已经声明了权限。或者更常见的是应用在启动时就弹出一大堆权限请求用户还没搞清楚这个应用是干什么的就被吓跑了直接点了拒绝。这就是静态权限声明时代留下的“后遗症”。在Android 6.0API level 23之前权限管理是“一锤子买卖”。你在AndroidManifest.xml文件里声明了uses-permission android:nameandroid.permission.CAMERA /用户安装应用时系统会一次性列出所有需要的权限用户要么全部接受安装要么拒绝安装。这种模式对开发者“友好”但对用户体验是灾难性的也导致了权限滥用。从Android 6.0开始Google引入了运行时权限模型。危险权限Dangerous Permissions——比如访问摄像头、麦克风、位置、存储空间等——不再在安装时授予而是在应用运行过程中在真正需要使用该功能时动态地向用户申请。用户可以在系统设置中随时单独授予或撤销每个权限。这迫使开发者必须思考我的应用在什么场景下才真正需要这个权限我该如何优雅地向用户解释需要权限的原因用户拒绝后我该如何提供降级体验而不是让应用崩溃对于Unity开发者来说这是一个必须跨越的坎。Unity引擎封装了跨平台的能力但在平台特定的功能集成上尤其是像Android运行时权限这种与系统深度交互、且流程复杂的特性需要我们主动去理解和实现。你不能指望简单地勾选Player Settings里的某个选项就万事大吉。本指南将带你从原理到实践彻底搞懂在Unity中如何正确、优雅地处理Android动态权限避开所有常见的坑打造既符合平台规范又用户体验良好的应用。2. 核心原理Android权限体系与Unity的桥梁在动手写代码之前我们必须先理解Android权限体系是如何工作的以及Unity作为“客官”是如何与Android“宿主”进行通信的。这能帮助我们在遇到问题时知道该从哪里排查。2.1 Android危险权限与权限组Android将权限分为几个保护级别我们最需要关注的是“危险权限”。这些权限涉及到用户的隐私或设备操作例如位置ACCESS_FINE_LOCATION,ACCESS_COARSE_LOCATION相机CAMERA麦克风RECORD_AUDIO存储READ_EXTERNAL_STORAGE,WRITE_EXTERNAL_STORAGE在更高API级别上策略有变化联系人READ_CONTACTS,WRITE_CONTACTS一个关键概念是权限组。例如ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION同属于LOCATION组。当用户授予了组内的某一个权限系统会自动授予该组内你申请的其他权限而不会再弹窗询问。但请注意你不能依赖这个行为仍然应该为你实际需要的每一个权限进行申请和检查。2.2 Unity调用Android原生代码的机制Unity本身是一个C#环境要调用Android的Java API需要通过一个叫做AndroidJavaClass和AndroidJavaObject的接口这本质上是基于JNIJava Native Interface的封装。基本调用模式如下// 获取Android的当前活动Activity上下文 AndroidJavaClass unityPlayer new AndroidJavaClass(“com.unity3d.player.UnityPlayer”); AndroidJavaObject currentActivity unityPlayer.GetStaticAndroidJavaObject(“currentActivity”); // 调用Activity的方法例如检查权限 string permission “android.permission.CAMERA”; AndroidJavaObject packageManager currentActivity.CallAndroidJavaObject(“getPackageManager”); int result packageManager.Callint(“checkPermission”, permission, currentActivity.Callstring(“getPackageName”)); // result 为 PackageManager.PERMISSION_GRANTED 或 PERMISSION_DENIED这种方式是可行的但代码冗长且需要处理大量的JNI交互容易出错。幸运的是Unity为我们提供了更高级的封装。2.3 UnityEngine.Android.Permission 命名空间从Unity 2018.3版本开始Unity在UnityEngine.Android命名空间下引入了Permission类。这个类封装了大部分常用的运行时权限操作让C#代码调用起来更加直观和安全。它是我们实现动态权限申请的首选工具。它的核心方法包括Permission.HasUserAuthorizedPermission(string permission): 检查某个权限是否已被授予。Permission.RequestUserPermission(string permission): 异步请求单个权限。Permission.RequestUserPermissions(string[] permissions, PermissionCallbacks callbacks): 异步请求多个权限并可通过回调获取结果。这个封装层帮我们处理了Android版本兼容性、主线程调用等复杂问题极大地简化了开发流程。我们后续的实战将主要基于这个API。注意即使使用了Unity的封装你仍然需要在Plugins/Android/AndroidManifest.xml文件中静态声明你所需要的所有危险权限。动态申请只是在运行时请求授权静态声明是告诉系统“我这个应用可能会用这些功能”两者缺一不可。如果你使用Unity自带的导出功能在Player Settings中启用相应功能如摄像头、麦克风Unity通常会帮你自动生成这部分声明。但手动检查和确认一遍总是好的。3. 实战准备环境配置与基础检查在开始编写核心逻辑前我们需要确保开发环境和工作流是正确的。很多权限问题其实源于错误的配置。3.1 确保正确的Android SDK与编译环境Unity版本建议使用Unity 2019.4 LTS或更高版本这些版本对Android新特性的支持更稳定。确保你的Unity已安装Android Build Support模块。JDK安装Oracle JDK 8或OpenJDK 8/11并在Unity的Edit - Preferences - External Tools中正确设置JDK路径。避免使用过新如JDK 17或环境变量混乱的JDK这常常是构建失败的神秘原因。Android SDK NDK通过Unity Hub或独立安装Android SDK。确保安装了必要的API级别平台工具尤其是你Target API Level对应的版本。NDK则根据Unity版本要求安装通常在External Tools中下载。Target API Level (Target SDK)这是最关键的一项设置。在Player Settings - Other Settings中Minimum API Level: 根据你想支持的最低Android版本设置。Target API Level:必须设置为API level 23 (Android 6.0) 或更高。这是运行时权限机制生效的起点。Google Play要求新应用的目标API必须足够新目前要求至少为API level 33。将其设置为较高的版本如API level 33可以确保应用使用最新的权限和行为模型。3.2 静态权限声明检查无论你用哪种方式申请权限静态声明都是基石。生成或检查你的AndroidManifest.xml文件在Unity中根据你的需求在Player Settings - Other Settings中勾选相应的功能如Camera、Microphone、Location等。Unity会将这些声明自动合并到最终的Manifest中。为了更精细的控制你可以创建自定义的Manifest文件。在Assets文件夹下创建Plugins/Android目录将Unity安装目录下的Editor/Data/PlaybackEngines/AndroidPlayer/Apk/AndroidManifest.xml文件复制过来然后进行修改。打开这个自定义的AndroidManifest.xml在manifest标签内添加你需要的权限例如uses-permission android:nameandroid.permission.CAMERA / uses-permission android:nameandroid.permission.RECORD_AUDIO / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / !-- 如果需要在Android 10 (API 29) 以下访问外部存储可能需要这个 -- uses-permission android:nameandroid.permission.WRITE_EXTERNAL_STORAGE android:maxSdkVersion28 /特别注意存储权限从Android 10 (API 29) 开始作用域存储Scoped Storage被强制执行。对于大多数应用不应该再请求老式的READ/WRITE_EXTERNAL_STORAGE权限来访问共享存储。Unity提供了UnityEngine.Android.Permission.ExternalStorageRead和ExternalStorageWrite常量对应Android的READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE但你应该优先使用Unity的Application.persistentDataPath或通过文件选择器如使用UnityEngine.Android.Permission.RequestUserPermission请求android.permission.READ_MEDIA_IMAGES等媒体权限来访问文件。3.3 创建一个基础的权限管理类框架我们先搭建一个可复用的AndroidPermissionManager单例类框架它将封装所有权限相关的操作。using UnityEngine; using UnityEngine.Android; // 引入Android权限命名空间 public class AndroidPermissionManager : MonoBehaviour { public static AndroidPermissionManager Instance { get; private set; } private void Awake() { if (Instance ! null Instance ! this) { Destroy(this.gameObject); return; } Instance this; DontDestroyOnLoad(this.gameObject); // 常驻方便全局权限管理 } // 后续的方法将在这里添加 }这个管理器将作为我们与UnityPermissionAPI交互的中心。4. 核心实现单权限与多权限的动态申请策略现在进入核心环节如何在实际代码中请求和检查权限。我们将实现两种最常用的场景请求单个权限和请求一组权限。4.1 检查权限状态在请求权限之前或者在使用某个需要权限的功能之前必须先检查权限是否已被授予。这是一个同步操作。/// summary /// 检查单个权限是否已被授予 /// /summary /// param namepermissionUnityEngine.Android.Permission定义的常量如 Permission.Camera/param /// returnstrue 已授权false 未授权/returns public bool CheckPermission(string permission) { // 使用Unity封装的API进行检查 bool hasPermission Permission.HasUserAuthorizedPermission(permission); Debug.Log($”[Permission] Check {permission}: {hasPermission}”); return hasPermission; } // 使用示例 bool canUseCamera Instance.CheckPermission(Permission.Camera);为什么用Unity的API而不是原生调用Unity的HasUserAuthorizedPermission内部已经处理了Android版本兼容性。在Android 6.0以下只要在Manifest中声明了就视为已授权。这省去了我们写条件判断代码的麻烦。4.2 请求单个权限异步回调当检查到权限未被授予时我们需要发起请求。这是一个异步操作因为需要等待用户做出选择。/// summary /// 请求单个权限 /// /summary /// param name“permission”权限常量/param /// param name“callback”请求结果的回调参数为是否授权/param public void RequestPermission(string permission, System.Actionbool callback) { if (CheckPermission(permission)) { callback?.Invoke(true); return; } Debug.Log($”[Permission] Requesting {permission}”); // 注册一个全局监听器简单做法实际更推荐用PermissionCallbacks // 这里先演示基本用法 var callbacks new PermissionCallbacks(); callbacks.PermissionGranted (string perm) { if (perm permission) { Debug.Log($”[Permission] {permission} GRANTED”); callback?.Invoke(true); } }; callbacks.PermissionDenied (string perm) { if (perm permission) { Debug.Log($”[Permission] {permission} DENIED”); callback?.Invoke(false); } }; callbacks.PermissionDeniedAndDontAskAgain (string perm) { if (perm permission) { Debug.Log($”[Permission] {permission} DENIED AND DON‘T ASK AGAIN - 用户选择了‘不再询问’”); callback?.Invoke(false); // 这里可以触发一个提示引导用户去系统设置页手动打开权限 ShowGoToSettingsDialog(permission); } }; Permission.RequestUserPermission(permission, callbacks); } // 使用示例在需要使用相机时 void StartCamera() { Instance.RequestPermission(Permission.Camera, (isGranted) { if (isGranted) { // 初始化并打开相机 Debug.Log(“可以启动相机了”); } else { // 提示用户没有相机权限功能不可用 Debug.LogError(“相机权限被拒绝无法使用拍照功能。”); } }); }关键点解析PermissionCallbacks这个对象提供了三个事件分别对应授权成功、拒绝、以及“拒绝且不再询问”。处理“不再询问”状态至关重要因为此时再次调用RequestUserPermission系统将不会弹出对话框你必须引导用户前往应用系统设置页手动开启。异步性回调函数会在用户操作后在Unity的主线程中被触发你可以在其中安全地更新UI或执行后续逻辑。4.3 批量请求多个权限有时应用需要同时获取多个权限才能启动核心功能比如一个视频通话应用需要相机和麦克风。一次性请求所有必要权限比分开请求体验更好。/// summary /// 批量请求多个权限 /// /summary /// param name“permissions”权限数组/param /// param name“callback”所有权限请求完成后的回调传入一个字典key为权限名value为授权结果/param public void RequestPermissions(string[] permissions, System.ActionDictionarystring, bool callback) { Dictionarystring, bool resultDict new Dictionarystring, bool(); Liststring permissionsToRequest new Liststring(); // 先检查哪些权限还没获取 foreach (var perm in permissions) { if (CheckPermission(perm)) { resultDict[perm] true; } else { permissionsToRequest.Add(perm); resultDict[perm] false; // 先初始化为false } } // 如果所有权限都已拥有直接回调 if (permissionsToRequest.Count 0) { callback?.Invoke(resultDict); return; } Debug.Log($”[Permission] Batch requesting: {string.Join(“, “, permissionsToRequest)}”); var callbacks new PermissionCallbacks(); callbacks.PermissionGranted (string perm) { Debug.Log($”[Permission] {perm} GRANTED in batch”); resultDict[perm] true; CheckAllBatchResults(resultDict, permissions, callback); }; callbacks.PermissionDenied (string perm) { Debug.Log($”[Permission] {perm} DENIED in batch”); resultDict[perm] false; CheckAllBatchResults(resultDict, permissions, callback); }; callbacks.PermissionDeniedAndDontAskAgain (string perm) { Debug.Log($”[Permission] {perm} DENIED AND DON‘T ASK AGAIN in batch”); resultDict[perm] false; // 记录下哪些权限是“不再询问”状态用于特殊提示 // _deniedAndDontAskAgainPerms.Add(perm); CheckAllBatchResults(resultDict, permissions, callback); }; // 使用RequestUserPermissions方法传入权限数组和回调 Permission.RequestUserPermissions(permissionsToRequest.ToArray(), callbacks); } // 辅助方法检查是否所有权限都有了结果无论授权还是拒绝 private void CheckAllBatchResults(Dictionarystring, bool resultDict, string[] allPermissions, System.ActionDictionarystring, bool finalCallback) { // 确保字典里包含了所有要查询的权限的结果 bool allDecided true; foreach (var perm in allPermissions) { // 如果字典里没有这个key或者其value仍是初始状态需要根据你的逻辑判断说明还没结果 // 这里简化处理只要字典包含了该key就认为有结果了因为我们在开始时初始化了所有key if (!resultDict.ContainsKey(perm)) { allDecided false; break; } // 更严谨的做法是使用一个额外的集合来跟踪哪些权限已收到回调 } // 一个更可靠的实现是使用计数器 // 这里为了示例清晰使用一个简单的类成员变量来计数 // 实际项目中建议用更健壮的状态机来管理 } // 使用示例应用启动时请求核心权限 void RequestEssentialPermissions() { string[] essentialPerms new string[] { Permission.Camera, Permission.Microphone, Permission.FineLocation }; Instance.RequestPermissions(essentialPerms, (results) { bool allGranted true; foreach (var kvp in results) { if (!kvp.Value) { Debug.LogWarning($”必要权限 {kvp.Key} 被拒绝。”); allGranted false; } } if (allGranted) { Debug.Log(“所有核心权限已获取可以进入主功能。”); } else { Debug.LogError(“部分核心权限缺失某些功能将受限。应提示用户。”); // 显示一个友好的界面告诉用户哪些功能不可用并引导去设置 } }); }实操心得批量请求时系统会依次弹出权限请求对话框而不是同时弹出多个。用户处理完第一个才会看到第二个。因此权限数组的顺序有一定意义。建议将最核心、最容易被用户理解的权限如相机用于扫码放在前面将相对次要或敏感的权限放在后面。5. 高级处理应对“不再询问”与引导用户至设置页用户拒绝权限时有两个选择“拒绝”和“禁止后不再询问”不同系统翻译略有不同。如果用户选择了后者你的应用再次调用RequestUserPermission时系统将不会显示请求对话框而是直接回调PermissionDeniedAndDontAskAgain事件。此时唯一的途径是引导用户手动前往系统的应用信息页面开启权限。5.1 检测“不再询问”状态在PermissionDeniedAndDontAskAgain回调中我们已经能知道哪个权限被永久拒绝了。但有时我们可能想在请求前就预判一下以便调整UI提示文案。Unity的API没有直接提供这个查询方法。我们可以通过尝试请求一个虚拟权限或者使用Android原生API来间接判断但更常见的做法是在收到PermissionDeniedAndDontAskAgain回调时将该权限状态记录到一个持久化列表如PlayerPrefs中。下次检查时如果HasUserAuthorizedPermission返回false并且该权限在“不再询问”列表中就可以直接显示引导去设置的提示而不用再尝试请求因为请求了也没用。5.2 跳转到应用系统设置页这是引导用户手动开启权限的标准做法。我们需要使用Android的Intent来启动系统设置中本应用的详情页。/// summary /// 打开当前应用的系统设置页面让用户手动管理权限 /// /summary public void OpenAppSystemSettings() { try { AndroidJavaClass unityPlayer new AndroidJavaClass(“com.unity3d.player.UnityPlayer”); AndroidJavaObject currentActivity unityPlayer.GetStaticAndroidJavaObject(“currentActivity”); AndroidJavaObject intent new AndroidJavaObject(“android.content.Intent”); AndroidJavaClass settingsClass new AndroidJavaClass(“android.provider.Settings”); // ACTION_APPLICATION_DETAILS_SETTINGS 是打开应用详情页的Action string action settingsClass.GetStaticstring(“ACTION_APPLICATION_DETAILS_SETTINGS”); intent.CallAndroidJavaObject(“setAction”, action); // 构建当前应用的URI: package:com.yourcompany.yourapp AndroidJavaObject uri new AndroidJavaClass(“android.net.Uri”).CallStaticAndroidJavaObject(“fromParts”, “package”, currentActivity.Callstring(“getPackageName”), null); intent.CallAndroidJavaObject(“setData”, uri); // 添加FLAG_ACTIVITY_NEW_TASK标志在某些情况下是必须的 intent.CallAndroidJavaObject(“addFlags”, 0x10000000); // Intent.FLAG_ACTIVITY_NEW_TASK currentActivity.Call(“startActivity”, intent); } catch (System.Exception e) { Debug.LogError($”[Permission] Failed to open system settings: {e.Message}”); // 备用方案可以尝试更通用的设置页面 ACTION_SETTINGS // 或者给用户一个文字说明 } } // 在UI中调用例如一个按钮的点击事件 public void OnSettingsButtonClicked() { Instance.OpenAppSystemSettings(); }5.3 设计友好的权限解释流程直接弹出一个系统权限对话框上面只有干巴巴的“允许”和“拒绝”转化率是很低的。最佳实践是使用“前置解释对话框”。流程如下检测到需要权限且未被授予。不直接调用RequestUserPermission而是先弹出你自己的自定义UI对话框。在这个对话框中用通俗的语言和图片/图标向用户解释为什么需要这个权限例如“需要访问您的位置是为了在地图上显示您周边的服务点。”权限将如何被使用例如“我们只会在您使用‘附近搜索’功能时获取位置不会在后台持续追踪。”拒绝会有什么影响例如“如果您拒绝地图功能将无法正常使用但其他功能不受影响。”对话框提供两个按钮“去设置”或“好的去开启”和“暂不”。用户点击“去设置”再调用RequestUserPermission弹出系统对话框。用户点击“暂不”则提供功能降级方案。这种“解释-请求”的两步流程能显著提高权限的授予率。对于“不再询问”的情况你的自定义对话框应该直接显示“前往系统设置开启权限”的选项并调用上面的OpenAppSystemSettings方法。6. 实战案例实现一个相机扫码功能的完整权限流程让我们用一个具体的例子把上面的所有知识点串联起来实现一个简单的相机扫码二维码功能。假设场景应用有一个“扫码”按钮点击后如果相机权限已授予则打开相机扫描界面如果未授予则走完整的权限申请流程。using UnityEngine; using UnityEngine.UI; using UnityEngine.Android; public class QRScannerManager : MonoBehaviour { public Button scanButton; // UI上的扫码按钮 public GameObject permissionExplanationPanel; // 自定义的解释权限的UI面板 public Text explanationText; public Button explanationConfirmBtn; public Button explanationCancelBtn; public GameObject scannerPanel; // 模拟的扫码界面 public Text resultText; private void Start() { scanButton.onClick.AddListener(OnScanButtonClicked); explanationConfirmBtn.onClick.AddListener(OnExplanationConfirmed); explanationCancelBtn.onClick.AddListener(OnExplanationCancelled); permissionExplanationPanel.SetActive(false); scannerPanel.SetActive(false); } void OnScanButtonClicked() { // 1. 首先检查权限 if (AndroidPermissionManager.Instance.CheckPermission(Permission.Camera)) { // 已有权限直接开始扫码 StartScanning(); } else { // 2. 没有权限显示前置解释对话框 ShowPermissionExplanation(); } } void ShowPermissionExplanation() { explanationText.text “扫码功能需要使用您的相机来识别二维码。我们只会在您点击‘扫码’按钮时开启相机扫描完成后立即关闭不会录制视频或保存照片。”; permissionExplanationPanel.SetActive(true); } void OnExplanationConfirmed() { permissionExplanationPanel.SetActive(false); // 3. 用户确认后发起真正的权限请求 AndroidPermissionManager.Instance.RequestPermission(Permission.Camera, OnCameraPermissionResult); } void OnExplanationCancelled() { permissionExplanationPanel.SetActive(false); resultText.text “已取消扫码功能不可用。”; // 可以提供其他替代方案比如手动输入二维码编号 } void OnCameraPermissionResult(bool isGranted) { if (isGranted) { StartScanning(); } else { // 4. 处理拒绝情况 // 可以检查是否是“不再询问”状态需要在PermissionManager中记录 // 这里简单提示 resultText.text “相机权限被拒绝无法使用扫码功能。您可以在手机设置中为本应用开启相机权限。”; // 可以在这里添加一个“去设置”的按钮链接到 OpenAppSystemSettings } } void StartScanning() { scannerPanel.SetActive(true); resultText.text “相机已开启请将二维码置于框内...此处集成ZXing等扫码库”; // 实际开发中这里会初始化相机纹理并开始图像分析 // 例如使用ZXing.Net等库进行二维码解码 Debug.Log(“开始扫码...”); // 模拟扫码成功 Invoke(“SimulateScanSuccess”, 2f); } void SimulateScanSuccess() { scannerPanel.SetActive(false); resultText.text “扫描成功内容https://example.com”; // 处理扫描到的数据... } // 在Scanner界面提供一个关闭按钮 public void CloseScanner() { scannerPanel.SetActive(false); Debug.Log(“扫码界面关闭释放相机资源...”); // 实际开发中这里需要关闭相机释放资源 } }这个案例展示了从用户交互到权限检查、解释、申请、结果处理、再到最终功能调用的完整闭环。它遵循了“最小惊动用户”和“提供清晰解释”的原则。7. 常见问题、调试技巧与避坑指南即使按照指南操作在真机测试时你仍可能遇到各种问题。以下是我在多年开发中积累的一些常见问题排查经验和技巧。7.1 权限请求对话框不弹出这是最让人头疼的问题之一。可能的原因和解决方案Target API Level 低于 23这是根本性错误。确保Player Settings - Other Settings - Target API Level设置为23或更高。权限未在 AndroidManifest.xml 中声明运行时权限也必须静态声明。检查你的AndroidManifest.xml文件中是否有对应的uses-permission标签。可以使用adb shell dumpsys package [your.package.name]命令查看最终合并后的权限列表。在后台线程请求权限权限请求必须在主线程Unity游戏线程发起。如果你在异步回调或子线程中调用RequestUserPermission请求可能会被忽略。确保你的调用发生在MonoBehaviour的生命周期方法如Start,Update或由主线程触发的回调中。频繁重复请求如果用户刚刚拒绝立即再次请求系统可能会抑制对话框的显示。应该等待一个合适的时机如用户再次触发相关功能或先显示自己的解释界面。模拟器/设备系统问题有些定制ROM或模拟器镜像可能存在Bug。尝试在标准的Google原生镜像如Pixel系列或真实设备上测试。7.2 在Unity编辑器中测试权限Unity编辑器并非Android环境Permission.HasUserAuthorizedPermission在编辑器中默认返回trueRequestUserPermission调用可能没有效果或行为不一致。为了模拟不同状态你可以使用条件编译void CheckPermissionInEditor() { #if UNITY_EDITOR // 在编辑器中模拟权限状态例如通过一个模拟的UI开关 bool simulatedGranted EditorPrefs.GetBool(“SimulateCameraGranted”, true); if (!simulatedGranted) { Debug.LogWarning(“[Editor Sim] Camera permission denied.”); // 触发拒绝流程 } else { // 触发授权流程 } #elif UNITY_ANDROID // 真实Android平台的代码 AndroidPermissionManager.Instance.RequestPermission(...); #endif }真机调试是必须的任何与权限相关的核心逻辑最终都必须在Android真机上进行充分测试。7.3 处理权限与Activity生命周期如果你的应用在权限请求对话框弹出时被切换到后台例如用户按了Home键当用户再切回来时需要处理好回调。Unity的PermissionCallbacks通常能正确工作但为了更稳健可以考虑在OnApplicationPause方法中做一些状态管理。void OnApplicationPause(bool pauseStatus) { if (!pauseStatus) // 应用从暂停恢复 { // 可以检查一下之前正在等待的权限请求是否超时或需要重新检查 // 例如如果你有一个“正在等待权限结果”的标志位可以在这里重置它 } }7.4 存储权限的变迁与适配如前所述Android的存储权限策略变化很大。对于Unity 2020.3及以上版本如果你只需要访问应用自身的持久化数据路径Application.persistentDataPath通常不需要申请任何存储权限。这个路径在Android上位于/data/data/[package.name]/files或外部存储的应用专属目录应用天生就有读写权限。如果你需要访问共享媒体文件图片、视频、音频应该使用Android的媒体选择器API或请求新的媒体权限如READ_MEDIA_IMAGES而不是老旧的READ_EXTERNAL_STORAGE。Unity的新API也在跟进请密切关注官方文档。避坑指南不要盲目请求WRITE_EXTERNAL_STORAGE除非你的应用是文件管理器或确实需要向公共目录写入非媒体文件否则尽量避免。高版本Android上此权限作用有限且难以获得。使用Application.persistentDataPath这是存储应用私有数据的首选位置无需权限。对于用户文件交互使用UnityEngine.Android.Permission.RequestUserPermission请求媒体权限或使用文件选择器插件。7.5 使用ADB命令进行权限管理调试ADBAndroid Debug Bridge是强大的调试工具。在测试时你可以通过命令行快速修改应用权限状态而不用在设备上点点点。# 1. 连接设备后列出所有包名找到你的应用 adb shell pm list packages | grep your.package # 2. 授予权限 adb shell pm grant [your.package.name] android.permission.CAMERA # 3. 撤销权限 adb shell pm revoke [your.package.name] android.permission.CAMERA # 4. 重置应用的所有权限模拟首次安装 adb shell pm reset-permissions [your.package.name] # 注意这个命令可能需要设备有root权限或是在调试版本上才能执行。 # 5. 查看应用拥有的权限 adb shell dumpsys package [your.package.name] | grep -A 50 “grantedPermissions:”熟练掌握这些命令能极大提升你测试各种权限场景的效率。8. 总结与最佳实践清单动态权限管理不是一项“一次性”任务而是融入应用交互设计的重要部分。回顾整个流程我们可以总结出以下最佳实践清单作为你未来开发中的检查表按需请求场景驱动绝对不要在应用启动时就请求所有危险权限。将权限请求与具体的功能触发点绑定例如只在用户点击“拍照”按钮时请求相机权限。解释先行价值传达在调用系统弹窗前先用自己的UI向用户解释权限的用途和好处尊重用户的知情权和选择权。优雅降级体验连贯用户拒绝权限后应用不应崩溃或出现空白页。应提供清晰的提示和可行的替代方案例如“无法访问位置请手动输入城市名称。”。处理“不再询问”必须检测并妥善处理PermissionDeniedAndDontAskAgain状态。此时应直接引导用户前往系统设置页并提供明确的操作指引。Manifest声明是基础确保AndroidManifest.xml中正确声明了所有需要的权限并注意存储权限等随API级别变化的策略。真机全面测试在多种Android版本和厂商设备上进行测试覆盖“首次请求”、“拒绝后再次请求”、“不再询问后引导设置”等完整流程。优先使用Unity APIUnityEngine.Android.Permission类封装良好是首选。仅在Unity API无法满足特殊需求时才考虑直接调用Android Java API。关注API级别与存储策略将Target API Level设置为推荐值目前至少33并遵循最新的存储访问规范Scoped Storage避免使用已废弃的权限。最后一点个人体会权限管理的好坏直接体现了应用对用户的尊重程度。一个粗暴索要权限的应用即使用户勉强给了也会心存芥蒂。而一个在合适时机、用清晰理由请求权限并在被拒绝后依然能提供友好体验的应用更能赢得用户的信任和长期使用。把这套流程打磨顺畅是你作为Unity移动端开发者专业性的重要体现。
1. 项目概述为什么Unity开发者必须掌握动态权限申请如果你用Unity开发过Android应用并且发布到应用商店那你大概率遇到过这个场景应用在某个新设备上崩溃了后台日志显示一个PermissionDenied异常而你的代码里明明已经声明了权限。或者更常见的是应用在启动时就弹出一大堆权限请求用户还没搞清楚这个应用是干什么的就被吓跑了直接点了拒绝。这就是静态权限声明时代留下的“后遗症”。在Android 6.0API level 23之前权限管理是“一锤子买卖”。你在AndroidManifest.xml文件里声明了uses-permission android:nameandroid.permission.CAMERA /用户安装应用时系统会一次性列出所有需要的权限用户要么全部接受安装要么拒绝安装。这种模式对开发者“友好”但对用户体验是灾难性的也导致了权限滥用。从Android 6.0开始Google引入了运行时权限模型。危险权限Dangerous Permissions——比如访问摄像头、麦克风、位置、存储空间等——不再在安装时授予而是在应用运行过程中在真正需要使用该功能时动态地向用户申请。用户可以在系统设置中随时单独授予或撤销每个权限。这迫使开发者必须思考我的应用在什么场景下才真正需要这个权限我该如何优雅地向用户解释需要权限的原因用户拒绝后我该如何提供降级体验而不是让应用崩溃对于Unity开发者来说这是一个必须跨越的坎。Unity引擎封装了跨平台的能力但在平台特定的功能集成上尤其是像Android运行时权限这种与系统深度交互、且流程复杂的特性需要我们主动去理解和实现。你不能指望简单地勾选Player Settings里的某个选项就万事大吉。本指南将带你从原理到实践彻底搞懂在Unity中如何正确、优雅地处理Android动态权限避开所有常见的坑打造既符合平台规范又用户体验良好的应用。2. 核心原理Android权限体系与Unity的桥梁在动手写代码之前我们必须先理解Android权限体系是如何工作的以及Unity作为“客官”是如何与Android“宿主”进行通信的。这能帮助我们在遇到问题时知道该从哪里排查。2.1 Android危险权限与权限组Android将权限分为几个保护级别我们最需要关注的是“危险权限”。这些权限涉及到用户的隐私或设备操作例如位置ACCESS_FINE_LOCATION,ACCESS_COARSE_LOCATION相机CAMERA麦克风RECORD_AUDIO存储READ_EXTERNAL_STORAGE,WRITE_EXTERNAL_STORAGE在更高API级别上策略有变化联系人READ_CONTACTS,WRITE_CONTACTS一个关键概念是权限组。例如ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION同属于LOCATION组。当用户授予了组内的某一个权限系统会自动授予该组内你申请的其他权限而不会再弹窗询问。但请注意你不能依赖这个行为仍然应该为你实际需要的每一个权限进行申请和检查。2.2 Unity调用Android原生代码的机制Unity本身是一个C#环境要调用Android的Java API需要通过一个叫做AndroidJavaClass和AndroidJavaObject的接口这本质上是基于JNIJava Native Interface的封装。基本调用模式如下// 获取Android的当前活动Activity上下文 AndroidJavaClass unityPlayer new AndroidJavaClass(“com.unity3d.player.UnityPlayer”); AndroidJavaObject currentActivity unityPlayer.GetStaticAndroidJavaObject(“currentActivity”); // 调用Activity的方法例如检查权限 string permission “android.permission.CAMERA”; AndroidJavaObject packageManager currentActivity.CallAndroidJavaObject(“getPackageManager”); int result packageManager.Callint(“checkPermission”, permission, currentActivity.Callstring(“getPackageName”)); // result 为 PackageManager.PERMISSION_GRANTED 或 PERMISSION_DENIED这种方式是可行的但代码冗长且需要处理大量的JNI交互容易出错。幸运的是Unity为我们提供了更高级的封装。2.3 UnityEngine.Android.Permission 命名空间从Unity 2018.3版本开始Unity在UnityEngine.Android命名空间下引入了Permission类。这个类封装了大部分常用的运行时权限操作让C#代码调用起来更加直观和安全。它是我们实现动态权限申请的首选工具。它的核心方法包括Permission.HasUserAuthorizedPermission(string permission): 检查某个权限是否已被授予。Permission.RequestUserPermission(string permission): 异步请求单个权限。Permission.RequestUserPermissions(string[] permissions, PermissionCallbacks callbacks): 异步请求多个权限并可通过回调获取结果。这个封装层帮我们处理了Android版本兼容性、主线程调用等复杂问题极大地简化了开发流程。我们后续的实战将主要基于这个API。注意即使使用了Unity的封装你仍然需要在Plugins/Android/AndroidManifest.xml文件中静态声明你所需要的所有危险权限。动态申请只是在运行时请求授权静态声明是告诉系统“我这个应用可能会用这些功能”两者缺一不可。如果你使用Unity自带的导出功能在Player Settings中启用相应功能如摄像头、麦克风Unity通常会帮你自动生成这部分声明。但手动检查和确认一遍总是好的。3. 实战准备环境配置与基础检查在开始编写核心逻辑前我们需要确保开发环境和工作流是正确的。很多权限问题其实源于错误的配置。3.1 确保正确的Android SDK与编译环境Unity版本建议使用Unity 2019.4 LTS或更高版本这些版本对Android新特性的支持更稳定。确保你的Unity已安装Android Build Support模块。JDK安装Oracle JDK 8或OpenJDK 8/11并在Unity的Edit - Preferences - External Tools中正确设置JDK路径。避免使用过新如JDK 17或环境变量混乱的JDK这常常是构建失败的神秘原因。Android SDK NDK通过Unity Hub或独立安装Android SDK。确保安装了必要的API级别平台工具尤其是你Target API Level对应的版本。NDK则根据Unity版本要求安装通常在External Tools中下载。Target API Level (Target SDK)这是最关键的一项设置。在Player Settings - Other Settings中Minimum API Level: 根据你想支持的最低Android版本设置。Target API Level:必须设置为API level 23 (Android 6.0) 或更高。这是运行时权限机制生效的起点。Google Play要求新应用的目标API必须足够新目前要求至少为API level 33。将其设置为较高的版本如API level 33可以确保应用使用最新的权限和行为模型。3.2 静态权限声明检查无论你用哪种方式申请权限静态声明都是基石。生成或检查你的AndroidManifest.xml文件在Unity中根据你的需求在Player Settings - Other Settings中勾选相应的功能如Camera、Microphone、Location等。Unity会将这些声明自动合并到最终的Manifest中。为了更精细的控制你可以创建自定义的Manifest文件。在Assets文件夹下创建Plugins/Android目录将Unity安装目录下的Editor/Data/PlaybackEngines/AndroidPlayer/Apk/AndroidManifest.xml文件复制过来然后进行修改。打开这个自定义的AndroidManifest.xml在manifest标签内添加你需要的权限例如uses-permission android:nameandroid.permission.CAMERA / uses-permission android:nameandroid.permission.RECORD_AUDIO / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / !-- 如果需要在Android 10 (API 29) 以下访问外部存储可能需要这个 -- uses-permission android:nameandroid.permission.WRITE_EXTERNAL_STORAGE android:maxSdkVersion28 /特别注意存储权限从Android 10 (API 29) 开始作用域存储Scoped Storage被强制执行。对于大多数应用不应该再请求老式的READ/WRITE_EXTERNAL_STORAGE权限来访问共享存储。Unity提供了UnityEngine.Android.Permission.ExternalStorageRead和ExternalStorageWrite常量对应Android的READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE但你应该优先使用Unity的Application.persistentDataPath或通过文件选择器如使用UnityEngine.Android.Permission.RequestUserPermission请求android.permission.READ_MEDIA_IMAGES等媒体权限来访问文件。3.3 创建一个基础的权限管理类框架我们先搭建一个可复用的AndroidPermissionManager单例类框架它将封装所有权限相关的操作。using UnityEngine; using UnityEngine.Android; // 引入Android权限命名空间 public class AndroidPermissionManager : MonoBehaviour { public static AndroidPermissionManager Instance { get; private set; } private void Awake() { if (Instance ! null Instance ! this) { Destroy(this.gameObject); return; } Instance this; DontDestroyOnLoad(this.gameObject); // 常驻方便全局权限管理 } // 后续的方法将在这里添加 }这个管理器将作为我们与UnityPermissionAPI交互的中心。4. 核心实现单权限与多权限的动态申请策略现在进入核心环节如何在实际代码中请求和检查权限。我们将实现两种最常用的场景请求单个权限和请求一组权限。4.1 检查权限状态在请求权限之前或者在使用某个需要权限的功能之前必须先检查权限是否已被授予。这是一个同步操作。/// summary /// 检查单个权限是否已被授予 /// /summary /// param namepermissionUnityEngine.Android.Permission定义的常量如 Permission.Camera/param /// returnstrue 已授权false 未授权/returns public bool CheckPermission(string permission) { // 使用Unity封装的API进行检查 bool hasPermission Permission.HasUserAuthorizedPermission(permission); Debug.Log($”[Permission] Check {permission}: {hasPermission}”); return hasPermission; } // 使用示例 bool canUseCamera Instance.CheckPermission(Permission.Camera);为什么用Unity的API而不是原生调用Unity的HasUserAuthorizedPermission内部已经处理了Android版本兼容性。在Android 6.0以下只要在Manifest中声明了就视为已授权。这省去了我们写条件判断代码的麻烦。4.2 请求单个权限异步回调当检查到权限未被授予时我们需要发起请求。这是一个异步操作因为需要等待用户做出选择。/// summary /// 请求单个权限 /// /summary /// param name“permission”权限常量/param /// param name“callback”请求结果的回调参数为是否授权/param public void RequestPermission(string permission, System.Actionbool callback) { if (CheckPermission(permission)) { callback?.Invoke(true); return; } Debug.Log($”[Permission] Requesting {permission}”); // 注册一个全局监听器简单做法实际更推荐用PermissionCallbacks // 这里先演示基本用法 var callbacks new PermissionCallbacks(); callbacks.PermissionGranted (string perm) { if (perm permission) { Debug.Log($”[Permission] {permission} GRANTED”); callback?.Invoke(true); } }; callbacks.PermissionDenied (string perm) { if (perm permission) { Debug.Log($”[Permission] {permission} DENIED”); callback?.Invoke(false); } }; callbacks.PermissionDeniedAndDontAskAgain (string perm) { if (perm permission) { Debug.Log($”[Permission] {permission} DENIED AND DON‘T ASK AGAIN - 用户选择了‘不再询问’”); callback?.Invoke(false); // 这里可以触发一个提示引导用户去系统设置页手动打开权限 ShowGoToSettingsDialog(permission); } }; Permission.RequestUserPermission(permission, callbacks); } // 使用示例在需要使用相机时 void StartCamera() { Instance.RequestPermission(Permission.Camera, (isGranted) { if (isGranted) { // 初始化并打开相机 Debug.Log(“可以启动相机了”); } else { // 提示用户没有相机权限功能不可用 Debug.LogError(“相机权限被拒绝无法使用拍照功能。”); } }); }关键点解析PermissionCallbacks这个对象提供了三个事件分别对应授权成功、拒绝、以及“拒绝且不再询问”。处理“不再询问”状态至关重要因为此时再次调用RequestUserPermission系统将不会弹出对话框你必须引导用户前往应用系统设置页手动开启。异步性回调函数会在用户操作后在Unity的主线程中被触发你可以在其中安全地更新UI或执行后续逻辑。4.3 批量请求多个权限有时应用需要同时获取多个权限才能启动核心功能比如一个视频通话应用需要相机和麦克风。一次性请求所有必要权限比分开请求体验更好。/// summary /// 批量请求多个权限 /// /summary /// param name“permissions”权限数组/param /// param name“callback”所有权限请求完成后的回调传入一个字典key为权限名value为授权结果/param public void RequestPermissions(string[] permissions, System.ActionDictionarystring, bool callback) { Dictionarystring, bool resultDict new Dictionarystring, bool(); Liststring permissionsToRequest new Liststring(); // 先检查哪些权限还没获取 foreach (var perm in permissions) { if (CheckPermission(perm)) { resultDict[perm] true; } else { permissionsToRequest.Add(perm); resultDict[perm] false; // 先初始化为false } } // 如果所有权限都已拥有直接回调 if (permissionsToRequest.Count 0) { callback?.Invoke(resultDict); return; } Debug.Log($”[Permission] Batch requesting: {string.Join(“, “, permissionsToRequest)}”); var callbacks new PermissionCallbacks(); callbacks.PermissionGranted (string perm) { Debug.Log($”[Permission] {perm} GRANTED in batch”); resultDict[perm] true; CheckAllBatchResults(resultDict, permissions, callback); }; callbacks.PermissionDenied (string perm) { Debug.Log($”[Permission] {perm} DENIED in batch”); resultDict[perm] false; CheckAllBatchResults(resultDict, permissions, callback); }; callbacks.PermissionDeniedAndDontAskAgain (string perm) { Debug.Log($”[Permission] {perm} DENIED AND DON‘T ASK AGAIN in batch”); resultDict[perm] false; // 记录下哪些权限是“不再询问”状态用于特殊提示 // _deniedAndDontAskAgainPerms.Add(perm); CheckAllBatchResults(resultDict, permissions, callback); }; // 使用RequestUserPermissions方法传入权限数组和回调 Permission.RequestUserPermissions(permissionsToRequest.ToArray(), callbacks); } // 辅助方法检查是否所有权限都有了结果无论授权还是拒绝 private void CheckAllBatchResults(Dictionarystring, bool resultDict, string[] allPermissions, System.ActionDictionarystring, bool finalCallback) { // 确保字典里包含了所有要查询的权限的结果 bool allDecided true; foreach (var perm in allPermissions) { // 如果字典里没有这个key或者其value仍是初始状态需要根据你的逻辑判断说明还没结果 // 这里简化处理只要字典包含了该key就认为有结果了因为我们在开始时初始化了所有key if (!resultDict.ContainsKey(perm)) { allDecided false; break; } // 更严谨的做法是使用一个额外的集合来跟踪哪些权限已收到回调 } // 一个更可靠的实现是使用计数器 // 这里为了示例清晰使用一个简单的类成员变量来计数 // 实际项目中建议用更健壮的状态机来管理 } // 使用示例应用启动时请求核心权限 void RequestEssentialPermissions() { string[] essentialPerms new string[] { Permission.Camera, Permission.Microphone, Permission.FineLocation }; Instance.RequestPermissions(essentialPerms, (results) { bool allGranted true; foreach (var kvp in results) { if (!kvp.Value) { Debug.LogWarning($”必要权限 {kvp.Key} 被拒绝。”); allGranted false; } } if (allGranted) { Debug.Log(“所有核心权限已获取可以进入主功能。”); } else { Debug.LogError(“部分核心权限缺失某些功能将受限。应提示用户。”); // 显示一个友好的界面告诉用户哪些功能不可用并引导去设置 } }); }实操心得批量请求时系统会依次弹出权限请求对话框而不是同时弹出多个。用户处理完第一个才会看到第二个。因此权限数组的顺序有一定意义。建议将最核心、最容易被用户理解的权限如相机用于扫码放在前面将相对次要或敏感的权限放在后面。5. 高级处理应对“不再询问”与引导用户至设置页用户拒绝权限时有两个选择“拒绝”和“禁止后不再询问”不同系统翻译略有不同。如果用户选择了后者你的应用再次调用RequestUserPermission时系统将不会显示请求对话框而是直接回调PermissionDeniedAndDontAskAgain事件。此时唯一的途径是引导用户手动前往系统的应用信息页面开启权限。5.1 检测“不再询问”状态在PermissionDeniedAndDontAskAgain回调中我们已经能知道哪个权限被永久拒绝了。但有时我们可能想在请求前就预判一下以便调整UI提示文案。Unity的API没有直接提供这个查询方法。我们可以通过尝试请求一个虚拟权限或者使用Android原生API来间接判断但更常见的做法是在收到PermissionDeniedAndDontAskAgain回调时将该权限状态记录到一个持久化列表如PlayerPrefs中。下次检查时如果HasUserAuthorizedPermission返回false并且该权限在“不再询问”列表中就可以直接显示引导去设置的提示而不用再尝试请求因为请求了也没用。5.2 跳转到应用系统设置页这是引导用户手动开启权限的标准做法。我们需要使用Android的Intent来启动系统设置中本应用的详情页。/// summary /// 打开当前应用的系统设置页面让用户手动管理权限 /// /summary public void OpenAppSystemSettings() { try { AndroidJavaClass unityPlayer new AndroidJavaClass(“com.unity3d.player.UnityPlayer”); AndroidJavaObject currentActivity unityPlayer.GetStaticAndroidJavaObject(“currentActivity”); AndroidJavaObject intent new AndroidJavaObject(“android.content.Intent”); AndroidJavaClass settingsClass new AndroidJavaClass(“android.provider.Settings”); // ACTION_APPLICATION_DETAILS_SETTINGS 是打开应用详情页的Action string action settingsClass.GetStaticstring(“ACTION_APPLICATION_DETAILS_SETTINGS”); intent.CallAndroidJavaObject(“setAction”, action); // 构建当前应用的URI: package:com.yourcompany.yourapp AndroidJavaObject uri new AndroidJavaClass(“android.net.Uri”).CallStaticAndroidJavaObject(“fromParts”, “package”, currentActivity.Callstring(“getPackageName”), null); intent.CallAndroidJavaObject(“setData”, uri); // 添加FLAG_ACTIVITY_NEW_TASK标志在某些情况下是必须的 intent.CallAndroidJavaObject(“addFlags”, 0x10000000); // Intent.FLAG_ACTIVITY_NEW_TASK currentActivity.Call(“startActivity”, intent); } catch (System.Exception e) { Debug.LogError($”[Permission] Failed to open system settings: {e.Message}”); // 备用方案可以尝试更通用的设置页面 ACTION_SETTINGS // 或者给用户一个文字说明 } } // 在UI中调用例如一个按钮的点击事件 public void OnSettingsButtonClicked() { Instance.OpenAppSystemSettings(); }5.3 设计友好的权限解释流程直接弹出一个系统权限对话框上面只有干巴巴的“允许”和“拒绝”转化率是很低的。最佳实践是使用“前置解释对话框”。流程如下检测到需要权限且未被授予。不直接调用RequestUserPermission而是先弹出你自己的自定义UI对话框。在这个对话框中用通俗的语言和图片/图标向用户解释为什么需要这个权限例如“需要访问您的位置是为了在地图上显示您周边的服务点。”权限将如何被使用例如“我们只会在您使用‘附近搜索’功能时获取位置不会在后台持续追踪。”拒绝会有什么影响例如“如果您拒绝地图功能将无法正常使用但其他功能不受影响。”对话框提供两个按钮“去设置”或“好的去开启”和“暂不”。用户点击“去设置”再调用RequestUserPermission弹出系统对话框。用户点击“暂不”则提供功能降级方案。这种“解释-请求”的两步流程能显著提高权限的授予率。对于“不再询问”的情况你的自定义对话框应该直接显示“前往系统设置开启权限”的选项并调用上面的OpenAppSystemSettings方法。6. 实战案例实现一个相机扫码功能的完整权限流程让我们用一个具体的例子把上面的所有知识点串联起来实现一个简单的相机扫码二维码功能。假设场景应用有一个“扫码”按钮点击后如果相机权限已授予则打开相机扫描界面如果未授予则走完整的权限申请流程。using UnityEngine; using UnityEngine.UI; using UnityEngine.Android; public class QRScannerManager : MonoBehaviour { public Button scanButton; // UI上的扫码按钮 public GameObject permissionExplanationPanel; // 自定义的解释权限的UI面板 public Text explanationText; public Button explanationConfirmBtn; public Button explanationCancelBtn; public GameObject scannerPanel; // 模拟的扫码界面 public Text resultText; private void Start() { scanButton.onClick.AddListener(OnScanButtonClicked); explanationConfirmBtn.onClick.AddListener(OnExplanationConfirmed); explanationCancelBtn.onClick.AddListener(OnExplanationCancelled); permissionExplanationPanel.SetActive(false); scannerPanel.SetActive(false); } void OnScanButtonClicked() { // 1. 首先检查权限 if (AndroidPermissionManager.Instance.CheckPermission(Permission.Camera)) { // 已有权限直接开始扫码 StartScanning(); } else { // 2. 没有权限显示前置解释对话框 ShowPermissionExplanation(); } } void ShowPermissionExplanation() { explanationText.text “扫码功能需要使用您的相机来识别二维码。我们只会在您点击‘扫码’按钮时开启相机扫描完成后立即关闭不会录制视频或保存照片。”; permissionExplanationPanel.SetActive(true); } void OnExplanationConfirmed() { permissionExplanationPanel.SetActive(false); // 3. 用户确认后发起真正的权限请求 AndroidPermissionManager.Instance.RequestPermission(Permission.Camera, OnCameraPermissionResult); } void OnExplanationCancelled() { permissionExplanationPanel.SetActive(false); resultText.text “已取消扫码功能不可用。”; // 可以提供其他替代方案比如手动输入二维码编号 } void OnCameraPermissionResult(bool isGranted) { if (isGranted) { StartScanning(); } else { // 4. 处理拒绝情况 // 可以检查是否是“不再询问”状态需要在PermissionManager中记录 // 这里简单提示 resultText.text “相机权限被拒绝无法使用扫码功能。您可以在手机设置中为本应用开启相机权限。”; // 可以在这里添加一个“去设置”的按钮链接到 OpenAppSystemSettings } } void StartScanning() { scannerPanel.SetActive(true); resultText.text “相机已开启请将二维码置于框内...此处集成ZXing等扫码库”; // 实际开发中这里会初始化相机纹理并开始图像分析 // 例如使用ZXing.Net等库进行二维码解码 Debug.Log(“开始扫码...”); // 模拟扫码成功 Invoke(“SimulateScanSuccess”, 2f); } void SimulateScanSuccess() { scannerPanel.SetActive(false); resultText.text “扫描成功内容https://example.com”; // 处理扫描到的数据... } // 在Scanner界面提供一个关闭按钮 public void CloseScanner() { scannerPanel.SetActive(false); Debug.Log(“扫码界面关闭释放相机资源...”); // 实际开发中这里需要关闭相机释放资源 } }这个案例展示了从用户交互到权限检查、解释、申请、结果处理、再到最终功能调用的完整闭环。它遵循了“最小惊动用户”和“提供清晰解释”的原则。7. 常见问题、调试技巧与避坑指南即使按照指南操作在真机测试时你仍可能遇到各种问题。以下是我在多年开发中积累的一些常见问题排查经验和技巧。7.1 权限请求对话框不弹出这是最让人头疼的问题之一。可能的原因和解决方案Target API Level 低于 23这是根本性错误。确保Player Settings - Other Settings - Target API Level设置为23或更高。权限未在 AndroidManifest.xml 中声明运行时权限也必须静态声明。检查你的AndroidManifest.xml文件中是否有对应的uses-permission标签。可以使用adb shell dumpsys package [your.package.name]命令查看最终合并后的权限列表。在后台线程请求权限权限请求必须在主线程Unity游戏线程发起。如果你在异步回调或子线程中调用RequestUserPermission请求可能会被忽略。确保你的调用发生在MonoBehaviour的生命周期方法如Start,Update或由主线程触发的回调中。频繁重复请求如果用户刚刚拒绝立即再次请求系统可能会抑制对话框的显示。应该等待一个合适的时机如用户再次触发相关功能或先显示自己的解释界面。模拟器/设备系统问题有些定制ROM或模拟器镜像可能存在Bug。尝试在标准的Google原生镜像如Pixel系列或真实设备上测试。7.2 在Unity编辑器中测试权限Unity编辑器并非Android环境Permission.HasUserAuthorizedPermission在编辑器中默认返回trueRequestUserPermission调用可能没有效果或行为不一致。为了模拟不同状态你可以使用条件编译void CheckPermissionInEditor() { #if UNITY_EDITOR // 在编辑器中模拟权限状态例如通过一个模拟的UI开关 bool simulatedGranted EditorPrefs.GetBool(“SimulateCameraGranted”, true); if (!simulatedGranted) { Debug.LogWarning(“[Editor Sim] Camera permission denied.”); // 触发拒绝流程 } else { // 触发授权流程 } #elif UNITY_ANDROID // 真实Android平台的代码 AndroidPermissionManager.Instance.RequestPermission(...); #endif }真机调试是必须的任何与权限相关的核心逻辑最终都必须在Android真机上进行充分测试。7.3 处理权限与Activity生命周期如果你的应用在权限请求对话框弹出时被切换到后台例如用户按了Home键当用户再切回来时需要处理好回调。Unity的PermissionCallbacks通常能正确工作但为了更稳健可以考虑在OnApplicationPause方法中做一些状态管理。void OnApplicationPause(bool pauseStatus) { if (!pauseStatus) // 应用从暂停恢复 { // 可以检查一下之前正在等待的权限请求是否超时或需要重新检查 // 例如如果你有一个“正在等待权限结果”的标志位可以在这里重置它 } }7.4 存储权限的变迁与适配如前所述Android的存储权限策略变化很大。对于Unity 2020.3及以上版本如果你只需要访问应用自身的持久化数据路径Application.persistentDataPath通常不需要申请任何存储权限。这个路径在Android上位于/data/data/[package.name]/files或外部存储的应用专属目录应用天生就有读写权限。如果你需要访问共享媒体文件图片、视频、音频应该使用Android的媒体选择器API或请求新的媒体权限如READ_MEDIA_IMAGES而不是老旧的READ_EXTERNAL_STORAGE。Unity的新API也在跟进请密切关注官方文档。避坑指南不要盲目请求WRITE_EXTERNAL_STORAGE除非你的应用是文件管理器或确实需要向公共目录写入非媒体文件否则尽量避免。高版本Android上此权限作用有限且难以获得。使用Application.persistentDataPath这是存储应用私有数据的首选位置无需权限。对于用户文件交互使用UnityEngine.Android.Permission.RequestUserPermission请求媒体权限或使用文件选择器插件。7.5 使用ADB命令进行权限管理调试ADBAndroid Debug Bridge是强大的调试工具。在测试时你可以通过命令行快速修改应用权限状态而不用在设备上点点点。# 1. 连接设备后列出所有包名找到你的应用 adb shell pm list packages | grep your.package # 2. 授予权限 adb shell pm grant [your.package.name] android.permission.CAMERA # 3. 撤销权限 adb shell pm revoke [your.package.name] android.permission.CAMERA # 4. 重置应用的所有权限模拟首次安装 adb shell pm reset-permissions [your.package.name] # 注意这个命令可能需要设备有root权限或是在调试版本上才能执行。 # 5. 查看应用拥有的权限 adb shell dumpsys package [your.package.name] | grep -A 50 “grantedPermissions:”熟练掌握这些命令能极大提升你测试各种权限场景的效率。8. 总结与最佳实践清单动态权限管理不是一项“一次性”任务而是融入应用交互设计的重要部分。回顾整个流程我们可以总结出以下最佳实践清单作为你未来开发中的检查表按需请求场景驱动绝对不要在应用启动时就请求所有危险权限。将权限请求与具体的功能触发点绑定例如只在用户点击“拍照”按钮时请求相机权限。解释先行价值传达在调用系统弹窗前先用自己的UI向用户解释权限的用途和好处尊重用户的知情权和选择权。优雅降级体验连贯用户拒绝权限后应用不应崩溃或出现空白页。应提供清晰的提示和可行的替代方案例如“无法访问位置请手动输入城市名称。”。处理“不再询问”必须检测并妥善处理PermissionDeniedAndDontAskAgain状态。此时应直接引导用户前往系统设置页并提供明确的操作指引。Manifest声明是基础确保AndroidManifest.xml中正确声明了所有需要的权限并注意存储权限等随API级别变化的策略。真机全面测试在多种Android版本和厂商设备上进行测试覆盖“首次请求”、“拒绝后再次请求”、“不再询问后引导设置”等完整流程。优先使用Unity APIUnityEngine.Android.Permission类封装良好是首选。仅在Unity API无法满足特殊需求时才考虑直接调用Android Java API。关注API级别与存储策略将Target API Level设置为推荐值目前至少33并遵循最新的存储访问规范Scoped Storage避免使用已废弃的权限。最后一点个人体会权限管理的好坏直接体现了应用对用户的尊重程度。一个粗暴索要权限的应用即使用户勉强给了也会心存芥蒂。而一个在合适时机、用清晰理由请求权限并在被拒绝后依然能提供友好体验的应用更能赢得用户的信任和长期使用。把这套流程打磨顺畅是你作为Unity移动端开发者专业性的重要体现。
双梁正问题 【 torch 实战】（Python代码实现）)
