【问题标题】：Android get list of active alarmsAndroid获取活动警报列表
【发布时间】：2014-03-23 20:36:10
【问题描述】：

有没有办法在我们的应用程序中以编程方式获取 android 设备中所有活动警报的列表以编程方式。只需指出一些可以提供帮助的链接，我基本上是想为用户提供查看其设备中所有警报的便利，因此我想获取设备中所有活动警报的列表。

【问题讨论】：

【解决方案1】：

不，AFAIK 您不能以编程方式执行此操作，因此在 UI 中向用户显示该信息是不可行的。

不过，您可以通过

转储警报数据以供您自己参考

adb shell dumpsys alarm

您不需要 root 权限。

但是你从上面得到的东西可能很难理解。为了完全理解转储，您应该查看 morphatic 的答案 here。

【讨论】：

【解决方案2】：

简短的回答：你不能。

警报管理器无法查看系统中当前安排的警报。每个使用警报管理器的应用都必须保持它们设置的每个警报的状态。

但是，您可以通过 adb 获取列表，如本问题 Get list of active PendingIntents in AlarmManager 中所述。并且应用可以获取系统转储并以这种方式获取警报，但这需要 root。

【讨论】：

但有些应用程序可以设置/更新活动警报。他们是怎么做到的？
应用程序可以通过维护活动警报列表来设置/修改自己的警报。该列表将使用 SharedPreferences 或 sqlite 进行持久化。要修改或删除警报，请完全按照设置时的状态重新创建警报对象，并使用 AlarmManger 方法。干杯。
活跃闹钟是指在“时钟”应用程序 android 中创建的闹钟。我们可以访问这些警报吗？
好吧，我想你在找这个：developer.android.com/reference/android/provider/… 它只指闹钟应用程序设置的闹钟，而这个问题是关于任何应用程序设置的闹钟，因为他们已经声明“所有设备上的警报”。
这有点糟糕

【解决方案3】：

如果您指的是活动闹钟，即设备闹钟应用程序中的闹钟，我认为您可以。尝试查看Here 中的方法。

但是，如果您的意思是想在您的设备上查看由 AlarmManager 创建的所有警报，那么很遗憾您无法以编程方式进行操作。

但是，您可以像这样在文本文件中查看转储数据：

adb shell dumpsys alarm > dump.txt

【讨论】：

【解决方案4】：

你可以得到下一个预定的闹钟(docs)

getSystemService(AlarmManager::class.java).nextAlarmClock.triggerTime

返回警报将触发的时间。此值为 UTC 挂钟时间，以毫秒为单位

【讨论】：

这仅适用于闹钟，不适用于任何其他闹钟类型

【解决方案5】：

要获得活动警报，目前还没有变通方法，但要获得警报列表 - 使用RingtoneManager，它可以访问警报音、铃声和通知声音。

1.要启动用户选择警报的默认意图，您可以像这样启动隐式意图：

private void selectAlarmTone(){
    Intent intent = new Intent(RingtoneManager.ACTION_RINGTONE_PICKER);
    intent.putExtra(RingtoneManager.EXTRA_RINGTONE_TYPE, RingtoneManager.TYPE_ALARM); //Incase you want the user to set a notification use => RingtoneManager.TYPE_NOTIFICATION, ringtone use => RingtoneManager.TYPE_RINGTONE
    intent.putExtra(RingtoneManager.EXTRA_RINGTONE_TITLE, "Select an alarm tone");
    intent.putExtra(RingtoneManager.EXTRA_RINGTONE_EXISTING_URI, (Uri) null);
    startActivityForResult(intent, 1);
}

并从onActivityResult获取用户选择使用的警报：

@Override
protected void onActivityResult(final int requestCode, final int resultCode, final
Intent data) {
    super.onActivityResult(requestCode, resultCode, data);
    if (resultCode == Activity.RESULT_OK && requestCode == 1) {
        Uri selectedUri = data.getParcelableExtra(RingtoneManager.EXTRA_RINGTONE_PICKED_URI);

        Ringtone ringtone = RingtoneManager.getRingtone(this, selectedUri);
        String title = ringtone.getTitle(this);
        Log.i("ALARM_SELECTED: ", title);
    }
}

2。如果您想以编程方式获取音调列表，请使用：

public void listAlarmtones() {
    RingtoneManager ringtoneManager = new RingtoneManager(this);
    ringtoneManager.setType(RingtoneManager.TYPE_ALARM);
    Cursor cursor = ringtoneManager.getCursor();

      while (cursor.moveToNext()) {
        String title = cursor.getString(RingtoneManager.TITLE_COLUMN_INDEX);
        String uri = String.valueOf(ringtoneManager.getRingtoneUri(cursor.getPosition()));

        String alarmTone = cursor.getString(cursor.getColumnIndex("title"));

        Log.e("ALARM_TONE: ", title + "=>" + uri + "=>" + alarmTone);
      }
}

【讨论】：

【解决方案6】：

我刚用我的新手机遇到了这个问题。我从旧手机迁移数据，事后看来，我认为发生的事情是一个不活动的警报应用程序突然激活，或者在迁移后启用了该应用程序中的禁用警报。无论如何，发生的事情是每天 8 点 30 分突然响起一个我无法识别的警报。

以下概述了我是如何解决它的。如果您不在乎，请滚动到最后的 TL;DR。

故障排除过程

我使用的过程是使用adb，如其他答案中所述。然而，如果你这样做，你很快就会不知所措。对我来说，输出是 2,000 多行的输出，并在 260 行附近的某处带有这条简洁的消息：

Pending alarm batches: 130

这是因为这些不是你我所说的警报。相反，它们是各种要求在特定时间被唤醒的应用程序（例如，一个邮件应用程序要求在一分钟内被唤醒以检查新邮件）。所以我猜警报，但对于应用程序。我所做的是首先确定“正确”警报的外观。我已经在官方闹钟应用程序中启用了两个闹钟，它们在过去 24 小时内响过。所以我先跑了：

adb shell dumpsys alarm > two-alarms.txt

然后我禁用了两个警报之一并运行：

adb shell dumpsys alarm > one-alarm.txt

然后我比较了两个输出，发现大部分差异与时间戳有关（这是有道理的——它们在不同的时间运行，输出主要集中在“从现在开始 X 毫秒我应该做什么” ）。例如，我会看到像这样的diff 输出：

287c293
<       type=3 expectedWhenElapsed=+1m51s619ms expectedMaxWhenElapsed=+1m51s619ms whenElapsed=+1m51s619ms maxWhenElapsed=+1m51s619ms when=+1m51s619ms
---
>       type=3 expectedWhenElapsed=+1m48s727ms expectedMaxWhenElapsed=+1m48s727ms whenElapsed=+1m48s727ms maxWhenElapsed=+1m48s727ms when=+1m48s727ms

我重新运行 diff，过滤掉包含 type= 的行：

$ diff -I 'type=' two-alarms.txt one-alarm.txt|less

这仍然包含很多噪音，但相关部分更容易定位。例如，我发现的第一个实质性差异是：

561c567,573
< Batch{b03e994 num=1 start=1851593838 end=1851593838 flgs=0x1}:
---
> Batch{849c837 num=1 start=1851593838 end=1851593838 flgs=0x5}:
>     RTC_WAKEUP #0: Alarm{e855db5 statsTag *walarm*:com.google.android.gms.reminders.notification.ACTION_REFRESH_TIME_REMINDERS type 0 when 1606626000000 com.google.android.gms}
>       tag=*walarm*:com.google.android.gms.reminders.notification.ACTION_REFRESH_TIME_REMINDERS
>       type=0 expectedWhenElapsed=+4h30m42s565ms expectedMaxWhenElapsed=+4h30m42s565ms whenElapsed=+4h30m42s565ms maxWhenElapsed=+4h30m42s565ms when=2020-11-29 00:00:00.000
>       window=0 repeatInterval=0 count=0 flags=0x5
>       operation=PendingIntent{543c4a: PendingIntentRecord{97867bb com.google.android.gms startService}}
> Batch{3f531a4 num=1 start=1851593838 end=1851593838 flgs=0x1}:

这显然是我设置的提醒（或者可能是 Google 提醒设置用于检查提醒的通用“唤醒我以检查提醒”警报）。

对输出的更多挖掘给了我们：

1027c1033,1039
<       type=0 expectedWhenElapsed=+1d13h20m45s459ms expectedMaxWhenElapsed=+1d13h20m45s459ms whenElapsed=+1d13h20m45s459ms maxWhenElapsed=+1d13h20m45s459ms when=2020-11-30 08:50:00.002
---
>       type=0 expectedWhenElapsed=+1d13h20m42s566ms expectedMaxWhenElapsed=+1d13h20m42s566ms whenElapsed=+1d13h20m42s566ms maxWhenElapsed=+1d13h20m42s566ms when=2020-11-30 08:50:00.002
>       window=0 repeatInterval=0 count=0 flags=0x9
>       operation=PendingIntent{89757d2: PendingIntentRecord{127f2fd com.lge.clock broadcastIntent}}
> Batch{39e90a3 num=1 start=2045693838 end=2045693838 flgs=0x9}:
>     RTC_WAKEUP #0: Alarm{ba76fa0 statsTag *walarm*:com.lge.clock.show_quick_dismiss_noti type 0 when 1606820100000 com.lge.clock}
>       tag=*walarm*:com.lge.clock.show_quick_dismiss_noti
>       type=0 expectedWhenElapsed=+2d10h25m42s565ms expectedMaxWhenElapsed=+2d10h25m42s565ms whenElapsed=+2d10h25m42s565ms maxWhenElapsed=+2d10h25m42s565ms when=2020-12-01 05:55:00.000

所以官方的闹钟应用似乎是com.lge.clock，这很合理——它是一部 LG 手机。让我们在原始输出中查找：

  u0a194:com.lge.clock +21s656ms running, 61 wakeups:
    +12s50ms 11 wakes 11 alarms, last -1d10h37m18s647ms:
      *walarm*:com.lge.clock.alarmclock.internal.for.lmk
    +8s338ms 17 wakes 17 alarms, last -1d12h42m26s219ms:
      *walarm*:com.lge.clock.show_quick_dismiss_noti
    +4s272ms 11 wakes 11 alarms, last -1d10h37m18s647ms:
      *walarm*:com.lge.clock.alarmclock.internal
    +1s2ms 11 wakes 11 alarms, last -1d10h38m15s71ms:
      *walarm*:com.lge.sizechangable.weather.action.force.update.currentonly
    +996ms 11 wakes 11 alarms, last -1d10h37m18s647ms:
      *walarm*:indicator

在这里，我们可以看到该应用在一天、10 小时 37 分钟以及几秒和几毫秒前 (-1d10h37m18s647ms) 发出了许多警报。这是有道理的。此输出在 18:32（下午 6:32）运行，而我的一个真实警报设置在 7:55。认识到我们如何识别“最后触发”的时间后，我们现在可以搜索那个虚幻的 8:30 警报。 8:30 距离报告时间大约一天 10 小时 2 分钟，所以我们搜索-1d10h2m 得到：

  u0a235:net.fredericosilva.mornify +14s944ms running, 20 wakeups:
    +14s944ms 20 wakes 20 alarms, last -1d10h2m26s3ms:
      *walarm*:net.fredericosilva.mornify/.alarm.AlarmBroadcastReceiver

嗯...net.fredericosilva.mornify 是什么？在Mornify Play Page 中的快速搜索结果。你瞧！我用那个警报器安装了 Mornify。我完全忘记了我过去曾测试过这个应用程序，并且在我认为它不适合我之后忘记删除它。问题解决了！

TL;DR

第 1 步：

运行报警输出：

adb shell dumpsys alarm > my-alarms.txt

第 2 步：

计算从现在到最后一次虚幻警报响起的相对时间。例如，如果运行输出的时间是下午 6:32:18，而警报在昨天早上 7 点响起，则差异是 6:32 pm-7am+24 小时，即 1 天、11 小时、32 分钟和 18秒（电子表格可以方便地为您计算时间）。

第三步：

将时差重新格式化为-DdHhMm，其中D 是天数，H 是小时数，M 是分钟数。我们将在这里忘记秒数以避免时钟漂移问题。在我们之前的示例中，这将是 -1d11h32m。

第四步：

在第 1 步的输出中搜索此字符串。如果找不到，请在字符串中减去或添加两个分钟以校正时钟差异。

【讨论】：