キャッチされていない例外が原因で Android サービスが強制終了されるのを防ぐ方法があるかどうかを調査しています。
5 ～ 6 個のサービスと通信する 10 個の UI アプリがあります。プラットフォームは Android 2.2 です。
予期しない状況により、サービスのロジックの一部が時々例外をスローしています。これにより、迷惑な ANR ポップアップでこれらのサービスが停止されます。これらの例外の根本的な原因を修正するソリューションに取り組んでいますが、Android が問題のあるサービスを強制終了しないようにしたいと考えています。
サービス内のすべてのスレッドに対して Uncaught のデフォルトの例外ハンドラを登録できるようです。これは、例外に関する何かをログに記録する機会を与えてくれます。それはいいです。後で使用するために、この手法を使用してクラッシュ情報をファイルに記録する多くの投稿に出くわしました。人々は、ANR ポップアップを防ぐために元の例外をスローしないことを提案しました。また、サービスが半減状態になる可能性があることを示唆する記事もいくつか見つけました。正しいことは、サービスを強制終了して再起動することです。強制終了して再起動することは、私が興味を持っているオプションではありません。
例外をスローしない場合の半死状態の部分がよくわかりませんでした。さらに調査するつもりです。その間、人々に提案があるかどうか疑問に思っています。
私の目標は、ANR ポップアップを防ぐことです。Android フレームワークがサービスを再起動するかどうかを決定するのではなく、コードでサービスを再起動するかどうかを決定する必要があります。
私が見つけたいのは次のとおりです
。1）サービスがフレームワークコードによって強制終了されるのを防ぐために変更できるマニフェストにフラグはありますか？
2)キャッチされていない例外を処理できるようにするサービスでオーバーライドできるメソッドはありますが、サービススレッドはクライアントからの次の要求を待機状態に戻すことができますか?
提案をありがとう。
ビデオガイ
更新:
Uncaught の既定の例外ハンドラーは、ここでは役に立ちません。何かをログに記録する機会が得られますが、サービス スレッドは引き続き終了します。
プロセスを強制終了しないように、Android フレームワークを変更する必要があります。AndroidフレームワークのActivityManagerService.javaには、クライアントなしでサービスを実行できる時間、バックグラウンドアクティビティ/サービスの数、サービスとUIの初期化のタイムアウトなど、さまざまなしきい値があります。これらの値を上げました。