マニフェストに BroadcastReceiver が登録されていて、アプリがアクティブでないとします。したがって、新しいプロセスが生成され、BroadcastReceiver の onReceive() メソッドがこの新しいプロセスのメイン スレッドでトリガーされます。
ここで、onReceive() メソッドからスレッドを生成します (これは推奨されておらず、onReceive() を超えてプロセスの寿命を延ばすために Service を使用する必要があることはわかっています)。
生成されたスレッド（無期限に実行されると仮定しましょう）がプロセスを存続させ続けるのは興味深いですか？JVM について考えると、JVM はアクティブな非デーモン スレッドが存在するまで終了しないためです。そしてARTはどうですか？ART は JVM ではなく、コンパイラであり、コンパイルされたアプリケーションの動作は異なる場合があります。たとえば、プロセスを強制終了し、実行中かどうかに関係なくすべてのスレッドを強制終了するなどです。誰かがこの状況についての洞察を持っていますか?
それはすべて、実行環境と OS 次第です。 コードがコンパイルされているか解釈されているかは、プロセス/アプリの強制終了の決定には影響しません。
長いバージョン:
いくつかのことを明確にするために: ART はコンパイラではありません。実行環境です。dex2oat はコンパイラ ドライバです。そして、あなたのシナリオを正しく理解していれば、ブロードキャストが OS に配信され、OS がアプリケーションを起動します。そして、onReceiveメソッドでスレッドを起動します。
アプリケーションは 100% AOTコンパイルされていない可能性があります。これは、いくつかの部分が ART によって解釈されることを意味しますが、ほとんどは ART によってネイティブに実行されます。つまり、ART はインタープリターも備えたランタイムです。ブロードキャスト ハンドラでスレッドを強制終了するかどうかの決定は、コードがネイティブに実行されるか解釈されるかに依存しません。OS は、メモリが少なくなったときにプロセスを強制終了することを決定したり、ランタイムが永久に実行されていることを検出した場合に実行を中断したりすることがあります。
したがって、コンパイルされたコードについて心配する必要はありません。OS (サービス?) をうまく操作してください。