Next Alarm sensor drops correct trigger time when creatorPackage resolves to "unknown", even with empty allow-list

[h-correia]

Description

The next_alarm sensor only updates to the correct value a few seconds/minutes before
the alarm actually fires, even though AlarmManager.getNextAlarmClock() already has the
correct trigger time available well in advance (confirmed via logcat, see below).

This happens consistently across different alarm apps: Samsung Clock and Sleep as Android
(com.urbandroid.sleep) both show the same behavior.

Root cause (from logcat)

NextAlarmManager resolves the owning app via alarmClockInfo.showIntent?.creatorPackage.
When the alarm is more than a few minutes away, this resolves to null → logged as
"unknown" → the update is dropped by the allow-list check, even though the reported
trigger time is already correct:

07-08 10:52:05.103 NextAlarmManager: Next alarm is scheduled by unknown with trigger time 1783518859000
07-08 10:52:05.103 NextAlarmManager: Skipping update from unknown as it is not in the allow list
...
07-08 10:54:39.037 NextAlarmManager: Next alarm is scheduled by com.urbandroid.sleep with trigger time 1783518900000

Note: 1783518859000 / 1783518900000 both correctly matched the actual scheduled alarm
time at the moment they were first logged — this isn't a data-availability problem, the
correct value is present ~2+ minutes ahead, but is silently discarded because the package
can't yet be resolved.

Made it worse: clearing the allow-list

After clearing the allow-list entirely (expecting it to accept all sources), the sensor
started reflecting what appear to be unrelated system/app-level AlarmClockInfo entries —
e.g. one at 11:12 local with no user-configured alarm at that time. This suggests
getNextAlarmClock() is picking up entries other apps register (possibly for keep-alive
purposes) that aren't genuine user-facing alarms, and an empty allow-list doesn't behave
as "accept the real alarm, ignore everything else."

Impact

Any automation relying on "N minutes before alarm" (a documented use case for this sensor)
is unusable, since the correct value only becomes available seconds before the alarm itself.

Environment

• Device: Samsung Galaxy S25 Ultra
• Android version: 16, security patch level May 2026
• Companion app version: 2026.6.5-full
• Alarm apps tested: Samsung Clock (native), Sleep as Android — same behavior on both

Questions

1. Should an unresolved creatorPackage ("unknown") be dropped silently, or should the
   sensor still update using the trigger time while just leaving the app attribution blank?
2. What's the intended behavior when the allow-list is empty — accept all, or something else?
3. Is there a way to distinguish genuine user-facing alarms from other apps' AlarmClockInfo
   registrations used for background keep-alive?

[jpelgrom]

Hi,

Ignoring the AI spam here:

The allowlist exists because different devices have different apps reporting alarms, and the Android API only allows getting whatever the next alarm scheduled by any app is. It's very frustrating and not the most user-friendly, but the best option available.

That also means:

• With the allowlist (default): This isn't something the HA app can fix as it's not possible to tell whether the app should be allowed. It seems your device has slightly different behavior making this very hard to use. It has been working for many users without issues though - some Samsung apps are known to abuse alarms, even planning them at the same time as other apps, making it difficult to use.
• If you want the sensor to update for any alarm, you can disable the allowlist. However as pointed out and mentioned you will then see alarms from other apps which might not be alarms you've actually set or recognize.