docs: ストア掲載の可否調査と、見送る方針を追加

PUBLISHING.md

@@ -0,0 +1,258 @@
+# ストア掲載について
+
+Lockview を Google Play に掲載できるか、規約上の可否を調査した結果と、掲載する場合の手順をまとめます。
+
+調査日: 2026-09-16 / 対象バージョン: v1.0.2
+
+## 現在の方針
+
+**Google Play への掲載は当面見送り、[商用ライセンス](LICENSING.md)の直販に集中します。**
+
+理由は次の 3 点です。
+
+1. AGPL-3.0 のソースを公開しているため、誰でも自分でビルドできる。有料アプリの価値が
+   「ビルドの手間を省くこと」だけになり、手数料 15〜30% に見合わない
+2. キオスク端末は台数展開する業務用途で、Google アカウント単位の有料アプリは運用と合わない
+3. 既存のデュアルライセンス(AGPL を嫌う利用者に商用ライセンスを販売する)が、そもそも
+   収益経路として成立している。Play の有料アプリはこれと食い合う
+
+以下は掲載を検討した際の調査記録です。方針を変える場合の資料として残します。
+
+なお、調査の過程で見つかった**ストア掲載と無関係に問題のある 2 箇所**(カメラ権限の
+要求方法と WebView の権限要求の無条件許可)は、掲載可否とは切り離して #17 で対応しています。
+
+## 結論
+
+**掲載は可能です。ただし無条件ではなく、コード側の修正とストア側の申請作業が必要です。**
+
+最大の関門は `SystemBarBlockerService` による AccessibilityService の利用です。Google Play は
+非アクセシビリティ目的での利用を禁止してはいませんが、アプリ内での開示・同意取得と、
+Play Console での宣言およびデモ動画の提出が必須になります。
+
+現状のコードのままでは審査を通らない可能性が高い箇所が 2 つあります(カメラ権限の要求方法と、
+WebView からの権限要求の無条件許可)。いずれも修正可能です。
+
+| 論点 | 判定 | 対応 |
+| --- | --- | --- |
+| AccessibilityService の非アクセシビリティ利用 | 条件付きで可 | 開示・同意 UI の追加、Play Console 宣言、デモ動画 |
+| キオスクによる操作制限 | 要説明 | 解除手段の存在を審査で説明 |
+| カメラ権限の無条件要求 | 要修正 (#17 で対応) | 必要時のみ要求へ変更 |
+| WebView の権限要求を無条件許可 | 要修正 (#17 で対応) | 要求内容を検査してから許可 |
+| WebView ラッパーとしての最低機能性 | 問題なし | ストア説明で用途を明示 |
+| AGPL-3.0 での配布 | 問題なし | — |
+| AAB / Play App Signing / targetSdk | 一部ギャップ | AAB ビルドの追加 |
+
+---
+
+## 1. 規約上の判定
+
+### 1.1 AccessibilityService(最大の関門)
+
+`SystemBarBlockerService` は `TYPE_ACCESSIBILITY_OVERLAY` のウィンドウをステータスバーと
+ナビゲーションバーに重ねてタッチを遮る目的で AccessibilityService を使っています。これは
+障害のあるユーザーを支援する用途ではないため、Google Play の区分では
+**非アクセシビリティ目的の利用**にあたります。
+
+Google Play はこの利用を禁止していませんが、次がすべて必要です。
+
+1. **アプリ内での目立つ開示 (prominent disclosure)** — 通常の利用フローの中で表示されること。
+   設定画面の奥やプライバシーポリシーへのリンクだけでは要件を満たしません
+2. **明示的な同意取得** — タップやチェックボックスなど、ユーザーの能動的な操作による承諾
+3. **Play Console の宣言フォーム** — API の利用目的、個人データ収集の有無を申告
+4. **デモ動画の提出** — 開示フローと実際の機能が映っているもの
+5. **ストア掲載情報への記載** — AccessibilityService を使うことを説明文に明記
+
+#### `isAccessibilityTool` は設定しないこと
+
+`isAccessibilityTool="true"` はスクリーンリーダー、スイッチ入力、音声入力、点字ディスプレイなど、
+障害者支援そのものを主目的とするアプリ専用のフラグです。Lockview は該当しません。
+
+虚偽の申告は**アプリの停止および開発者アカウントの解約**の対象になります。
+
+現状 `app/src/main/res/xml/accessibility_service_config.xml` に属性の記載がなく、既定値の
+`false` が適用されます。動作上は問題ありませんが、意図を明確にするため明示的に
+`android:isAccessibilityTool="false"` を書いておくことを推奨します。
+
+#### 禁止事項との関係(要説明)
+
+ポリシーは AccessibilityService について、**「ユーザーがアプリを無効化またはアンインストール
+できないようにすること」を明確に禁止**しています。Lockview のキオスクモードはホームボタンと
+最近のアプリを無効化し、システムバーを覆うため、ユーザーが設定アプリへ到達する経路を塞ぎます。
+ここが審査で最も説明を要する点です。
+
+説明材料として使えるのは次の点です。
+
+- 解除手段が実装され文書化されている(音量ボタンの上→下→上→下→上 + パスワード)
+- ユーザー補助の有効化は、導入者が設定アプリから手動で行う必要がある
+- 端末の所有者/管理者が、自分の端末を意図してキオスク化するためのツールである
+- 設定 > アプリ > Lockview からストレージを消去すれば未設定状態に戻せる
+
+それでも審査側の裁量に左右される部分です。**リジェクトされる可能性は残ります。**
+
+#### 将来のリスク
+
+Android 17 のベータで、Advanced Protection Mode が有効な端末では非アクセシビリティアプリによる
+AccessibilityService の利用がブロックされる変更が報じられています。掲載可否とは別に、
+機能そのものが将来の Android で動かなくなる可能性があります。この点は一次情報での再確認を
+推奨します。
+
+### 1.2 カメラ権限(要修正 / #17 で対応)
+
+`MainActivity.onCreate` が起動直後に無条件で `CAMERA` を要求し、拒否されると起動を続行しません。
+
+```kotlin
+if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
+    == PackageManager.PERMISSION_GRANTED
+) {
+    continueStartup()
+} else {
+    requestCameraPermission.launch(Manifest.permission.CAMERA)
+}
+```
+
+Google Play は、要求する権限がアプリの中核機能に必要であることを求めます。Lockview にとって
+カメラは「表示するページが使う場合にのみ」必要なもので、中核機能ではありません。
+起動時に一律で要求する現在の実装は、審査で指摘される可能性が高い箇所です。
+
+**対応**: WebView から `onPermissionRequest` が来た時点で初めて要求する形に変更します。
+マニフェストの `uses-feature android:required="false"` は既に適切です。
+
+### 1.3 WebView の権限要求(要修正 / #17 で対応)
+
+```kotlin
+override fun onPermissionRequest(request: PermissionRequest) {
+    request.grant(request.resources)
+}
+```
+
+読み込んだページからの権限要求を、内容を問わず無条件で許可しています。キオスク用途で
+表示先が固定されているとはいえ、ページが遷移すれば任意のサイトが対象になり得ます。
+審査上もセキュリティ上も望ましくありません。
+
+**対応**: 要求されたリソースを検査し、アプリに付与済みのものだけを許可します。
+
+### 1.4 最低限の機能性
+
+Google Play は、既存のウェブサイトを WebView で包んだだけのアプリを「最低限の機能性」の
+違反として扱います。Lockview は表示先 URL を利用者が設定するキオスク化ツールであり、
+特定サイトの再パッケージではありません。パスワードによる解除、システムバーの遮断、
+Lock Task、スクリーンショット禁止など固有の機能を持つため、この条項には該当しにくいと判断します。
+
+ただしストア説明文では「特定サイトのアプリ版」ではなく「端末をキオスク化するツール」で
+あることを明確に書いてください。
+
+### 1.5 ライセンス(問題なし)
+
+AGPL/GPL とアプリストアの衝突としてよく知られているのは **Apple の App Store** の事例です。
+ストア側の追加規約が、ライセンスがユーザーに与える権利を制限してしまう点が問題になりました。
+Google Play にはこれと同等の問題はなく、AGPL-3.0 のアプリの配布実績も多数あります。
+
+加えて Lockview は、[CONTRIBUTING.md](CONTRIBUTING.md) の CLA によって権利者が Doa に
+集約されています。**権利者自身は自分のライセンスに拘束されない**ため、Play での配布形態は
+自由に選べます。ソース公開義務も GitHub リポジトリの公開で満たされています。
+
+この論点は掲載の障害になりません。
+
+### 1.6 プライバシーポリシーとデータセーフティ
+
+- **プライバシーポリシー**: URL の掲示が必須です。Lockview 自体はサーバーを持たず、
+  設定 URL とパスワードハッシュを端末内にのみ保存します。その旨を記載したページを用意します
+- **データセーフティフォーム**: Play Console での回答が必須です。上記に加えて、
+  表示先のウェブサイトが独自にデータを収集し得る点の扱いを整理しておく必要があります
+
+---
+
+## 2. 技術的な前提とのギャップ
+
+| 項目 | Play の要件 | Lockview の現状 | 対応 |
+| --- | --- | --- | --- |
+| 配布形式 | 新規アプリは **AAB 必須** | `assembleRelease` で APK のみ | `bundleRelease` の追加が必要 |
+| 署名 | Play App Signing 必須 | 自前のキーストアで署名 | アップロード鍵として登録 |
+| targetSdk | 2026-08-31 以降、新規アプリは API 36 以上 | `targetSdk = 36` | 対応済み |
+| compileSdk | — | 37 | 問題なし |
+| minSdk | — | 24 | 問題なし |
+| versionCode | 単調増加 | `github.run_number` | 実質単調増加。ワークフローを作り直すと破綻する点に注意 |
+
+GitHub Releases 用の APK ビルドは維持したまま、Play 用に AAB を追加する形になります。
+
+---
+
+## 3. 掲載手順
+
+### 3.1 コード側の修正
+
+1. `accessibility_service_config.xml` に `android:isAccessibilityTool="false"` を明示する
+2. `MainActivity` のカメラ権限要求を、WebView の `onPermissionRequest` 契機に変更する — #17 で対応
+3. `onPermissionRequest` で要求リソースを検査し、付与済みのものだけを許可する — #17 で対応
+4. ユーザー補助サービスの利用目的を説明し、同意を取る画面を追加する
+   - 現状は `warnIfAccessibilityServiceDisabled()` がトーストで促すだけで、開示要件を満たさない
+   - 初回設定フロー(`SetupActivity`)に組み込むのが自然
+5. `release.yml` に `bundleRelease` を追加し、AAB を生成する
+
+### 3.2 アカウントの準備
+
+1. Google Play デベロッパー登録(初回のみ **$25**)
+2. 本人確認 / 組織確認を完了する
+3. **個人アカウントの場合の追加要件**: 2023-11-13 以降に作成された個人アカウントは、
+   製品版の公開前に **12 名以上のテスターが 14 日間連続でオプトインしたクローズドテスト**が
+   必要です。組織アカウント、およびそれ以前に作成された個人アカウントは免除されます
+   - 「オプトイン」は招待を承諾し実際にインストールした状態を指します。招待しただけ、
+     エミュレータ、重複アカウントはカウントされません
+   - このアカウントがどちらに該当するかは未確認です。**最初に確認してください**。
+     該当する場合、掲載までの所要期間が 2 週間以上延びます
+
+### 3.3 Play Console での作業
+
+1. アプリを作成し、パッケージ名 `io.doany.lockview` を登録する
+2. Play App Signing を有効化し、既存のキーストアをアップロード鍵として登録する
+3. ストア掲載情報を作成する
+   - 説明文に「端末をキオスク化するツール」であることと、AccessibilityService を
+     利用することを明記する
+   - スクリーンショット、アイコン、フィーチャーグラフィックを用意する
+4. プライバシーポリシーの URL を登録する
+5. データセーフティフォームに回答する
+6. **AccessibilityService の宣言フォームに回答する**
+7. **デモ動画を提出する** — アプリ内の開示・同意フローと、キオスク機能の実際の動作が
+   映っているもの
+8. コンテンツレーティングのアンケートに回答する
+9. AAB をアップロードする
+10. (個人アカウントの場合)クローズドテストを 14 日間実施し、製品版アクセスを申請する
+11. 審査に提出する
+
+### 3.4 審査で聞かれる可能性が高い点
+
+- なぜ AccessibilityService が必要か(DeviceOwner / ProfileOwner を使わない理由)
+- ユーザーがキオスクモードを解除する方法
+- カメラ権限を要求する理由
+
+README にすでに設計上の理由が書かれているため、その内容を英訳して提出できるように
+しておくと審査対応が楽になります。
+
+---
+
+## 4. 代替の配布経路
+
+Google Play の審査リスクを避けたい場合、または並行して配布したい場合の選択肢です。
+
+| 経路 | 特徴 |
+| --- | --- |
+| **GitHub Releases**(現状) | 制約なし。タグ push で自動ビルド・署名済み APK を添付 |
+| **F-Droid** | AGPL-3.0 と相性が良く、AccessibilityService の用途制限もない。ビルドの再現性など F-Droid 側の要件を満たす必要がある |
+| **Amazon Appstore** | 審査は Play より緩いとされる。対象端末は限られる |
+| **Samsung Galaxy Store** | Galaxy 端末向け |
+
+キオスク端末は業務用途で管理者が手動導入するケースが多く、**GitHub Releases での配布で
+足りている可能性**もあります。Play に出す目的(到達性か、信頼性の担保か)を先に決めると
+判断しやすくなります。
+
+---
+
+## 5. 未確定事項
+
+この文書で結論を出せていない点です。
+
+1. **Play デベロッパーアカウントの種別と作成日** — 12 テスター要件の要否が決まります
+2. **Android 17 の Advanced Protection Mode による影響** — 報道ベースの情報のため、
+   一次情報での確認が必要です
+3. **審査の実際の判断** — AccessibilityService とキオスクによる操作制限の組み合わせは
+   審査側の裁量が大きく、事前に確実な可否判定はできません