GoogleがAndroid 17のPixel端末から始めたアプリ単位のメモリ制限が、他社製端末へ広がる。同社は2026年8月19日、今後1年をかけて採用する端末メーカーを増やし、物理RAMが4GBの構成から16GB超の構成まで対応範囲を広げる方針を明らかにした。端末全体が逼迫してからメモリを回収する従来の運用に加え、使い過ぎたアプリ自身を減速させ、最後には終了させる。対象がどこまで広がり、アプリ側で何を測り直す必要があるのか。それが開発者の判断を左右する。
Pixelから4GB〜16GB超へ
Android 17はAPI level 37であり、この制限は端末の総RAMに応じて設定される。Googleの説明では、targetSdkVersionを問わず、Android 17上で動く全アプリに関係する。新しいtargetSdkへ移行済みのアプリだけが対象になる互換性変更ではない。既存アプリを含めて、メモリの使い方を見直す必要がある。
ただし、Android 17端末なら一律に適用されるわけではない。GoogleのAndroid 17の挙動変更ページは、制限の対象を「一部のAndroid端末」としている。8月19日のブログも、今後1年で採用メーカーを増やす方針を述べたにとどまり、メーカー名、対象機種、展開開始日は挙げていない。全メーカー、全端末への義務化や、Android 17搭載端末すべてへの即時導入と受け取ることはできない。
今回に先立ち、GoogleはAndroid 17のメモリ効率を優先する方針を示し、Pixel端末でアプリ別のメモリ制限を導入していた。8月19日の発表は、その仕組みをより広いRAMクラスと端末メーカーへ展開する計画を具体化したものだ。Googleは背景として、物理メモリの価格上昇を受け、新端末の搭載RAMが横ばいまたは減少していると説明する。これは同社の展開理由であり、独立した市場データを示したものではない。
端末のRAM容量が大きくても、メモリを多く使うアプリが常に安全になるわけではない。総RAMに応じたアプリごとの予算が置かれるため、開発者は端末の容量表示に加え、対象端末上で自分のプロセスがどの程度の実使用量に達するかを確認しなければならない。具体的な予算値は公開されていない。
zRAMで減速し、その先で終了する
アプリが割り当てられた予算に達すると、システムはそのページをzRAMへ送る。zRAMは圧縮したデータをRAM内で保持する仕組みであり、圧縮と展開にはCPUの処理が要る。そのため、メモリを使い続けるアプリは、直ちに落ちる前にUIのカクつきや動作の減速として影響を受け得る。
zRAMの閾値を越えても使用量が増え続ければ、システムはプロセスを終了する。Googleは、この終了には通常のスタックトレースが伴わないと案内している。クラッシュのログだけを探す運用では、メモリ制限による終了と見分けにくい。画面上では遅延として始まり、最終的にプロセスが消える。性能問題と終了後の復帰を、同じシナリオで検証する必要が出てくる。
Androidには従来からアプリのヒープ容量にハード上限がある。加えて、Low Memory Killer Daemon（lmkd）は端末全体のメモリ圧迫を検知し、oom_adj_scoreに基づいて重要度の低いプロセスから終了させる。フォアグラウンドサービスなどで保護された大きなアプリが残る状況では、キャッシュ済みアプリやバックグラウンド処理が先に落ちることがある。
アプリ別の制限は、端末全体のメモリが逼迫する前から過剰利用へ対処する。割り当てを超えたアプリのページをzRAMへ押し出し、なお使用量が増えればそのプロセスを終了させる。Googleが説明する狙いは、メモリを使い過ぎるアプリが他のアプリへ与える影響を抑えることにある。とはいえ、zRAMへ移す厳密な判定式や、端末ごとの予算計算方法は公開されていない。
平均値ではなく裾を見る
Google Play ConsoleのAndroid vitalsでは、Anonymous RSS + swapをメモリの監視指標として確認できる。匿名メモリにはJava/Kotlinヒープ、ネイティブヒープ、スレッドスタックなどが入る。端末のRAMクラスとプロセス状態ごとにP50やP90を見られるため、全ユーザーの平均だけでは捉えにくい、使用量が伸びるセッションを切り分けられる。
Googleは、P90とP50の比率が3.5倍を超える場合を、長時間セッションでのメモリリーク候補を探す目安として案内する。ただし、高い比率だけでリークと断定はできない。ユースケースによっては、限られた利用者が大きなデータを扱うことで裾が長くなることもある。RAMクラス、フォアグラウンドかバックグラウンドか、SDKが別プロセスを作っていないか。これらを分けて見る必要がある。
制限による終了を受けたセッションは、ApplicationExitInfo.getDescription()で確認できる。reasonはREASON_OTHERで、descriptionにMemoryLimiter:AnonSwapが含まれる。この印を復帰処理や分析基盤で捕捉すれば、通常のクラッシュとは異なる経路として扱える。終了時にスタックトレースがないという条件を補う手掛かりになる。
さらに、Android 15（API level 35）で導入されたProfilingManagerは、TRIGGER_TYPE_ANOMALYを使い、メモリ制限に達した時点のヒープダンプを収集できる。再現環境ではadbのam memory-limiterも使える。サブコマンドはignore、manual、statusの3つで、manualではPIDとMB単位の上限を指定する。公式文書は30MBを例に示しているが、制限に対応しない端末ではこの機能は動かない。
診断は、数値を眺めるだけでは終わらない。上限へ近づいたときに画面状態を保存できるか、再開時に必要なデータを戻せるか、重い操作の途中でUIがどこまで遅くなるか。これらを実機か再現コマンドで確かめることになる。Android vitalsで裾の長いRAMクラスとプロセスを絞り、終了情報やヒープダンプで再現経路を追う。そうすれば、平均的な端末では見えないメモリ消費を調べられる。
高メモリアプリに残る不確定要素
今回の発表で、採用が広がる時間軸と、4GBから16GB超までを含むRAM構成は示された。一方で、どのメーカーのどの機種がいつ採用するのかは分からない。RAMクラス別の既定上限値や、可視・不可視のプロセスに与えられる具体的な予算も公表されていない。アプリのメモリ使用量から、制限に達する時点を一般式で計算することはまだできない。
Anonymous RSS + swapはGoogleが診断と監視を案内する指標だが、それが制限の唯一の算定値だと断定する根拠はない。zRAMへの退避から終了へ移る条件も同様である。開発側は、公開値が出るまで架空の閾値を置くより、制限を実装したAndroid 17端末ごとに実測し、メモリを大きく使う画面と長時間セッションを優先して検証する方が確実だ。
メモリを多く使う機能を持つアプリほど、端末側の採用状況が公開された後の確認が早く求められる。採用機種、RAMクラス別の実際の振る舞い、終了後に状態を保てるかを確認して初めて、今回の制限が利用者の体験へどう効くかを判断できる。
