3行まとめ
Android 17では、デバイスの総RAMに基づくアプリメモリ制限が導入される。
影響を受けた場合は、ApplicationExitInfo.getDescription() に含まれる記述を確認する。
LeakCanary、Android Studio Profiler、ProfilingManager、R8、画像最適化、onTrimMemoryを並べて確認する。
クラッシュログだけでなく、終了理由、リーク、画像、バックグラウンド時の解放まで一続きで見る。
- Android 17では、デバイスの総RAMに基づくアプリメモリ制限が導入される。公式ドキュメントは一部のAndroidデバイスに課される制限として説明しており、すべての端末で同じ条件が一律に動くとは読まないほうがよい。
- 影響を受けた場合は、
ApplicationExitInfo.getDescription()にMemoryLimiter:AnonSwapを含むかを確認する。通常のJava例外やANRだけを見ていると、システム側のメモリ制限による終了を見落としやすい。 - 開発チームは、LeakCanaryとAndroid Studio Profiler、ProfilingManagerの
TRIGGER_TYPE_ANOMALYとTRIGGER_TYPE_OOM、R8、画像最適化、onTrimMemoryを同じチェック表に入れて、Android 17対応を互換性テストと品質改善の両方で進めたい。
Android 17のメモリ制限は、見出しだけ読むと「Android 17でアプリが急に落ちる新仕様」に見えやすい。実際には、Googleの公式説明はもっと落ち着いている。対象はデバイス総RAMに基づくアプリメモリ制限で、初期の制限は保守的に設定され、極端なメモリリークや外れ値を先に抑える位置づけだ。
それでも、Androidアプリを運用するチームにとっては無視しにくい変更だ。理由は単純で、メモリ問題はクラッシュログだけでは見えないことが多いからだ。画像一覧で少しずつ増えるbitmap、画面遷移後も残るActivityやContext、Foreground Service中のキャッシュ、バックグラウンド復帰時の重い再生成は、ユーザー体験としては固まり、電池消費、cold start、セッション喪失として現れる。
この記事では、2026年6月14日時点で確認できるAndroid Developersの公式情報をもとに、Android 17のメモリ制限対応を開発チームのチェックリストへ落とし込む。需要シグナルとしては、Android Developers公式ブログに加え、専門メディアや開発者コミュニティでAndroid 17 memory limitsへの反応が続いている。ただし、本文の事実認定はAndroid Developers Blog、Android Developers docs、API referenceなどの一次情報に限定する。
Androidの利用条件やプラットフォーム更新を続けて追う場合は、当サイトの<a href="https://googl-watch.blog.mo-gmo.com/category/products-services-solutions/">製品・サービス・ソリューション</a>カテゴリ、2026年6月の発表を時系列で見るなら<a href="https://googl-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>も確認してほしい。Alphabet Watch JapanはAlphabetおよびGoogleとは非提携のメディアであり、本記事は投資助言ではなく、公式情報をもとにした製品・開発者向け確認メモだ。
Android 17のメモリ制限で何が変わるのか
公式ドキュメントは、一部のAndroidデバイスに課される制限として説明している。
通常のJava例外やANRだけでは、システム側のメモリ制限による終了を見落としやすい。
画像、動画、Foreground Service、複数プロセス、バックグラウンドキャッシュを優先して見る。
Android 17対応を、targetSdk更新だけでなくメモリの基準線を下げる機会として扱う。
「保守的」「一部デバイス」は準備不要という意味ではなく、まず観測できる状態にするための前提として読む。
Android 17で見るべき変化は、アプリが使えるJava heapの上限だけではない。公式のbehavior changesでは、Android 17がデバイス総RAMに基づくアプリメモリ制限を導入し、より安定した環境を作るための変更として説明されている。制限は保守的に設定され、極端なメモリリークや外れ値が、UIのひっかかり、電池消費、他アプリの終了につながる前に抑える狙いがある。
まず押さえたいのは、これは「すべてのAndroid 17端末で同じ数値の上限が必ず課される」という話ではないことだ。公式ドキュメントは、メモリ制限が一部のAndroidデバイスに課されると明記している。したがって、記事やSNSの要約だけを見て、自社アプリが今すぐ全端末で落ちると決めつける必要はない。
一方で、対象端末が一部だから準備不要とも言えない。長時間セッション、画像や動画の多い画面、Foreground Service、複数プロセス、バックグラウンドキャッシュ、広告やSDKの保持、ComposeとViewの混在があるアプリは、Android 17対応の中でメモリの基準線を作っておく価値がある。
制限は一部端末で保守的に始まる
根拠
Android Developersのbehavior changesは、Android 17がデバイス総RAMに基づくアプリメモリ制限を導入すると説明している。同じページでは、制限が一部のAndroidデバイスにのみ課されることも示されている。Googleの6月2日の公式ブログも、Android 17ではメモリ最適化に加えて、より厳しいメモリ要件に備えるためのツールとAPIを提供すると説明している。
この記事では、この2点を分けて読む。1つは、Android 17にメモリ制限という新しい観測・終了の経路が入ること。もう1つは、現時点の公式説明では、制限の適用範囲や値を全端末一律として扱っていないことだ。
注意点
「保守的」「一部デバイス」と書かれているからといって、開発チームが後回しにしてよいとは限らない。特に、ユーザーが長時間使うアプリ、画像一覧や動画、マップ、チャット、カメラ、決済、ナビゲーション、業務用常駐アプリでは、メモリ増加がユーザーの離脱やデータ喪失に直結しやすい。
対象端末で初めて問題が出てから調査を始めると、再現条件が複雑になりやすい。Android 17対応では、まず自社アプリのpeak memory、復帰時の再読み込み、LMKやOOMの傾向、画面遷移後の保持オブジェクトを確認するのがよい。
超過時は通常のクラッシュ調査と見え方が違う
確認項目
公式ドキュメントは、メモリ制限の影響を受けたアプリセッションについて、ApplicationExitInfo.getDescription() を確認する方法を案内している。影響を受けた場合、exit reasonは REASON_OTHER になり、descriptionには MemoryLimiter:AnonSwap を含む。
これは、通常のKotlinやJavaの例外とは見え方が違う。スタックトレースを伴うクラッシュだけを見ていると、システムがメモリ制限によってプロセスを終了したケースを別の終了理由として扱ってしまう可能性がある。既存のクラッシュ基盤や独自ログで、OS側の終了理由を見られるかを先に確認したい。
評価基準
最低限、日付、端末、API level、アプリバージョン、プロセス名、foregroundかbackgroundか、直前画面、ApplicationExitInfo のreasonとdescriptionをひもづけて見られる状態にする。MemoryLimiter:AnonSwap が出たかどうかだけではなく、どの画面や操作に偏るかを見る。
件数が少ない段階では、再現手順を探すより分類を優先する。フィールドでしか出ない長時間利用、低RAM端末、バックグラウンド復帰、端末全体のメモリ状態は、手元の短いテストでは再現しにくい。
Android 17対応は互換性テストと品質改善の両方で見る
条件
Android 17 Beta 4の公式ブログでは、開発者に最終的な互換性テストとアプリ更新準備を促している。メモリ制限はその中の1テーマだが、対応は単に「落ちるかどうか」を見るだけでは足りない。
検証対象にしたいのは、長時間の画面遷移、画像一覧から詳細への往復、動画再生、カメラ、地図、ログイン切り替え、アカウント切り替え、バックグラウンド復帰、Foreground Service中のメモリ増加、push通知後の起動などだ。ユーザーが日常的に踏む経路を、メモリの観点で測る。
MemoryLimiter:AnonSwapを検出できるようにする
- 1ApplicationExitInfoを見る
まずセッション終了の情報を取得し、descriptionにMemoryLimiter:AnonSwapが含まれるか確認する。
- 2終了理由を分ける
クラッシュ、ANR、LMK、MemoryLimiter、ユーザー操作による終了を分類する。
- 3優先度を変える
MemoryLimiter由来の終了は、メモリ使用量が端末条件に近いことを示す手がかりとして扱う。
- 4確認日を残す
description文字列は公式案内として利用し、Android 17 docs更新時に見直せるようにする。
最初の目的は再現ではなく分類。終了理由が分かると、調査ルートと修正候補を選びやすくなる。
MemoryLimiter:AnonSwap は、Android 17のメモリ制限対応で最初に作りたい観測ポイントだ。これはユーザー向けに表示する文言ではなく、開発チームが終了理由を分類するための手がかりとして扱う。
既存の監視で、Java例外、Native crash、ANR、LMK、ユーザー操作による終了、システム都合の終了が同じ箱に入っているなら、Android 17対応の前に分類を見直したい。MemoryLimiter由来の終了は、アプリのバグを直接示すとは限らないが、メモリ使用量が端末やOSの許容範囲に対して大きくなっているサインにはなる。
ApplicationExitInfo は終了理由を見る入口になる
根拠
Android Developers Blogとbehavior changesの両方で、ApplicationExitInfo.getDescription() が案内されている。公式説明では、メモリ制限の影響を受けた場合、descriptionに MemoryLimiter:AnonSwap を含むとされている。
開発チームでは、これをクラッシュレポートの1項目として扱うより、セッション終了の分類軸として扱うほうがよい。クラッシュ、ANR、MemoryLimiter、LMK、ユーザーによる終了を分けることで、優先度と調査ルートが変わる。
注意点
description文字列を、将来も永遠に変わらない仕様としてコードに強く焼き込むのは避けたい。2026年6月14日時点の公式案内として利用し、公開後にAndroid 17 docsが更新された場合は見直す。記事公開後にチーム内のチェックリストへ転記する場合も、確認日と公式URLを一緒に残す。
クラッシュ、ANR、LMK、MemoryLimiterを分ける
確認項目
終了理由の分類は、次のように見ると調査が楽になる。
| 分類 | 主な見方 | 初動 |
|---|---|---|
| Java/Kotlin例外 | stack trace、例外型、画面 | 再現と修正箇所の特定 |
| Native crash | native stack、端末、ABI | SDK、NDK、端末依存の切り分け |
| ANR | main thread、binder、I/O | ブロッキング処理と入力応答の確認 |
| LMK | 低メモリ状態、プロセス優先度 | 端末全体のメモリ圧とバックグラウンド保持の確認 |
| MemoryLimiter | ApplicationExitInfo のdescription | アプリ単体のメモリ増加、画面、セッション長の分類 |
この分類を作っておくと、「Android 17で落ちたらしい」という曖昧な報告を、どの種類の終了として扱うか決めやすくなる。
評価基準
合格条件は、MemoryLimiter:AnonSwap の有無だけをログに出すことではない。日次やバージョン別に集計でき、画面、端末、OS、ユーザー操作の直前情報と合わせて見られることだ。特定画面に偏るなら、その画面の画像、cache、listener、ViewModel、SDK、広告、動画バッファを疑う。端末やOSに偏るなら、端末メモリと制限適用の条件を優先して見る。
チームの初動は再現ではなく分類から始める
下振れ
フィールドで出たMemoryLimiter由来の終了を、最初から手元で完全再現しようとすると時間を失いやすい。ユーザーの端末状態、他アプリの動作、長時間利用、メモリ断片化、画像キャッシュの履歴は再現しづらいからだ。
まず件数を分類し、アプリバージョン、画面、端末、セッション長、直前操作の偏りを見る。そのうえで、偏りが大きい領域をローカル再現やProfiler調査へ回すほうが、調査の順番として自然だ。
ローカルでは am memory-limiter で制約を試す
- 1statusを確認する
対象デバイスでMemory Limiterの状態を見て、手動制限やignore設定が残っていないか確認する。
- 2manualで制約をかける
プロセス単位でメモリ制約を課し、どの操作で増え、どのタイミングで戻らないかを見る。
- 3ログとProfilerを残す
PID取得、テスト用ビルド、ログ取得、Profiler記録、検証後の戻し方を1つの手順にする。
- 4ignoreで比較する
制限がある状態と無視した状態を比べ、通常動作との差を確認する。
小さな制限値で落とすこと自体より、増え続ける資源や戻らないキャッシュを見つけることが重要。
Android Developersのbehavior changesでは、ADBの am コマンドに含まれる memory-limiter サブコマンドが案内されている。対象デバイスで現在の状態を見たり、手動で制限をかけたり、制限を無視する設定にしたりできる。
ただし、公式ドキュメントは、これらのコマンドがメモリ制限を課さないデバイスでは効果を持たないとも説明している。つまり、コマンドを打った結果だけで「対応不要」と決めないほうがよい。使っている端末が制限対象なのか、テスト用ビルドで十分にログを取れるのか、検証後に状態を戻せるのかをセットで見る。
まず現在の制限状態を確認する
確認項目
am memory-limiter status は、対象デバイスでMemory Limiterの状態を確認する入口になる。最初にこの状態を見て、端末が制限を課す環境なのか、手動制限やignore設定が残っていないかを確認する。
開発チームでは、手順書に「statusを確認してからmanualを使う」「検証後にもう一度statusを見る」という流れを入れておきたい。過去の検証設定が残ったまま別のテストをすると、結果の解釈が崩れる。
手動制限は再現テスト用に使う
条件
am memory-limiter manual <pid> <limit>|max|none は、プロセス単位でメモリ制約を課して挙動を見るために使う。検証では、PID取得、テスト用ビルド、ログ取得、Profiler記録、検証後の戻し方を1つの手順にする。
小さな制限値を入れてアプリを落とすだけでは、役に立つ情報は少ない。大事なのは、どの操作でメモリが増え、どのタイミングで戻らず、どのキャッシュや画面が残り続けるかを見ることだ。
注意点
manual制限は、開発端末や検証端末で使うものとして扱う。本番ユーザーに近い条件で見る場合も、ログ、データ、アカウント、個人情報の扱いを先に決める。heap dumpやprofileには機密情報を含む可能性があるため、保存場所とアクセス権を曖昧にしない。
ignoreは通常動作との比較に使う
評価基準
am memory-limiter ignore <uid>|none|all は、制限の有無で動作差を見る比較に使える。例えば、同じ操作を制限ありと制限なしで走らせ、メモリ増加、復帰時間、cold start、ログの違いを見る。
検証後は、none などで前回の設定を戻すことを明示する。戻し忘れは、次のテスト結果を汚す。コマンド表には、実行目的だけでなく「戻し方」と「確認するログ」も入れておきたい。
LeakCanaryとAndroid Studio Profilerでリーク調査を短くする
Android Studio PandaのLeakCanary統合を使い、IDE内でリーク解析へ進みやすくする。
警告を全部直すのではなく、ライフサイクル、ユーザー影響、再現頻度、修正コストで見る。
LocalContext、DisposableEffect、AndroidView、state holderやlambdaの保持を確認する。
Activity、Fragment、View、Adapter、listener、callback、bindingの残り方を確認する。
リーク修正は、メモリ制限対応で最初に効果が出やすい候補として優先度を付ける。
MemoryLimiter由来の終了が疑われる場合、最初に疑いたいのはメモリリークだ。Android Studio preview featuresでは、Android Studio PandaにLeakCanary統合のProfiler taskが入り、メモリリーク解析をテスト端末から開発マシンへ移せると説明されている。IDE内でソースへジャンプできる点も、調査時間を短くするうえで大きい。
ここで重要なのは、LeakCanaryを「警告が出たら全部直す道具」として扱わないことだ。保持経路、ライフサイクル、ユーザー影響、再現頻度、修正コストを見て、MemoryLimiter対応として先に直すべきものから並べる。
Android Studio PandaのLeakCanary連携を使う理由
根拠
Android Studio preview featuresは、PandaにLeakCanary統合が直接Profiler taskとして入ると説明している。LeakCanaryの解析を端末側ではなく開発マシン側へ移すことで、解析フェーズの負荷を下げ、IDE内のJump to Sourceなどの導線で修正箇所へ移りやすくなる。
この説明は、2026年6月14日時点ではpreview featuresの文脈にある。記事では、安定版の永続的なUI手順として細かく断定せず、Panda系のpreview機能として扱う。
注意点
Android Studioのプレビュー機能は、名称、チャンネル、UI文言、提供タイミングが変わる可能性がある。チームの正式手順に入れる前に、Android Studio preview featuresとrelease updatesを開き直す。安定版だけを使う組織では、Heap Dump、Android Vitals、既存のLeakCanary導入、Perfettoを組み合わせる。
ComposeとViewでリークの型を分ける
確認項目
Composeでは、LocalContext.current をViewModelへ渡す、DisposableEffect の破棄処理が空になっている、AndroidView のrelease処理がない、state holderやlambdaがContextを捕まえている、といったケースを疑う。Viewベースでは、ActivityやFragment、View Bindingを破棄後も保持する、listenerやreceiverを解除しない、static参照で短命なUIオブジェクトを持つ、といったケースが候補になる。
どちらのUI方式でも、画面回転、戻る操作、タブ切り替え、ログアウト、アカウント変更、画像詳細から一覧への往復をテストに入れるとよい。短いhappy pathだけでは、リークは見えにくい。
評価基準
LeakCanaryの検出結果は、保持サイズ、保持経路、再現頻度、ユーザー影響、修正コストで並べる。たとえば、ほとんど使われない画面の小さな保持より、毎日使う画像一覧でActivityを保持する問題のほうが先だ。Android 17のメモリ制限対応では、「検出数をゼロにする」より「ユーザーの長時間利用で積み上がる保持を減らす」ことを優先する。
リーク修正はメモリ制限対応の最優先候補になる
上振れ
リーク修正は、Android 17だけに効く対策ではない。長時間利用後のGC頻度、UIのひっかかり、cold start、バックグラウンド復帰、電池消費にも効く可能性がある。MemoryLimiter由来の終了がまだ出ていないアプリでも、LeakCanaryとProfilerで基準線を作っておく価値はある。
ProfilingManagerでフィールドのOOMとAnomalyを拾う
heap dumpやprofileには個人情報や機密情報が含まれる可能性があるため、観測範囲と削除手順を先に決める。
ローカルで再現できるメモリ問題は、ProfilerとLeakCanaryで追いやすい。難しいのは、特定端末、長時間利用、特定ユーザーの操作履歴、バックグラウンド状態でだけ出る問題だ。そこでは、ProfilingManagerとtrigger-based profilingが候補になる。
Android Developersのメモリ管理ページは、ProfilingManagerを、トリガーに基づいて本番ユーザーのデータを収集し、再現しにくいメモリ問題を見つけるための高度な観測APIとして説明している。Android 17で特に関係するのが、TRIGGER_TYPE_OOM と TRIGGER_TYPE_ANOMALY だ。
OOM triggerはOutOfMemoryError時のheap dumpを見る
根拠
ProfilingTrigger API referenceでは、TRIGGER_TYPE_OOM がAPI level 37で追加され、アプリがOut Of Memory Exceptionを起こしたときにJava heap dumpを提供すると説明されている。OOMは従来からある問題だが、Android 17対応では、OOMを単独のクラッシュとして見るだけでなく、メモリ制限やリーク調査と同じ観測設計に入れる。
注意点
カスタムの Thread.UncaughtExceptionHandler を使っている場合は、default uncaught exception handlerへ処理を渡さないと、このtriggerを使えないとAPI referenceに記載されている。独自クラッシュ基盤を持つアプリでは、例外ハンドリングを確認する必要がある。
Anomaly triggerはMemoryLimiterに近い現象を見る入口になる
根拠
Android Developers Blogとbehavior changesは、TRIGGER_TYPE_ANOMALY を使ったtrigger-based profilingで、メモリ制限に達したときのheap dumpを取得できると案内している。メモリ管理ページでも、Android 17で導入されたメモリ制限を超えた場合、システムがプロセスを止める前にAnomaly triggerが発火する例が示されている。
条件
Anomaly triggerは、全ユーザーに無制限で仕込むものとして考えない。heap dumpやprofileには個人情報や機密情報が含まれる可能性がある。取得対象、保存期間、アップロード先、アクセス権、削除手順、マスキング、社内承認を決めてから使う。
候補になるのは、ローカルで再現しづらい、特定端末や長時間セッションでだけ膨らむ、MemoryLimiter由来の終了が疑われる、既存のクラッシュログでは原因が見えないケースだ。
PerfettoのHeap Dump Explorerまで導線を置く
確認項目
公式ブログでは、取得したheap dumpをPerfetto UIへ読み込み、Heap Dump Explorerで見る流れも紹介している。確認対象は、retained size、GC rootへの経路、bitmap過多、ActivityやContextの保持、キャッシュ、SDK由来の保持オブジェクトなどだ。
評価基準
合格条件は、heap dumpを取ることではない。担当者が、再現不可のメモリ増加をissue化し、修正候補へつなげられることだ。取得、保存、解析、削除までの運用が決まっていなければ、ProfilingManagerを入れても現場の判断にはつながりにくい。
R8と画像最適化でメモリの基準線を下げる
アプリサイズ削減だけでなく、常駐コード、cold start、メモリ圧、画像の展開後メモリを同じ表で見る。
Android 17のメモリ制限対応は、観測だけでは終わらない。Googleの公式ブログは、R8によるbytecode最適化、画像ロード、LeakCanary、onTrimMemory、ProfilingManagerを並べている。これは、メモリ制限に引っかかるかどうかの前に、アプリの基準線を下げるという話だ。
特に画像は、ファイルサイズではなく展開後メモリで見る必要がある。小さなJPEGでも、表示時にはbitmapとして大きなメモリを使う。画像一覧、サムネイル、プロフィール画像、地図のタイル、動画サムネイル、広告画像、ユーザー生成画像を持つアプリは、画像ロード経路を別枠で棚卸ししたい。
R8はアプリサイズだけでなく常駐コードの削減として見る
根拠
公式ブログは、R8最適化によりresident codeを減らし、メモリフットプリント低減に寄与すると説明している。確認項目としては、isMinifyEnabled、isShrinkResources、proguard-android-optimize.txt、android.enableR8.fullMode = false の見直しがある。
アプリサイズ削減だけを目的にR8を見ると、Android 17対応としては狭い。常駐コード、起動、ANR、cold start、メモリ圧の観点でも見る。
注意点
keep ruleを削りすぎると、reflection、serialization、DI、SDK連携、プラグイン、動的ロードで壊れる可能性がある。広すぎるkeep ruleを削る場合は、Configuration Analyzer、ユニットテスト、E2E、QA、段階リリースを組み合わせる。R8の設定変更は、メモリ改善の近道である一方、壊れ方が実行時まで見えにくい。
画像は圧縮後サイズではなく展開後メモリで見る
確認項目
画像では、downsample、画像ファイルに不要なpaddingを焼き込まないこと、透過が不要な場合の RGB_565、vector drawable、bitmap pool、bitmap.recycle()、GlideやCoilの設定を確認する。ComposeとViewで画像ロード経路が分かれている場合は、両方を見る。
| 対象 | 見ること | 失敗しやすい点 |
|---|---|---|
| サムネイル | 表示サイズに合うdownsample | 原寸画像を小さな枠へ表示している |
| 一覧画像 | cacheと再利用 | スクロールのたびに大きなbitmapを作る |
| 透過なし画像 | pixel format | 画質や透過が必要な画像まで RGB_565 にする |
| ベクター化できる素材 | vector drawable | 写真系まで無理に置き換える |
| 手動bitmap管理 | recycleと参照破棄 | recycle後も参照を残す |
評価基準
peak memory、復帰後の再読み込み、スクロールjank、重複bitmap、画質、アクセシビリティをセットで見る。メモリだけ下がっても、画像が粗くなったり、再読み込みで体験が悪くなったりすれば、別の問題を作る。
Android Studio Profilerでduplicate bitmapも見る
注意点
公式ブログでは、Android Studio Narwhal 4のProfilerでduplicate bitmapsを見つける手順も紹介されている。今回のタイトルはPandaのLeakCanary連携を中心にしているが、画像最適化の章では重複bitmap検出も補助線として扱う。
同じ画像が複数回保持されている場合、キャッシュの粒度、画像キー、画面ライフサイクル、SDK側の保持を確認する。単にキャッシュを小さくするだけでは、再読み込みが増えてUXが悪化する場合もある。
onTrimMemory はUI非表示とバックグラウンドを中心にする
解放量だけで判断せず、バックグラウンド復帰やcold startに近い体験が増えないかも合わせて確認する。
onTrimMemory() は、Androidがアプリに「いまメモリを減らす機会だ」と伝える入口だ。Android Developersのメモリ管理ドキュメントは、TRIM_MEMORY_UI_HIDDEN と TRIM_MEMORY_BACKGROUND に集中すべきと説明している。Android 14以降は他のlegacy constantの通知が届かず、Android 15で正式にdeprecatedになった点も重要だ。
古いサンプルの分岐を大量に残していると、対応しているように見えて、実際に届くイベントに合っていないことがある。Android 17対応では、今の公式案内に合わせて、UI非表示とバックグラウンドの2場面で何を捨てるかを決めたい。
見るべきlevelを絞る
根拠
メモリ管理ドキュメントは、onTrimMemory() の実装を TRIM_MEMORY_UI_HIDDEN と TRIM_MEMORY_BACKGROUND に集中すべきと説明している。UIがユーザーから見えなくなったときと、プロセスがバックグラウンドにいるときでは、捨てられる資源が違う。
注意点
古い定数を大量に分岐して、対応したつもりになるのは避けたい。実際に届くイベントと、捨てる資源を結びつける。特に、画像キャッシュ、動画バッファ、画面専用の一時データ、プレビュー画像、機械学習モデル、データベース接続、ネットワーククライアントは、アプリごとに再生成コストが違う。
UI hiddenではUIに紐づく重い資源を捨てる
確認項目
TRIM_MEMORY_UI_HIDDEN では、UIに紐づく重い資源を候補にする。bitmap cache、動画再生バッファ、複雑なアニメーション、画面専用のプレビュー画像、戻ってきたときに再生成できる一時データだ。
ただし、すべてを捨てればよいわけではない。復帰時の再読み込みが長すぎると、ユーザーはcold startに近い体験をする。解放によるメモリ削減と、復帰時のUXを同時に測る。
backgroundでは再生成可能な資源をより積極的に捨てる
評価基準
TRIM_MEMORY_BACKGROUND では、プロセスがcached stateで長く残れるか、復帰時のcold startやjankが減るか、バックグラウンド処理が壊れないかを見る。バックグラウンドで保持している巨大なcacheや一時データは、MemoryLimiterやLMKのリスクを増やす。
評価では、解放前後のメモリ、復帰時間、通信量、再生成コスト、ユーザーが見た状態の保持を並べる。業務アプリや長時間入力があるアプリでは、状態喪失のリスクも確認する。
開発チームの対応優先度を決める
画像や動画が重い、長時間セッションが多い、Foreground Serviceやバックグラウンド常駐があるアプリを入れる。
Android 17対応やtargetSdk更新を予定しているアプリで、基準線の計測と監視を先に入れる。
大きなメモリ問題が見えていないアプリでも、終了理由の分類と公式情報の更新を追う。
MemoryLimiter検出、LeakCanary調査、R8設定、画像ロード経路、onTrimMemory、heap確認を別チケットにする。
ここでの優先度は投資判断ではなく、サービス品質とサポート負荷を下げるための実務判断。
最後に、Android 17のメモリ制限対応を、Now、Next、Watchに分ける。全アプリで同じ深さの調査をする必要はない。メモリリスクが高いアプリから、観測、再現、調査、改善を進める。
ここでの判断は、GOOGLやAlphabetの投資判断ではない。Androidを使うユーザー、開発者、導入企業にとって、サービス品質とサポート負荷を下げるための実務判断だ。
Nowに入れるアプリ
条件
画像や動画が重い、長時間セッションが多い、Foreground Serviceを使う、バックグラウンド常駐がある、LMKやOOMが既に多い、低RAM端末の利用者が多いアプリはNowに入れる。
確認項目
最初のスプリントでは、MemoryLimiter:AnonSwap の検出、LeakCanary調査、R8設定、画像ロード経路、onTrimMemory、Profilerでのheap確認を入れる。機能開発と同じチケットに混ぜず、互換性と品質改善の作業として扱う。
Nextに入れるアプリ
条件
直近で大きなメモリ問題はないが、Android 17対応やtargetSdk更新を予定しているアプリはNextに入れる。互換性テストの一部として、基準線の計測と監視だけ先に入れておく。
この段階では、大きなリファクタリングよりも、計測、分類、チーム内の見方をそろえることが大事だ。次にMemoryLimiter由来の終了が出たとき、どこを見るか決まっている状態にする。
Watchに置くアプリ
評価基準
利用セッションが短い、画像が少ない、端末条件が限られる、既存のメモリ監視が十分なアプリはWatchに置ける。ただし、Android 17端末のフィールドデータを見られるようにはしておく。MemoryLimiter:AnonSwap の件数が出始めたら、WatchからNowへ上げる。
次に読むなら
Android 17、Android Studio preview、Googleの公式発表を継続して追いたい場合は、読了後に<a href="https://googl-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>も確認してください。一次情報の扱い方は<a href="https://googl-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>でも整理しています。
参照した主な情報源
- Android Developers Blog: Prioritizing Memory Efficiency: Essential Steps for Android 17（確認日: 2026年6月14日）
https://android-developers.googleblog.com/2026/06/prioritizing-memory-efficiency-steps-for-android-17.html
- Android Developers: Behavior changes: all apps, Android 17（確認日: 2026年6月14日）
https://developer.android.com/about/versions/17/behavior-changes-all
- Android Developers: Manage your app's memory（確認日: 2026年6月14日）
https://developer.android.com/topic/performance/memory
- Android Developers Blog: The Fourth Beta of Android 17（確認日: 2026年6月14日）
https://android-developers.googleblog.com/2026/04/the-fourth-beta-of-android-17.html
- Android Developers API reference: ProfilingTrigger（確認日: 2026年6月14日）
https://developer.android.com/reference/android/os/ProfilingTrigger
- Android Developers: Release notes for Android Studio preview（確認日: 2026年6月14日）
https://developer.android.com/studio/preview/features
- Android Developers: Capture a heap dump（確認日: 2026年6月14日）
https://developer.android.com/studio/profile/capture-heap-dump
更新履歴
- 2026年6月14日
Android Developers Blog、Android 17 behavior changes、Android memory docs、ProfilingTrigger API reference、Android Studio preview featuresを確認。
Android 17 docsやAndroid Studio preview featuresは更新される可能性があるため、チームのチェックリストへ転記する場合も確認日を残す。
- 2026年6月14日: Android Developers Blog、Android 17 behavior changes、Android memory docs、ProfilingTrigger API reference、Android Studio preview featuresを確認し、初稿を作成。