diff --git a/PUBLISHING.md b/PUBLISHING.md deleted file mode 100644 index b0965f5..0000000 --- a/PUBLISHING.md +++ /dev/null @@ -1,258 +0,0 @@ -# ストア掲載について - -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 とキオスクによる操作制限の組み合わせは - 審査側の裁量が大きく、事前に確実な可否判定はできません