我在 Play 商店中有一个 Android 应用程序已经有 8 年了。最近Google发布Android S或12引入了一些限制,包括前台服务启动限制
和 准确的报警权限
https://developer.android.com/about/versions/12/behavior-changes-12#exact-alarm-permission
在应用程序中,我使用前台服务和闹钟来安排从云和设备传感器更新天气数据并向用户发送通知,更新小部件。 但他们说:确切的警报应该只用于面向用户的功能所以如果我继续使用这些 API,它是安全的(根据 Google Play 政策)?
我问这个是因为其他解决方案(例如带有前台服务和工作管理器的粘性通知)无法满足我的要求。
如果您正在测试 Android 12,请不要忘记将此行添加到 Manifest
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
更新:
Android 13 生成了安全异常,解决方案是在清单中添加以下两行:
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
<uses-permission android:name="android.permission.USE_EXACT_ALARM" />
是的,android.permission.SCHEDULE_EXACT_ALARM可以安全使用,在Android 12上此权限是由Android系统自动授予的,但在Android 13上您需要检查用户是否已授予此权限。
所以你需要将权限添加到清单中
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
然后您需要检查是否授予了权限,如果未授予则需要将用户重定向到警报和提醒页面
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
val alarmManager = ContextCompat.getSystemService(context, AlarmManager::class.java)
if (alarmManager?.canScheduleExactAlarms() == false) {
Intent().also { intent ->
intent.action = Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM
context.startActivity(intent)
}
}
}
Google 还建议您需要通过注册广播接收器来检查此权限的任何更改,并检查 ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED
Google 表示:“(当您的应用程序)需要精确定时的操作时”。您的用例是“安排更新天气数据(…)向用户发送通知”。虽然这可能是面向用户的,但似乎并不需要精确地在某个时间。我猜你的应用不符合条件。
目前需要额外权限的方法有:
setExact()
、setExactAndAllowWhileIdle()
和setAlarmClock()
。重复警报总是不准确的。无论如何,处理天气数据和设备传感器似乎都是重复的事情。
有效的解决方案
您需要先将权限添加到清单中
如官方文档所述(https://developer.android.com/reference/android/Manifest.permission#USE_EXACT_ALARM):
如果您的应用已在较旧的 SDK 上使用 SCHEDULE_EXACT_ALARM,但 在 SDK 33 及更高版本上需要 USE_EXACT_ALARM,然后是 SCHEDULE_EXACT_ALARM 应使用 max-sdk 属性
进行声明
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"
android:maxSdkVersion="32" />
<uses-permission android:name="android.permission.USE_EXACT_ALARM" />
医生还警告:
仅当您使用任何这仅适用于依赖精确警报的应用程序 他们的核心功能
[...]
请记住,这是一个强大的权限,应用程序商店可能会强制执行策略来审核和审查此权限的使用。此类审核可能涉及从应用程序商店删除,如果发现应用程序滥用此权限。
set*exact*
方法在确切的指定日期时间触发警报时,才应使用确切的警报。否则,“计划”方法就足够了,让系统根据某些系统因素选择合适的最接近的日期时间来触发警报。
假设相反的例子是 Facebook 在某个特定时间强制同步用户数据。这会很糟糕,因为最好不要对这些类型的事情强制安排计划,因为当系统资源未被其他服务使用时,它是否发生在特定时间或一分钟后并不重要。
此外,“应该”意味着这是一个建议。 Facebook
可以做到上述,但这将是一个不太理想的解决方案。最好将对此类服务的控制权留给 Android,因为它可能会在分配资源和防止延迟方面做得更好。因此,换句话说,您不听取他们的建议不会让您的应用程序从应用程序商店或类似的地方删除。
此外,您从第二个链接引用的段落有一个指向可接受的用例示例的链接,并且提到了警报应用程序。这可能就是您的问题被否决的原因。