Bug: PendingIntent identity mismatch can leave stale or duplicate boot-restored alarms

[Rahul-2k4]

Description

Alarm scheduling, cancellation, and boot restore do not consistently target the same PendingIntent identity.

The app now routes normal alarm scheduling through AlarmScheduleContract, but there is still upgrade and restore risk around legacy boot-restored alarms and mixed request-code usage. This can leave an old alarm armed when the user expects the latest schedule to replace it.

Affected Code

• android/app/src/main/kotlin/com/ccextractor/ultimate_alarm_clock/ultimate_alarm_clock/AlarmScheduleContract.kt
• android/app/src/main/kotlin/com/ccextractor/ultimate_alarm_clock/ultimate_alarm_clock/BootReceiver.kt
• android/app/src/main/kotlin/com/ccextractor/ultimate_alarm_clock/ultimate_alarm_clock/MainActivity.kt

Why this matters

This is an alarm app, so duplicate or zombie alarms are a trust-breaking bug.

A user can:

• edit an alarm
• reboot the phone
• or upgrade from an older install state

and still have a previously scheduled alarm fire because cancellation and restore are not fully modeled around one stable identity contract.

Current Observations

The current code already contains legacy cancellation handling in AlarmScheduleContract.clear(), which shows this mismatch has existed across scheduling generations.

That makes this a repo-level correctness issue, not just cleanup.

Expected Behavior

• the currently active alarm schedule should be represented by one consistent PendingIntent identity contract
• schedule, cancel, and boot restore should all operate on that same contract
• upgrade paths should explicitly cancel any legacy alarm identities

Suggested Fix

• centralize alarm PendingIntent creation in one helper
• define stable request codes and flags for:
  • main alarm broadcast
  • activity check service
  • location check service
  • weather check service
• ensure all old boot-restored identities are cancelled during clear/reschedule
• add regression tests for upgrade-time and boot-time behavior

Acceptance Criteria

• editing or rescheduling an alarm does not leave the previous alarm armed
• reboot restore does not create a duplicate alarm delivery path
• legacy boot-restored alarms are cancelled during migration/cleanup
• native tests cover the PendingIntent identity contract