mirror of
https://github.com/bulwarkmail/native.git
synced 2026-10-31 08:06:36 +00:00
A push that arrived while the app was in the background started BulwarkPushTaskService with `startService`. Android 8+ allows that only while the app is temporarily allowlisted, which a high-priority FCM message grants. The relay does send FCM data messages at HIGH priority, but FCM delivers some at normal priority anyway (it downgrades apps whose high-priority messages rarely end in a notification), and a UnifiedPush distributor may not raise the app at all. The call then threw `BackgroundServiceStartNotAllowedException` and the app crashed, from the FCM thread or, for UnifiedPush, on the main thread. The service start is kept as the first choice, so a high-priority push works as before. When Android refuses it, the same headless task now runs from a JobScheduler job (BulwarkPushJobService): expedited on Android 12+, which runs at once while the app has expedited-job quota and as a regular job after that, and a regular job on Android 8-11. JobScheduler is a platform API, so nothing is added to the build; WorkManager is not in the dependency tree. A generic "new mail" notification built natively was the other option, but the relay's payload cannot tell new mail from other changes and the native side knows neither the notification settings nor what was already shown. Checked on the API 35 emulator with the R8 release build, the process killed and the push delivered past the allowlist: - FCM data message: before, FATAL EXCEPTION on Firebase-Messaging-Intent-Handle; now the job is scheduled 18 ms after the refusal and runs the task - UnifiedPush message (connector 3.3.5, sent the way a distributor does): before, FATAL EXCEPTION on main; now the same job path - allowlisted FCM message: still starts BulwarkPushTaskService