From 061d433be1935d5a17f76a4528cf1028c2e2f23c Mon Sep 17 00:00:00 2001 From: Ruk Doe Date: Wed, 16 Sep 2026 12:38:25 +0900 Subject: [PATCH 1/3] =?UTF-8?q?docs:=20=E3=82=B9=E3=83=88=E3=82=A2?= =?UTF-8?q?=E6=8E=B2=E8=BC=89=E3=81=AE=E5=8F=AF=E5=90=A6=E8=AA=BF=E6=9F=BB?= =?UTF-8?q?=E3=81=A8=E6=89=8B=E9=A0=86=E3=82=92=E8=BF=BD=E5=8A=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Google Play への掲載が規約上可能かを調査し、結果と手順を PUBLISHING.md にまとめる。 掲載自体は可能だが、AccessibilityService の非アクセシビリティ利用にあたるため、 アプリ内での開示・同意、Play Console での宣言、デモ動画の提出が必要になる。 あわせてカメラ権限の要求方法と WebView の権限要求の扱いに要修正箇所がある。 Co-Authored-By: Claude Opus 5 (1M context) --- PUBLISHING.md | 241 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 PUBLISHING.md diff --git a/PUBLISHING.md b/PUBLISHING.md new file mode 100644 index 0000000..6333f61 --- /dev/null +++ b/PUBLISHING.md @@ -0,0 +1,241 @@ +# ストア掲載について + +Lockview を Google Play に掲載できるか、規約上の可否を調査した結果と、掲載する場合の手順をまとめます。 + +調査日: 2026-09-16 / 対象バージョン: v1.0.2 + +## 結論 + +**掲載は可能です。ただし無条件ではなく、コード側の修正とストア側の申請作業が必要です。** + +最大の関門は `SystemBarBlockerService` による AccessibilityService の利用です。Google Play は +非アクセシビリティ目的での利用を禁止してはいませんが、アプリ内での開示・同意取得と、 +Play Console での宣言およびデモ動画の提出が必須になります。 + +現状のコードのままでは審査を通らない可能性が高い箇所が 2 つあります(カメラ権限の要求方法と、 +WebView からの権限要求の無条件許可)。いずれも修正可能です。 + +| 論点 | 判定 | 対応 | +| --- | --- | --- | +| AccessibilityService の非アクセシビリティ利用 | 条件付きで可 | 開示・同意 UI の追加、Play Console 宣言、デモ動画 | +| キオスクによる操作制限 | 要説明 | 解除手段の存在を審査で説明 | +| カメラ権限の無条件要求 | **要修正** | 必要時のみ要求へ変更 | +| WebView の権限要求を無条件許可 | **要修正** | 要求内容を検査してから許可 | +| 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 カメラ権限(要修正) + +`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 の権限要求(要修正) + +```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` 契機に変更する +3. `onPermissionRequest` で要求リソースを検査し、付与済みのものだけを許可する +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 とキオスクによる操作制限の組み合わせは + 審査側の裁量が大きく、事前に確実な可否判定はできません From 1b60e705f269865fd624dee2d7fafa43d8d08584 Mon Sep 17 00:00:00 2001 From: Ruk Doe Date: Wed, 16 Sep 2026 12:48:40 +0900 Subject: [PATCH 2/3] =?UTF-8?q?docs:=20=E3=82=B9=E3=83=88=E3=82=A2?= =?UTF-8?q?=E6=8E=B2=E8=BC=89=E3=82=92=E8=A6=8B=E9=80=81=E3=82=8B=E6=96=B9?= =?UTF-8?q?=E9=87=9D=E3=82=92=E8=BF=BD=E8=A8=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 課金は商用ライセンスの直販に集中する方針となったため、Google Play への掲載は 当面見送る。調査記録は方針を変える場合の資料として残す。 あわせて、掲載と無関係に問題のある 2 箇所を修正済みである旨を反映する。 Co-Authored-By: Claude Opus 5 (1M context) --- PUBLISHING.md | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/PUBLISHING.md b/PUBLISHING.md index 6333f61..ee55fc1 100644 --- a/PUBLISHING.md +++ b/PUBLISHING.md @@ -4,6 +4,23 @@ 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 の権限要求の無条件許可)は、掲載可否とは切り離して修正済みです。 + ## 結論 **掲載は可能です。ただし無条件ではなく、コード側の修正とストア側の申請作業が必要です。** @@ -19,8 +36,8 @@ WebView からの権限要求の無条件許可)。いずれも修正可能で | --- | --- | --- | | AccessibilityService の非アクセシビリティ利用 | 条件付きで可 | 開示・同意 UI の追加、Play Console 宣言、デモ動画 | | キオスクによる操作制限 | 要説明 | 解除手段の存在を審査で説明 | -| カメラ権限の無条件要求 | **要修正** | 必要時のみ要求へ変更 | -| WebView の権限要求を無条件許可 | **要修正** | 要求内容を検査してから許可 | +| カメラ権限の無条件要求 | ~~要修正~~ 対応済み | 必要時のみ要求へ変更 | +| WebView の権限要求を無条件許可 | ~~要修正~~ 対応済み | 要求内容を検査してから許可 | | WebView ラッパーとしての最低機能性 | 問題なし | ストア説明で用途を明示 | | AGPL-3.0 での配布 | 問題なし | — | | AAB / Play App Signing / targetSdk | 一部ギャップ | AAB ビルドの追加 | From 5e2ced0ad08313838a892ba4151277a2836802c9 Mon Sep 17 00:00:00 2001 From: Ruk Doe Date: Wed, 16 Sep 2026 12:51:47 +0900 Subject: [PATCH 3/3] =?UTF-8?q?docs:=202=E7=AE=87=E6=89=80=E3=81=AE?= =?UTF-8?q?=E4=BF=AE=E6=AD=A3=E7=8A=B6=E6=B3=81=E3=81=AE=E8=A8=98=E8=BC=89?= =?UTF-8?q?=E3=82=92=20#17=20=E3=81=B8=E3=81=AE=E5=8F=82=E7=85=A7=E3=81=AB?= =?UTF-8?q?=E7=9B=B4=E3=81=99?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 「修正済み」と書いていたが、実際の修正は別ブランチの #17 にあり、この差分には 含まれていない。本文側の「(要修正)」という記載とも矛盾していた。 参照先を明示する形に統一する。 Co-Authored-By: Claude Opus 5 (1M context) --- PUBLISHING.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/PUBLISHING.md b/PUBLISHING.md index ee55fc1..b0965f5 100644 --- a/PUBLISHING.md +++ b/PUBLISHING.md @@ -19,7 +19,7 @@ Lockview を Google Play に掲載できるか、規約上の可否を調査し 以下は掲載を検討した際の調査記録です。方針を変える場合の資料として残します。 なお、調査の過程で見つかった**ストア掲載と無関係に問題のある 2 箇所**(カメラ権限の -要求方法と WebView の権限要求の無条件許可)は、掲載可否とは切り離して修正済みです。 +要求方法と WebView の権限要求の無条件許可)は、掲載可否とは切り離して #17 で対応しています。 ## 結論 @@ -36,8 +36,8 @@ WebView からの権限要求の無条件許可)。いずれも修正可能で | --- | --- | --- | | AccessibilityService の非アクセシビリティ利用 | 条件付きで可 | 開示・同意 UI の追加、Play Console 宣言、デモ動画 | | キオスクによる操作制限 | 要説明 | 解除手段の存在を審査で説明 | -| カメラ権限の無条件要求 | ~~要修正~~ 対応済み | 必要時のみ要求へ変更 | -| WebView の権限要求を無条件許可 | ~~要修正~~ 対応済み | 要求内容を検査してから許可 | +| カメラ権限の無条件要求 | 要修正 (#17 で対応) | 必要時のみ要求へ変更 | +| WebView の権限要求を無条件許可 | 要修正 (#17 で対応) | 要求内容を検査してから許可 | | WebView ラッパーとしての最低機能性 | 問題なし | ストア説明で用途を明示 | | AGPL-3.0 での配布 | 問題なし | — | | AAB / Play App Signing / targetSdk | 一部ギャップ | AAB ビルドの追加 | @@ -96,7 +96,7 @@ AccessibilityService の利用がブロックされる変更が報じられて 機能そのものが将来の Android で動かなくなる可能性があります。この点は一次情報での再確認を 推奨します。 -### 1.2 カメラ権限(要修正) +### 1.2 カメラ権限(要修正 / #17 で対応) `MainActivity.onCreate` が起動直後に無条件で `CAMERA` を要求し、拒否されると起動を続行しません。 @@ -117,7 +117,7 @@ Google Play は、要求する権限がアプリの中核機能に必要であ **対応**: WebView から `onPermissionRequest` が来た時点で初めて要求する形に変更します。 マニフェストの `uses-feature android:required="false"` は既に適切です。 -### 1.3 WebView の権限要求(要修正) +### 1.3 WebView の権限要求(要修正 / #17 で対応) ```kotlin override fun onPermissionRequest(request: PermissionRequest) { @@ -182,8 +182,8 @@ GitHub Releases 用の APK ビルドは維持したまま、Play 用に AAB を ### 3.1 コード側の修正 1. `accessibility_service_config.xml` に `android:isAccessibilityTool="false"` を明示する -2. `MainActivity` のカメラ権限要求を、WebView の `onPermissionRequest` 契機に変更する -3. `onPermissionRequest` で要求リソースを検査し、付与済みのものだけを許可する +2. `MainActivity` のカメラ権限要求を、WebView の `onPermissionRequest` 契機に変更する — #17 で対応 +3. `onPermissionRequest` で要求リソースを検査し、付与済みのものだけを許可する — #17 で対応 4. ユーザー補助サービスの利用目的を説明し、同意を取る画面を追加する - 現状は `warnIfAccessibilityServiceDisabled()` がトーストで促すだけで、開示要件を満たさない - 初回設定フロー(`SetupActivity`)に組み込むのが自然