[brunonahornygaudium]

Summary

• No Android, o updateData do NotificationContent só gravava som e vibração quando eles vinham no pedido. Quando vinham null, o valor anterior ficava salvo. Como o API_UPDATE sempre chama playCustomSound() e playVibration(), qualquer updateService sem som tocava de novo o último som e repetia a última vibração.
• Isso ficou visível com a live activity do app passageiro, que atualiza a notificação a cada polling. Depois do status arriving, o som e a vibração tocavam a cada ciclo (bug F-02800).
• Agora a chave é removida quando o valor vem null, igual ao NotificationContent.swift do iOS já faz. Som e vibração valem só para o update em que foram informados.

Test plan

• Corrida no app passageiro com o motorista se aproximando (Lockito): som e vibração tocam uma vez na mudança de status e não se repetem nas atualizações da live activity.
• Conferir que a mudança de status com som (accepted, arriving, arrived) continua tocando.

[gaudinho]

✅ Review postada — #12 (review)

job_id: flutter_foreground_task-12-1793912693574-399b

[gaudinho]

O fix ataca a causa raiz. No Android, o updateData deixava som e vibração salvos no SharedPreferences, e o API_UPDATE sempre chama playCustomSound()/playVibration(), então eles tocavam de novo a cada update. Agora o Android remove as chaves quando o valor vem nulo, igual ao NotificationContent.swift do iOS (linhas 84-94). O diff é mínimo, updateData só tem um chamador (ForegroundServiceManager.update) e os outros campos não mudam.

[gaudinho]

Nit / documentação (não bloqueante): o fix está correto e o comentário explica bem o motivo da diferença em relação aos outros campos, que continuam usando ?.let.

Só lembrando que isso muda o comportamento da API pública do plugin no Android. Antes, o som e a vibração ficavam salvos entre updates. Agora valem só para o updateService em que foram passados. Algum consumidor que mandava notificationSound/notificationVibratePattern uma vez e esperava que eles continuassem valendo vai deixar de ouvir o som nos updates seguintes.

Sugestão: colocar uma entrada no CHANGELOG.md (ex.: * [**FIX-Android**] Clear notification sound/vibrate pattern on updateService when not provided, matching iOS behavior), para quem atualizar a versão do plugin ficar sabendo da mudança.