【技術編】Androidで暗号化動画ストリーミングとセキュリティ挙動に泣き笑いした話

前回の記事では、完全ローカル完結の暗号化カメラアプリ「暗号化動画プレイヤー守」の開発思想について書きました。

今回は、実際にJavaのコードを叩き、AI（Copilot）と壁打ちしながら直面した、具体的な実装の苦労と泥臭いバグ対策の記録を技術メモとして残します。Android開発で暗号化やセキュアなUI制御を行う方の参考になれば幸いです。

Contents

1. 再生パフォーマンスの極限化：全復号から「一部復号」、そしてExoPlayerへの決断
2. 汎用性を高めるための「Adapterの分離」と、のちの別アプリへの資産継承
3. 暗号化方式の仕様変更：パスワード変更機能の追加と、ビジネス用途への展開
4. UI/UXの試行錯誤：画像と動画の操作ロジック
5. 【一番の苦労】バックグラウンド移行時の「徹底的な証拠隠滅」
6. OSの「バックボタン（戻る）」の機種ごとの挙動差
7. 重い処理の非同期化（UIスレッドの解放）
📥 アプリ「暗号化動画プレイヤー守」をPlayストアでチェックする
1. 👉 Google Play ストアでダウンロード
🛠️ 次回予告：【設計・仕様決め編】「暗号化動画プレイヤー守」の裏側に隠された、割り切りとUI/UXのリアルなトレードオフ

1. 再生パフォーマンスの極限化：全復号から「一部復号」、そしてExoPlayerへの決断

当初は、暗号化されたファイルを一度すべてメモリ上（または一時ファイル）に完全復号してから、標準の MediaPlayer で再生する仕様で実装を進めていました。しかしこれだと、ファイルサイズが大きい動画の場合、再生ボタンを押してから実際に動き出すまでに致命的なタイムラグ（待ち時間）が発生してしまいました。

さらに検証を進める中で、標準の MediaPlayer では、暗号化ファイルをオンデマンドで部分復号しながらスムーズに流し込むような柔軟なバッファ制御やデータソースの差し替えを行うのが非常に難しいという壁にぶつかりました。

ここで、「これまで構築したMediaPlayerベースのプログラムを一度すべて捨てて、一から組み直す」という大きな決断をしました。

思い切って柔軟なデータソースのカスタマイズが可能な ExoPlayer（現Media3） へとエンジンを切り替え、「ファイルの先頭や一部のストリームだけをリアルタイムに復号しながら順次読み込む」オンデマンド方式へとアーキテクチャを刷新しました。この泥臭いリベンジの末、数GBある巨大な暗号化動画ファイルでも、待たされることなく一瞬でサクサク再生が開始できる快適なストリーミングを実現できるようになりました。

2. 汎用性を高めるための「Adapterの分離」と、のちの別アプリへの資産継承

後々、別のアプリでもこの機能を使い回せるように設計したかったため、設計の初期段階からコンポーネントの共通化を強く意識しました。

具体的には、ファイル一覧から呼び出される「画像プレビュー用」と「動画再生用」の処理について、下手に無理やり共通のパーツにまとめて複雑化させるのではなく、それぞれの Adapter をあえて完全に分離してシンプルに実装しました。

この「あえて分ける」という判断がのちに大きな実を結びます。ここで綺麗にモジュール化・共通パーツ化された画像プレビューの仕組みは、のちに開発する暗号化PDF Viewerアプリ（PDF GuardView）の開発においてそのまま流用・移植することができ、結果として別プロジェクトへの高い移植性と開発効率の大幅な向上を実感することになりました。

3. 暗号化方式の仕様変更：パスワード変更機能の追加と、ビジネス用途への展開

暗号化・復号化のコアロジック自体はAIの助けを借りたため、比較的スムーズに実装できました。しかし、開発を進める中で大きな転換点がありました。

当初は高齢者の方のプライベートな利用を想定していたため、「パスワード変更機能はそこまで重要ではない（不要）」と考えていました。しかし、開発の途中で「この仕組みは、工場などの現場における組み立て説明動画や業務マニュアルのセキュアな配信・共有にもそのまま流用できるのではないか」という新たな可能性に気づきました。

ビジネスや現場で複数人が利用するとなれば、後からパスワードを変更できる機能は必須の要件となります。そこで、単純にパスワード文字列を変えるだけでは過去の暗号化ファイルがすべて開かなくなってしまう課題をクリアするため、ユーザーのパスワードでマスターキーをさらに隠す「パスワード暗号化の階層構造」を見直し、パスワード変更に対応する大規模なリファクタリングを行いました。

4. UI/UXの試行錯誤：画像と動画の操作ロジック

アプリ内再生を快適にするため、動画画面の拡大・座標移動（ピンチイン・アウトやドラッグ）を実装しましたが、静止画（写真）側で一つ大きな罠にハマりました。

写真を表示したままスワイプして次の画像に切り替えた際、「前の画面の拡大率や座標情報」がメモリに残ってしまい、切り替え後の画像の位置やサイズがおかしくなるバグが発生したのです。初期バージョンでは拡大縮小の座標情報を保持しようと試みましたが、表示が崩れる挙動を回避するため、現バージョンでは「画面が切り替わるごとに一回縮小（初期化）する」という安全策をとりました。この挙動のスマートな共通保持は、今後のアップデートでの課題です。

5. 【一番の苦労】バックグラウンド移行時の「徹底的な証拠隠滅」

今回、技術的に最も頭を悩ませたのが、「ユーザーがアプリを閉じてバックグラウンドに追いやった瞬間」のセキュリティ制御です。

アプリが裏に回ったとき、Androidの「最近使ったアプリ（タスク切り替え画面）」に、さっきまで見ていた写真のサムネイル（スクリーンショット）がそのまま残ってしまうのは、プライバシーアプリとして致命的です。そのため、バックグラウンド移行を検知した瞬間に、ショートカット表示（タスクプレビュー）を確実にクリアし、かつメモリ上のパスワード情報も即座に破棄（クリア）する挙動を作り込みました。これにより、再びアプリを開くときには必ずパスワード入力を再要求する鉄壁の仕様にしています。

6. OSの「バックボタン（戻る）」の機種ごとの挙動差

現在のAndroidは、画面の端をスワイプして戻る「ジェスチャーナビゲーション」と、画面下部に三角形のボタンがある「3ボタンナビゲーション」が混在しています。このOS側の「戻る」が押された際、暗号化のセッションをどのタイミングで安全に閉じるべきか、機種ごとの挙動の差異を吸収して一貫した安全性を保つ制御に苦労しました。