Android で 位置情報取得を定期実行する方法をしらべたので、メモっておく
Foreground 実装
フォアグラウンドサービスの最低限の実装について【Kotlin, Android Studio, バックグラウンドでのアプリ実行】 - アンラッキーシステムズのやり方、方法論。
AndroidアプリでForeground Serviceを使って、画面スリープ状態でも位置情報を定期取得する | DevelopersIO
Auto-Start Foreground Service in Android | by CodingwithSaud | The Startup | Medium
Androidアプリでバックグラウンド状態で位置情報が取得できるのか調査した - 酢ろぐ！
バックグラウンドで位置情報アクセスするアプリには特別な審査が必要
審査に必要なものは、Google公式のバックグラウンド位置情報にアクセスするアプリの審査を円滑に進めるためのヒントにも書かれている通り以下のものを準備する必要がある。
機密情報に関わる申請 を行う ・デモ動画が必要 アプリ内での位置情報使用の開示を行う (位置情報許諾ダイアログ) プライバシーポリシー にバックグラウンドで位置情報を取得する件について書く
Android13でアプリ監視強化。電池持ちが改善する可能性も - Gadget Arena
フォアグラウンド サービス（FGS）タスク マネージャー | Android デベロッパー | Android Developers
Why did Android 13 remove the Foreground Service notification? - Stack Overflow
Sorry for the sort of click-bait title; I couldn’t think of a more concise way to say it.
In Android 13, if the user doesn’t grant the “dangerous” POST_NOTIFICATION permission, then Foreground Service notifications are not shown in the Notification Drawer. Instead, for the user to see it, they have to navigate to the new Foreground Services Task Manager, according to the documentation:
If the user denies the notification permission, they still see notices related to these foreground services in the Foreground Services (FGS) Task Manager but don’t see them in the notification drawer.
Now I haven’t used the Android 13 Beta so I don’t know exactly how “in the face” the FGS Task Manager will be when Foreground Services are running, but I thought the entire point of forcing Foreground Services to have a notification was so that the user would be aware when the application was running. This even has security consequences because Android restricts what background v.s. foreground processes can do using dangerous permissions (e.g. ACCESS_BACKGROUND_LOCATION). This change essentially allows an app to use foreground based permissions without clearly notifiying the user.
So, why did they decide to restrict Foreground Service notifications? I mean there is a whole other discussion about the addition of restricting notifications in the first place. But one would think that if Android forces you to use a notification, then there shouldn’t be a way to get around it (i.e. never request the POST_NOTIFICATION permission or even just remove the permission programatically).
これ以上簡潔な言い方が思いつかなかったので、クリックしやすいタイトルで申し訳ないです。
Android 13では、ユーザーが「危険な」POST_NOTIFICATION権限を付与していない場合、Foreground Serviceの通知は通知ドロワーに表示されません。その代わり、ドキュメントによると、ユーザーがそれを見るには、新しいフォアグラウンド・サービスのタスク・マネージャーに移動する必要があるそうです。
ユーザーが通知許可を拒否した場合、これらのフォアグラウンドサービスに関連する通知はフォアグラウンドサービス（FGS）タスクマネージャーで引き続き表示されますが、通知ドロワーでは表示されません。
私はAndroid 13 Betaを使用していないので、フォアグラウンド・サービスが実行されているときにFGSタスク・マネージャがどのように「見える」ようになるか正確にはわかりませんが、フォアグラウンド・サービスに通知を強制する全体のポイントは、アプリケーションが実行されているときにユーザーが認識できるようにすることだと私は考えていました。Androidは、危険なパーミッション（例：ACCESS_BACKGROUND_LOCATION）を使用して、バックグラウンドプロセスとフォアグラウンドプロセスができることを制限しているため、これはセキュリティにも影響を及ぼします。この変更により、アプリはユーザーに明確に通知することなく、フォアグラウンドベースのパーミッションを使用することができます。
では、なぜフォアグラウンドサービスの通知を制限することにしたのでしょうか？つまり、そもそも通知を制限することの追加については、全く別の議論があるのです。しかし、Androidが通知の使用を強制するなら、それを回避する方法（つまり、POST_NOTIFICATION権限を決して要求しない、あるいは、プログラム的に権限を削除する）はないはずだと考えるでしょう。
PendingIntentのFLAG_IMMUTABLEとFLAG_MUTABLE - Kenji Abe - Medium
Target SDK 31(Android 12)から PendingIntent のmutability(可変性)を指定する必要があります。
FLAG_IMMUTABLE FLAG_IMMUTABLE を指定すると、パラメータを追加をしたとしても、元々のIntentは変更はされず、起動された側でも取得できずにnullになります。 ほとんどケースで FLAG_IMMUTABLE を指定することになると思います。
FLAG_MUTABLE FLAG_MUTABLE を指定すると、変更が可能となり、先程のパラメータを追加したときに、起動された側で取得することが出来ます。