私の要件:電源イベントを検出して応答します。ユーザーが応答を設定できるアクティビティがあります。UI がバックグラウンドに移行した後も、アプリは応答し続ける必要があります (ユーザー アクション、つまり「ホーム」、または電話の受信など)。
私の分析：
- ACTION_POWER_DISCONNECTED (および ..CONNECTED) を受け入れる BroadcastReceiver を使用する
- アクティビティ内にレシーバーを実装しましたが、期待どおりに動作します。しばらくの間バックグラウンドで動作し続けますが、通常の Android ライフサイクルのために最終的に動作を停止します。OSはそれを破壊します。
- (提案) 受信機を実行し続けるために、私はこの推奨に従い、それをサービスにし
startForegroundます。 - (提案) UI と対話する必要があるため、つまり、設定の変更を受け入れる必要があるため、バインドされたサービスにする必要があります。
予想される問題:
ドキュメントによると、バインドされたサービスは、すべてのクライアントがバインド解除されると停止します。onDestroyメソッドでアンバインドするクライアント (UI) は 1 つだけです。これは、クライアントが OS によって停止されたときに呼び出されます。これは、通常のリソース管理の下で最終的に発生します。
アプリケーション コンポーネントが bindService() を呼び出してサービスにバインドすると、サービスは「バインド」されます。バインドされたサービスは、コンポーネントがサービスとやり取りしたり、要求を送信したり、結果を取得したり、プロセス間通信 (IPC) を使用してプロセス全体でそれらを実行したりできるようにするクライアント サーバー インターフェイスを提供します。バインドされたサービスは、別のアプリケーション コンポーネントがバインドされている間だけ実行されます。一度に複数のコンポーネントをサービスにバインドできますが、すべてのコンポーネントがバインド解除されると、サービスは破棄されます。
質問
- この分析は正しいですか？すなわち。1 つの UI クライアントにバインドされたサービスは、通常の OS 管理の一環として、クライアントが破棄されると最終的に破棄されますか?
- もしそうなら、私はそれについて何をすべきですか？
- 他のヒントをください:)
バインドされたサービスをセットアップし、期待どおりに停止することを証明する作業がかなりあるため、仮説として尋ねられました。また、動作しているように見えても、間違っている可能性があります。