Android17「アプリのメモリ上限」があなたのアプリへ与える影響

開発者コラム
スマホのアプリにメモリ上限が課せられ、そのうちAIサービスが優遇されていることを表現したイラスト。
スマホのアプリにメモリ上限が課せられ、そのうちAIサービスが優遇されているイラスト。

コラム概要

■こんな方におすすめ：

Android17の変更内容とアプリへの影響範囲を調べている方
メモリ上限の影響を具体的に評価したい方
低レイヤ層の仕組みに興味がある方

■難易度：★☆☆～★★☆

■ポイント：

  • Android17搭載端末は、任意のアプリで「アプリのメモリ上限(App memory limits)」が発動する
  • Pixel系は約9GBのメモリを使用後、アプリが30秒後に終了するが、原因の調査は困難な仕様となっている
  • メモリ上限はメーカーの設定次第で上下する仕様のため、廉価端末では上限設定が厳しくなる可能性がある
  • システム系/AIプロセス(AICore)はメモリ上限評価の対象外であり優遇されている
  • メモリ上限の影響を適切に避けるため、アプリ開発者は詳しい仕様を理解しておきたい
  • Google Playの配信要件の1つとして、Level Up ProgramsやApps Experience Programの要件にも関わるより厳しいメモリ使用量の指標が追加されることが発表されたため、アプリのメモリ使用量に着目した開発が必要となる

1. 公式仕様から読み解く「アプリのメモリ上限」

ユーザ向けのドキュメント*1-3にて広く説明されている内容は以下です。

  • メモリ上限のある端末かどうかは、以下のコマンドから確認可能
    adb shell am memory-limiter status
  • アプリのメモリ上限を超えたかどうかを、後からAPI(ApplicationExitInfo)で確認可能
  • ProfilingManagerに異常トリガー(TRIGGER_TYPE_ANOMALY)を新規追加
  • メモリ上限超過時に異常トリガーが発動した後、アプリは強制終了する
  • 異常トリガーから、開発者はヒープダンプを取得して問題を修正できる

システム開発者向けに、詳細仕様として説明されている内容*4は以下です。

  • メモリ上限を監視する「Memory Limiter」をAndroid 17にて導入
  • 負荷軽減と重要プロセスの生存を目的とし、個々のアプリのメモリ使用量を制限
  • /system/etc/memory-limiter-config.xmlにメモリ上限の具体的な値を記載
  • アプリのメモリ使用量がソフトリミット(memory.high)を超過すると、
    - アプリの匿名メモリがスワップアウトされ、上限を超えない調整が入る
    - アプリの実行速度低下やクラッシュの可能性がある
    - Memory Limiterが上限超過を検出し、環境情報取得などを実行可能

メモリ上限が有効な端末

Android 17正式版(CP2A.260605.012)のPixel 9, 10では以下のように確認できます。

adb shell am memory-limiter statusの出力
Memory limiter
  enabled                  limits=true              monitoring=true          killing=true             ignored=none
visibleMem=6144MB        visibleSwap=3072MB       notVisibleMem=3072MB     notVisibleSwap=3072MB
  started=153              watched=153              watch-failed=0           events=0                 false-events=0
  processes=153            process-hwm=153          red-poll=0               red-process=0  

monitoring：trueならメモリ上限が有効でプロセスの監視が行われている
visibleMem / notVisibleMem：ソフトリミット(memory.high)の具体的な値。
　　　　　　　　　　　　　　　※フォアグラウンド/バックグラウンドごと
visibleSwap / notVisibleSwap：ソフトリミット(memory.high)の超過時のスワップアウト上限
　　　　　　　　　　　　　　　※フォアグラウンド/バックグラウンドごと
events：プロセスがメモリ上限を超えた回数
processes：監視対象のプロセスの数

仕様の説明を読んで、以下のような疑問が残りました。
[A] どのようなテストを行えば、メモリ上限の検証ができるのでしょうか
[B] アプリがメモリ上限を超えた際に、どのように強制終了するのでしょうか
[C] アプリは異常トリガーから情報をいつ、どのように受け取ることができるのでしょうか
[D] ヒープダンプをどのように解析し、メモリ上限の問題を修正すればよいのでしょうか

Googleによれば「ほとんどのアプリセッションへの影響は最小限になると予想されます」*1とのことですが、実体の不明瞭な仕様を安全と判断することは困難です。
また、2027年2月にGoogle Playの配信要件にメモリ使用量に関する指標が追加される*5, 6ことに関連し、今後メモリ上限に関するより詳細な情報や追加の診断ツールが提供される*5ことが発表されていますが、現状の仕様には不明な点があります。 具体的に実験して確かめてみましょう。

2.「アプリのメモリ上限」の詳細仕様を実証

メモリ上限有効端末上でテストアプリをフォアグラウンドにて動作させ、メモリ上限の強制終了過程を実験的に確認しました。
・Native Heap(匿名メモリ)の確保にmalloc APIを利用
・端末のソフトリミット(memory.high)は以下
　Native Heap / SWAP = 6GB / 3GB (フォアグラウンド)
　Native Heap / SWAP = 3GB / 3GB (バックグラウンド)

[結果]
時系列T0．Native Heapの確保開始
時系列T1．Native Heapがソフトリミット(memory.high)に到達し、増分はSWAPへ
時系列T2.  MemoryLimiterがAIプロセス(AICore)を監視から除外したログ
時系列T3. スワップアウト上限(Native Heap+SWAP)に到達
時系列T4. perfetto用のヒープダンプファイルが生成
時系列T5. T3から30秒後、AnonSwapのログと共にアプリプロセスが強制終了

上記のNative Heap確保過程をグラフ化すると以下となります。

アプリの強制終了後、ApplicationExitInfoから以下のように、メモリ上限により強制終了したことを確認できました。

10:37:08.939 17083 17083 D MemoryTest: Reason Code: 13
10:37:08.939 17083 17083 D MemoryTest: Description: [KILL PID] MemoryLimiter:AnonSwap

詳細を省きますが、以下のような傾向も確認できました。
・バックグラウンドの条件でもメモリ上限到達後の動作は同様
・状況によっては、perfetto用のヒープダンプファイルが生成されないことがあった

[perfetto用のヒープダンプファイル]
時系列T3でスワップアウトの上限に到達した直後のT4において、ヒープダンプファイルが出力される場合があります。
その場合、以下のようにファイル名と保存されるパスを確認することができます。

10:36:08.554 16979 16979 I perfetto:    perfetto_cmd.cc:1293 Wrote 15147403 bytes into /data/misc/perfetto-traces/profiling/profile_memorylimit_2026-07-06-10-36-07.perfetto-java-heap-dump

また、取得したヒープダンプファイルはperfettoにて表示すると以下のようになります。

Durationには944msと記載されており、今回の実験で出力されたヒープダンプからは瞬間的な記録しか得られませんでした。
また、0秒付近に終了したアプリのメインプロセス(PID=16496)のヒープダンプのグラフが作成されていますが、どの段階のメモリの使用状況が反映されたものであるか判断できない結果でした。

[分析]
ここまでの結果を踏まえ、仕様に関する疑問について次のように分析します。

[A] どのようなテストを行えば、メモリ上限の検証ができるのでしょうか
継続的にメモリを確保するテストアプリを用いるなどし、Native Heap/SWAPの視点からメモリ確保量を見積もることで、概ね仕様通りの挙動を確認することができます。

[B] アプリがメモリ上限を超えた際に、どのように強制終了するのでしょうか
ソフトリミットの超過だけではアプリプロセスは強制終了しません。
Native Heap+SWAPの合計を超過した後、Memory Limiterから30秒後にアプリプロセスが強制終了させられます。この間にヒープダンプファイルが生成されることがあります。

[C] アプリは異常トリガーから情報をいつ、どのように受け取ることができるのでしょうか
ProfilingManagerで新規に追加された異常トリガーを設定しない場合でも、perfetto用のヒープダンプファイルが出力されます。しかし、通常の端末ではアクセスすることができない専用の一時保存場所に出力されるため、ファイルを回収することが困難です。トリガーを設定することでファイルを端末の内部ストレージにコピーすることができ、ファイルの回収が容易になります。

[D] ヒープダンプをどのように解析し、メモリ上限の問題を修正すればよいのでしょうか
今回の実験で得ることができたヒープダンプファイルからは、どの時点のメモリの使用状況が反映されているかわからない瞬間的な情報しか得られませんでした。 今回のように十分な情報を得ることができない場合には、ヒープダンプをメモリ上限の対策に活用することは難しく、メモリ上限超過時の動作環境情報と照合する等、総合的な解析が必要であると考えられます。

[分析まとめ]
Googleの「ほとんどのアプリセッションへの影響は最小限になると予想されます」という説明は、実験的に確認する範囲では、少なくともPixel程度の十分なスペックのある端末では正しそうです。しかし、メモリ上限値はメーカーごとに設定できるため、廉価端末では影響がある可能性が否定できません。さらに、メモリ上限によりプロセスが終了してヒープダンプファイルが出力され、エンドユーザからファイルを収集できたとしても、ファイルの内容のみでは情報が足りず分析が困難である可能性があることから、リリースしたアプリから問題を特定することは難しいと予想されます。

3.「アプリのメモリ上限」はAIのための優先席か

Memory Limiterの監視の対象外となることがあったAICore*7は、端末内で完結するAIモデルGemini Nanoを実行するためのサービスです。
メモリ上限に関するドキュメント*4には、プリインストールされているアプリを含めてすべてのアプリがメモリ上限の対象となり、除外するための許可リストのようなものはないことが記載されていますが、今回の実験ではAICoreが対象から除外される様子が確認できました。
AIサービスを機能させるための重要な位置付けであるAICoreには、”優先席”が与えられていると推察されます。
また、スワップアウトせずに使えるメモリ量が制限されることで、アプリの動作に対して影響を与える可能性があることに加え、複数のアプリがメモリを奪い合う可能性も考えられます。
2027年2月にはGoogle Playの配信要件にメモリ使用量に関する指標が導入されることとなり、メモリ使用量を端末のメモリ容量に応じた閾値に収めることが、Apps Experience ProgramやLevel Up Programの基準を満たすために必要となります*6。 Android 17で導入されたメモリ上限について把握するとともに、メモリ使用量に留意した開発をすることが重要となります。

4.まとめ

本コラムではAndroid OS17で導入されたメモリ上限について、アプリに与える影響を検証した結果を紹介しました。
OSやメモリという低レイヤの視点を持つことで、今回のような新しい仕様の影響をより具体的に考察することができるようになります。
このような視点を取り入れ、メモリ使用量を考慮したアプリの開発に活かしてみてはいかがでしょうか。

5.参考

*1. Android17 動作の変更点 : すべてのアプリ - アプリのメモリ制限
https://developer.android.com/about/versions/17/behavior-changes-all?hl=ja#app-memory-limits
*2. アプリのメモリを管理する : ProfilingManagerを使用してメモリの問題を追跡する
https://developer.android.com/topic/performance/memory?hl=ja#profiling-triggers
*3. アプリの異常のプロファイリングトリガー
https://developer.android.com/about/versions/17/features?hl=ja#anomaly-profiling-trigger
*4. メモリ リミッター
https://source.android.com/docs/core/perf/memory-limiter
*5. アプリの品質向上：メモリ使用量の削減とデバイス移行の改善
https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html
*6. Play Consoleの技術品質要件
https://support.google.com/googleplay/android-developer/answer/17492799
*7. AICoreについて
https://support.google.com/android/answer/17065362?hl=ja

当サイトでは、本記事の他にもセキュリティエンジニアが執筆したコラムを公開しています。
アプリ開発やセキュリティ知識習得のご参考に、ぜひお役立てください。

開発者コラム

自社アプリのクラッキング対策について詳しく話を聞いてみたい方は、
当サイトからお気軽にお問い合わせください。

お問い合わせはこちら