Androidエンジニアの藤井です。

今回は Photoruction Build のAndroidアプリの16KBページ対応について実際に取り組んだ（又は取り組んでいる）ことについて書ける範囲ではありますが、紹介していこうかと思います。

16KBページ対応とは？

16KBページサイズ対応とは、Android OSがメモリを管理する際の最小単位（ページサイズ）を、従来の4KBから16KBに拡大することに伴い、アプリケーション側で必要な互換性の確保と最適化のことです。

📌 なぜ対応が必要なのか？

この変更は、特に大容量のRAMを搭載した現代のデバイスにおいて、パフォーマンスの向上と消費電力の削減を目的としています。

ページサイズを大きくすることで、OSがメモリを管理する手間が減り、メモリとストレージ間のデータ転送効率が向上します。これにより、以下のメリットが公式に示されています。

アプリ起動時間の短縮 🚀
システム起動時間の短縮
アプリ起動時の消費電力の削減 🔋

📝 開発者が対応すべきこと

Google Playのポリシーにより、Android 15以降をターゲットとするアプリは、16KBページサイズに対応することが必須となります。

Java/Kotlinのみで書かれたアプリは、通常、大きな変更は不要ですが、16KB環境での動作確認が推奨されます。
C/C++（ネイティブ）コードやネイティブライブラリ（.soファイル）を使用しているアプリは、16KBページサイズに対応するように再コンパイルなどの対応が必要です。

詳細については、Android Developersの公式ドキュメントを参照してください。

🔗 公式ドキュメント： 16 KB ページサイズのサポート | Compatibility - Android Developers

取り組んだこと

対応要否の調査

まず、当社のアプリでは一部提供されているライブラリにC++製のライブラリが存在しているので、提供元に問い合わせるところから始まりました。

こちらは後に既に問題ないことがわかったので、難なくクリアしました。

ただ、C++製のライブラリ以外でもネイティブライブラリ（.soファイル）を使用している箇所があり、詳細は割愛しますが、それらのライブラリの対応が必要であるとわかるまで調査に時間を費やしました。

最終的には公式で提供されているスクリプトでapkを解析して、使用されているライブラリのELFアライメントヘッダをチェックすることで確認するという情報に辿り着きました。

※ ここまでは筆者の知識不足故にかなり回り道をしてしまった気がしています。

対象となるライブラリの洗い出し

前述のスクリプトを使った調査では実際に下記のような手順で実行しました。

公式で提供されているスクリプト(check_elf_alignment.sh)をアプリのプロジェクトルートに配置
./gradlew assembleProductionRelease でプロダクションビルドのapkを出力

check_elf_alignment.sh を使用してapkをチェック

  bash-3.2$ ./check_elf_alignment.sh app/build/outputs/apk/production/release/app-productionRelease_vX.XX.X\(XXX\).apk

※ bash で実行する必要があります

出力結果を確認

出力例（抜粋

  Recursively analyzing *****************.apk

  NOTICE: Zip alignment check requires build-tools version 35.0.0-rc3 or higher.
    You can install the latest build-tools by running the below command
    and updating your $PATH:

      sdkmanager "build-tools;35.0.0-rc3"

  === ELF alignment ===
  /var/folders/rm/********/lib/armeabi-v7a/xxxx.so: \e[32mALIGNED\e[0m (2**14)
  /var/folders/rm/********/lib/armeabi-v7a/xxxx-jni.so: \e[31mUNALIGNED\e[0m (2**12)
  /var/folders/rm/********/lib/x86/xxxx.so: \e[32mALIGNED\e[0m (2**14)
  /var/folders/rm/********/lib/x86/xxxx-jni.so: \e[31mUNALIGNED\e[0m (2**12)
  /var/folders/rm/********/lib/arm64-v8a/xxxx.so: \e[32mALIGNED\e[0m (2**14)
  /var/folders/rm/********/lib/arm64-v8a/xxxx-jni.so: \e[31mUNALIGNED\e[0m (2**12)
  /var/folders/rm/********/lib/x86_64/xxxx.so: \e[32mALIGNED\e[0m (2**14)
  /var/folders/rm/********/lib/x86_64/xxxx-jni.so: \e[31mUNALIGNED\e[0m (2**12)
  \e[31mFound XX unaligned libs (only arm64-v8a/x86_64 libs need to be aligned).\e[0m
  =====================

ここまでの手順を踏んで得た出力の結果でUNALIGNED と出力されているsoファイルは既に16KBページ対応で対応する必要のあるSDKのsoファイルになります。

これらのsoファイルをALIGNED と判定されるように各種SDKを対応していく必要があります。

GooglePlayに延長リクエスト

前述の対応と前後はしますが、調査の過程でGooglePlayに延長リクエストを送ることで元々の期限(2025年11月1日) から2026年5月31日まで延長できることがわかったので、早速リクエストを送りました。

各SDKの更新

ここまでの調査で判明したsoファイルから、対象となるSDKを絞り込むことになります。

これはsoファイルの名前から対象となるSDKを推測したり、CursorやChatGPTを始めとするAIサービスを活用して、ファイル毎に調べるなどの手段を用いました。

対応が必要になったSDKやライブラリは大きく分けて下記に分類されます。

有償SDK
公式又はOSSのライブラリ
AAR化した独自ライブラリ

殆どのライブラリはバージョンアップによって解決しましたが、AAR化した独自ライブラリに関しては、様々な都合によりソースコードを参照できなかったり、参照できたとしても対応工数が掛かる可能性が高いものでした。

ただ、当社の場合ではありますが、結果的にはAAR化した一部のライブラリの使用を廃止するだけで解決しました。

その結果、現状使用されているSDKの中で対応が必要なネイティブコードのELFヘッダのアライメントは全てALIGNED と判定される状態に持っていくことが出来ました。

今後の取り組み

対応が必要な各種SDKの対応は出来たものの、市場にリリースしているわけではありません。

今後はリリースに向けて影響範囲をテストしていき、必要に応じて段階を分けてリリースしていくことになります。

Photoruction工事中！

Photoructionの開発ブログです！

Android 16KBページ対応で取り組んだこと