RORK LABEN
APPLE-AI — Appleが初回DL 200万未満の開発者にFoundation Modelsを無償開放。個人開発アプリへのAI組み込みコストが大幅に低下SWIFT-API — Foundation Modelsのサーバーサイド統合で、ClaudeやGeminiを同一Swift APIから呼び出し可能に。画像入力にも対応KOTLIN-MIGRATION — Android Studioの移行エージェントがReact Native製アプリをネイティブKotlinへ自動移行。Rork生成アプリの将来の選択肢にRORK-MAX — Rork MaxはネイティブSwiftコードを生成(月$200)。iPhone・iPad・Watch・TV・Vision Pro・iMessageまで対応SIMULATOR — ブラウザベースのストリーミングiOSシミュレータで、XcodeやMacなしに実機相当のApple環境で検証可能SWIFTUI — WWDC 2026でSwiftUIが進化。並べ替え可能コンテナ・任意コンテナのスワイプアクション・最大2倍速のレイアウトAPPLE-AI — Appleが初回DL 200万未満の開発者にFoundation Modelsを無償開放。個人開発アプリへのAI組み込みコストが大幅に低下SWIFT-API — Foundation Modelsのサーバーサイド統合で、ClaudeやGeminiを同一Swift APIから呼び出し可能に。画像入力にも対応KOTLIN-MIGRATION — Android Studioの移行エージェントがReact Native製アプリをネイティブKotlinへ自動移行。Rork生成アプリの将来の選択肢にRORK-MAX — Rork MaxはネイティブSwiftコードを生成(月$200)。iPhone・iPad・Watch・TV・Vision Pro・iMessageまで対応SIMULATOR — ブラウザベースのストリーミングiOSシミュレータで、XcodeやMacなしに実機相当のApple環境で検証可能SWIFTUI — WWDC 2026でSwiftUIが進化。並べ替え可能コンテナ・任意コンテナのスワイプアクション・最大2倍速のレイアウト
記事一覧/開発ツール
開発ツール/2026-06-12中級

Android 17 で「ポートレート固定」が通用しなくなる — Rork 製 Expo アプリの大画面対応を前倒しで済ませる手順

Android 17 では大画面デバイスでの画面固定・リサイズ制限が無視されるようになります。Rork で生成した Expo アプリの影響判定からレイアウト改修、エミュレータだけで済ませる検証手順までを実例ベースでまとめました。

Rork381Expo61Android 17大画面対応折りたたみタブレットReact Native153

プレミアム記事

先週、Android 17 のベータを入れたリサイズ対応エミュレータで自分のアプリを開いたとき、見慣れない光景に手が止まりました。ポートレート固定で設計したはずの画面が、横長のウィンドウいっぱいに引き伸ばされて表示されていたのです。レターボックス(左右の黒帯)で守られていた従来の表示は、そこにはありませんでした。

個人開発で Android アプリを運用している方の多くは、「画面はポートレート固定にしておけばレイアウトは崩れない」という前提で作ってきたはずです。私自身もそうでした。その前提が、今夏提供見込みの Android 17 では大画面デバイスにおいて通用しなくなります。

ここでは、Rork で生成した Expo(React Native)アプリを対象に、影響の有無を判定するところから、固定をほどく実装、エミュレータだけで完結する検証までを、私が 6 本のアプリで実際に進めた順番でまとめます。

何が変わるのか — 「固定の無視」は段階的に進んできた

まず変更の中身を整理します。Google は Android 16 から、画面の短辺が 600dp 以上の大画面デバイス(タブレット・折りたたみの展開状態・デスクトップウィンドウ)において、アプリ側が宣言した次の制限を無視する方針を段階的に適用してきました。

  • screenOrientation によるポートレート / ランドスケープ固定
  • resizableActivity="false" によるリサイズ拒否
  • アスペクト比の上限・下限の宣言

Android 16 の時点では互換プロパティによる一時的なオプトアウトが認められていましたが、Android 17 ではこの逃げ道が外れる、というのが今回の節目です。つまり「対応するかどうか」ではなく「いつ対応するか」だけが残された選択になります。

スマートフォン単体(短辺 600dp 未満)では従来どおり固定が尊重されます。影響範囲はあくまで大画面側ですが、折りたたみ端末は閉じればスマートフォン・開けばタブレットという二面性を持つため、「うちはタブレット向けに出していないから無関係」という判断は成り立ちにくくなりました。

影響を受けるかを 10 分で判定する

改修の前に、自分のアプリがどの程度影響を受けるかを見積もります。私は次の 3 点を順に確認しました。

  1. app.json の orientation 設定を見る: Rork が生成する Expo プロジェクトの既定は "orientation": "portrait" です。この値が portraitlandscape なら、固定無視の対象に入ります
  2. 固定幅・固定比率のレイアウトを洗い出す: Dimensions.get("window") をモジュール読み込み時に一度だけ評価しているコードは、リサイズ後も古い寸法を返し続けます。grep -rn "Dimensions.get" src/ で全箇所を確認してください
  3. Google Play Console の端末内訳を見る: 「統計情報 → 端末の種類」でタブレット・折りたたみの利用比率を確認します。私のアプリでは合計 4〜7% でしたが、この層は画面が大きいぶん広告の視認面積も大きく、AdMob の eCPM がスマートフォンより高めに出る傾向があり、切り捨てるには惜しい層です

3 点のうち 1 と 2 の両方に該当するなら、放置した場合に「引き伸ばされて崩れた画面」がそのままユーザーに見えることになります。逆に、すでに orientation: "default" で運用していてレイアウトが寸法ベースなら、本稿の作業はほぼ検証だけで済みます。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
ポートレート固定の既存アプリが Android 17 で強制リサイズの対象になるかを 10 分で判定するチェック手順
orientation 固定を外しても破綻しないための寸法クラス設計と、useWindowDimensions ベースの実装コード一式
実機なし・リサイズ対応エミュレータだけで折りたたみ検証を済ませる手順と、私が実際に直した 4 つの箇所
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Rork Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

開発ツール2026-06-12
Rork 製アプリに開発者デバッグメニューを実装する — 広告・課金・Remote Config の検証をリリース前に終わらせる設計
リリースビルドでしか再現しない広告・課金・Remote Config の不具合に毎回本番で向き合うのは消耗します。壁紙アプリ6本の運用で固まった、ストア提出ビルドには存在ごと残さない開発者デバッグメニューの設計と実装を、動くコードと落とし穴付きで共有します。
開発ツール2026-05-28
Rork アプリで iOS の BGTaskScheduler.submit が Error Code=1 で失敗するときの切り分け手順
Rork で作った iOS アプリで BGTaskScheduler.submit が Error Code=1 (Unavailable) を返してバックグラウンド更新が動かないときに、原因をひとつずつ潰していくための実用チェックリストです。
開発ツール2026-05-25
Rork で targetSdkVersion 35 にしたら Android のレイアウトが下まで埋まる問題の直し方
Android 15 (API 35) で強制されるエッジ・トゥ・エッジ表示によって、Rork で生成したアプリの下部タブやヘッダーがシステムバーに食い込む問題を、react-native-edge-to-edge と useSafeAreaInsets を使って実装パターン別に解決します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →