[DroidKaigi 2020] Re:ゼロから始める Play Billing Library / Re: Zero - starting uses of Play Billing Library

1. Re:ゼロから始める Play Billing Library DroidKaigi 2020 2020/02/21 (Fri) @syarihu
2. Taichi Sato (@syarihu) • Money Forward, Inc. ◦ Android Engineer • TechBooster
3. アジェンダ • Play Billing Library概要 • Play Billing Library 2.0新機能 • Purchase Anywhere • AACを利用したPlay Billing Libraryによる課金実装 • 年額課金を実装したときに得ら れた知見
4. Play Billing Library
5. https://android-developers.googleblog.com/2017/09/google-play-billing-library-10-released.html https://youtu.be/y78ugwN4Obg
6. • AndroidではIn-app Billing APIを通じてPlay Billingと連携し、アプリ課金を実現する • Play Billing Libraryの登場以前はAIDLを使っ てアプリ課金の実装を行っていた • AIDLではアプリからサービスへの接続や通信 の管理をすべて行う AIDL
7. • 機能に必要なコードをたくさんプロジェクトにコ ピーする必要があったため、新しい機能を追 加することは困難だった • AIDLのさまざまな課題を解決するために、 Play Billing Libraryが開発された AIDL
8. • PBLはPlay Billingと連携するためのAIDLを抽 象化した課金ライブラリ • 接続の管理やPlay Billingとの通信などを行う ◦ サービスとの接続を自分自身で管理する必 要はなくなった Play Billing Library
9. • いままでプロジェクトにコピーしていた定形コー ドはライブラリに埋め込まれている • In-app Billing APIに機能が追加されるたびに ファイルを更新する必要はなくなった Play Billing Library
10. • このような背景があり、AIDLは今後更新され ず、PBLでしか新しい機能は提供されない • AIDLからPBLへの移行は必須 Play Billing Library
11. Play Billing Library ロードマップ
12. • 各メジャーバージョンはリリースされてから２年 間サポートされる • AIDLやPlay Billing Library 1.xは 2021年5月1日までのサポート Play Billing Library
13. • AIDLとPBL 1.xのサポート終了まで 2020年2月21日から数えると残り435日 ありますが、ギリギリまで待たずになるべく早 めに移行しましょう Play Billing Library
14. Play Billing Library 2.0
15. • acknowledge • Pending transactions Play Billing Library 2.0
16. • PBL 2.0からPBLを介して行ったすべての購入 に対してacknowledge（承認）を行うことが必 須になった • 購入後、3日以内に承認をしない場合はユー ザーは自動的に払い戻しを受ける acknowledge
17. • 承認する方法は2種類 ◦ Google Play Developer APIを使ってサー バーから行う ◦ PBLを使ってアプリから行う acknowledge
18. acknowledgeの支払いフロー
19. 通常の支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
20. 通常の支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
21. 通常の支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
22. 通常の支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
23. 通常の支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
24. 通常の支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果 Google Playでの購入は正常にできているのに サービスは利用できない状態になってしまう
25. acknowledgeに対応した支払いフロー ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
26. acknowledgeに対応した支払いフロー ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
27. acknowledgeに対応した支払いフロー ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
28. acknowledgeに対応した支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果 承認リクエスト 承認結果
29. acknowledgeに対応した支払いフロー ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果 承認リクエスト 承認結果 購入情報の登録に失敗しても 3日以内に承認されない場合は払い戻されるので安心
30. acknowledgeに対応した支払いフロー（アプリ） ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
31. acknowledgeに対応した支払いフロー（アプリ） ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
32. acknowledgeに対応した支払いフロー（アプリ） ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
33. acknowledgeに対応した支払いフロー（アプリ） ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
34. acknowledgeに対応した支払いフロー（アプリ） ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果 アプリで通信失敗したときなどの考慮は必要
35. Pending transactions
36. • 遅延支払いができる新しい支払い方法 • 支払いは実店舗での現金払いや銀行振込 などを想定 Pending transactions
37. • 管理対象アイテムで利用できる • 定期購入では利用できない ◦ 支払い方法の選択肢には出てこない Pending transactions
38. Pending transactionsの コンビニでの利用例
39. What's New with Google Play Billing (Google I/O'19) より引用 https://youtu.be/N4004Set4F8
40. What's New with Google Play Billing (Google I/O'19) より引用 https://youtu.be/N4004Set4F8
41. What's New with Google Play Billing (Google I/O'19) より引用 https://youtu.be/N4004Set4F8
42. Google Playへの支払いリクエスト ユーザー アプリ サーバー 支払いリクエストを行う 支払いを促す Google Play 支払いコード レシート送信 レシート検証 購入情報を登録 購入結果 レシート（支払い保留状態）
43. Google Playへの支払いリクエスト ユーザー アプリ サーバー 支払いリクエストを行う 支払いを促す Google Play 支払いコード レシート送信 レシート検証 購入情報を登録 購入結果 レシート（支払い保留状態）
44. Google Playへの支払いリクエスト ユーザー アプリ サーバー 支払いリクエストを行う 支払いを促す Google Play 支払いコード レシート送信 レシート検証 購入情報を登録 購入結果 レシート（支払い保留状態）
45. Google Playへの支払いリクエスト ユーザー アプリ サーバー 支払いリクエストを行う 支払いを促す Google Play 支払いコード レシート送信 レシート検証 購入情報を登録 購入結果 レシート（支払い保留状態）
46. Google Playへの支払いリクエスト ユーザー アプリ サーバー 支払いリクエストを行う 支払いを促す Google Play 支払いコード レシート送信 レシート検証 購入情報を登録 購入結果 レシート（支払い保留状態）
47. Google Playへの支払いリクエスト ユーザー アプリ サーバー 支払いリクエストを行う 支払いを促す Google Play 支払いコード レシート送信 レシート検証 購入情報を登録 購入結果 レシート（支払い保留状態）
48. Google Playへの支払いリクエスト ユーザー アプリ サーバー 支払いリクエストを行う 支払いを促す Google Play 支払いコード レシート送信 レシート検証 購入情報を登録 購入結果 レシート（支払い保留状態）
49. コンビニへの支払い コンビニ ユーザー アプリ サーバー 支払いを行う 支払い完了通知 承認リクエスト 承認結果 アイテムを渡す Google Play 支払い完了通知 購入履歴をリクエスト レシート検証 購入情報を登録 購入結果 アプリを起動 購入履歴 レシートを送信
50. コンビニへの支払い コンビニ ユーザー アプリ サーバー 支払いを行う 支払い完了通知 承認リクエスト 承認結果 アイテムを渡す Google Play 支払い完了通知 購入履歴をリクエスト レシート検証 購入情報を登録 購入結果 アプリを起動 購入履歴 レシートを送信
51. コンビニへの支払い コンビニ ユーザー アプリ サーバー 支払いを行う 支払い完了通知 承認リクエスト 承認結果 アイテムを渡す Google Play 支払い完了通知 購入履歴をリクエスト レシート検証 購入情報を登録 購入結果 アプリを起動 購入履歴 レシートを送信
52. コンビニへの支払い コンビニ ユーザー アプリ サーバー 支払いを行う 支払い完了通知 承認リクエスト 承認結果 アイテムを渡す Google Play 支払い完了通知 購入履歴をリクエスト レシート検証 購入情報を登録 購入結果 アプリを起動 購入履歴 レシートを送信
53. コンビニへの支払い コンビニ ユーザー アプリ サーバー 支払いを行う 支払い完了通知 承認リクエスト 承認結果 アイテムを渡す Google Play 支払い完了通知 購入履歴をリクエスト レシート検証 購入情報を登録 購入結果 アプリを起動 購入履歴 レシートを送信
54. コンビニへの支払い コンビニ ユーザー アプリ サーバー 支払いを行う 支払い完了通知 承認リクエスト 承認結果 アイテムを渡す Google Play 支払い完了通知 購入履歴をリクエスト レシート検証 購入情報を登録 購入結果 アプリを起動 購入履歴 レシートを送信
55. コンビニへの支払い コンビニ ユーザー アプリ サーバー 支払いを行う 支払い完了通知 承認リクエスト 承認結果 アイテムを渡す Google Play 支払い完了通知 購入履歴をリクエスト レシート検証 購入情報を登録 購入結果 アプリを起動 購入履歴 レシートを送信
56. • 支払いリクエストを行ったときは保留状態にな る（Pending transactions） • 支払いが終わったあとにアプリが3日以上起動 されないなど承認が行われないときは払い戻 しされる（acknowledge） コンビニでの現金払い
57. Purchase Anywhere
58. • Pending transactions • アプリ外購入 Purchase Anywhere
59. • 現金購入（Cash purchases） • リモート購入承認（Remote purchase approvals） Pending transactions
60. • コンビニなどの実店舗での支払いや 銀行振り込み • 日本、インドネシア、メキシコで使える状態に なっている ◦ 2020年2月現在は日本では実際に使える 店舗はまだ無い 現金購入
61. • Googleアカウントを子どもに提供する代わりに 子ども用のアカウントを作成できる • 子どもが何かを購入すると、アプリやゲームに 表示される前に親が親のスマートフォンで承認 リモート購入承認
62. • リモート購入承認もPending transactionsの 仕組みを使って行われる • まだリリースされていないが、もうすぐリリース される予定（と、Android Dev Summit 2019で 発表していた） リモート購入承認
63. アプリ外購入
64. • アプリが実行中でないときにアプリの外部で発 生する購入 アプリ外購入
65. • Promo Codes • Gift Cards • Google Play Points • Subscribe and Install アプリ外購入
66. Promo Codes
67. Gift Cards
68. Google Play Points
69. Subscribe and Install
70. • アプリ外購入は、アプリではないところで購入 されるため、アプリはどんな状態かは分からな い アプリ外購入
71. • アプリは動いていないかもしれない • アプリはインストールされていないかもしれな い • 何らかの状態で一時停止しているかもしれな い（分割画面やPicture in pictureなど） アプリ外購入
72. • アプリの外部で受け取ったアイテムを検出 • 分割画面モードの最中に受け取ったアイテム を検出 • アイテムを検出したときに、アプリ内で何らか のメッセージをユーザーに表示 アプリ外購入
73. • Play Billing Libraryは、Purchase Anywhere の一環で提供される機能が使えるというメリッ トも大きい • これらの新機能を使うためにもなるべく 早めにPBLに移行しましょう Purchase Anywhere
74. AACとPBLを使った アプリ課金の実装例
75. • Google Playの課金サービスへの接続やリク エストはBillingClientのinterfaceから受け取れ る • 課金を実装する画面は1つとは限らないため、 ActivityやFragmentなどではなくViewModel で実装する AACでBillingClientを扱う
76. dependencies { implementation 'com.android.billingclient:billing:2.1.0' } app/build.gradle
77. dependencies { implementation 'com.android.billingclient:billing:2.1.0' implementation 'androidx.lifecycle:lifecycle-livedata:2.2.0' implementation 'androidx.lifecycle:lifecycle-viewmodel:2.2.0' } app/build.gradle
78. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { private val billingClient: BillingClient = BillingClient.newBuilder(application) .enablePendingPurchases() .setListener(this /* PurchasesUpdatedListener */) .build() } BillingViewModel.kt
79. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { private val billingClient: BillingClient = BillingClient.newBuilder(application) .enablePendingPurchases() .setListener(this /* PurchasesUpdatedListener */) .build() } BillingViewModel.kt
80. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { private val billingClient: BillingClient = BillingClient.newBuilder(application) .enablePendingPurchases() .setListener(this /* PurchasesUpdatedListener */) .build() } BillingViewModel.kt
81. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { private val billingClient: BillingClient = BillingClient.newBuilder(application) .enablePendingPurchases() .setListener(this /* PurchasesUpdatedListener */) .build() } BillingViewModel.kt
82. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { private val billingClient: BillingClient = BillingClient.newBuilder(application) .enablePendingPurchases() .setListener(this /* PurchasesUpdatedListener */) .build() } BillingViewModel.kt
83. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { ...省略... /** 購入完了、購入キャンセルなどのコールバック */ override fun onPurchasesUpdated( billingResult: BillingResult, purchases: MutableList<Purchase>? ) { } } BillingViewModel.kt
84. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { private val billingClient: BillingClient = BillingClient.newBuilder(application) .enablePendingPurchases() .setListener(this /* PurchasesUpdatedListener */) .build() ...省略... } BillingViewModel.kt
85. • BillingClientは課金サービスへの接続完了後 や購入完了後などさまざまな状態に応じたイ ベントを受け取れる • 現在どのような状態なのかを知るため、各状 態をあらかじめ定義し、LiveDataで管理する LiveDataで課金の状態を管理する
86. sealed class BillingStatus { object SetupSuccess : BillingStatus() object BillingFlow : BillingStatus() object PendingPurchase : BillingStatus() object AcknowledgeSuccess : BillingStatus() object ServiceDisconnected : BillingStatus() object NoPreviousPlanPurchaseHistory : BillingStatus() data class Error(val billingResult: BillingResult) : BillingStatus() } BillingStatus.kt
87. sealed class BillingStatus { object SetupSuccess : BillingStatus() object BillingFlow : BillingStatus() object PendingPurchase : BillingStatus() object AcknowledgeSuccess : BillingStatus() object ServiceDisconnected : BillingStatus() object NoPreviousPlanPurchaseHistory : BillingStatus() data class Error(val billingResult: BillingResult) : BillingStatus() } BillingStatus.kt
88. sealed class BillingStatus { object SetupSuccess : BillingStatus() object BillingFlow : BillingStatus() object PendingPurchase : BillingStatus() object AcknowledgeSuccess : BillingStatus() object ServiceDisconnected : BillingStatus() object NoPreviousPlanPurchaseHistory : BillingStatus() data class Error(val billingResult: BillingResult) : BillingStatus() } BillingStatus.kt
89. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { ...省略... /** 購入完了、購入キャンセルなどのコールバック */ override fun onPurchasesUpdated( billingResult: BillingResult, purchases: MutableList<Purchase>? ) { } } BillingViewModel.kt
90. sealed class BillingStatus { object SetupSuccess : BillingStatus() object BillingFlow : BillingStatus() object PendingPurchase : BillingStatus() object AcknowledgeSuccess : BillingStatus() object ServiceDisconnected : BillingStatus() object NoPreviousPlanPurchaseHistory : BillingStatus() data class Error(val billingResult: BillingResult) : BillingStatus() } BillingStatus.kt
91. sealed class BillingStatus { object SetupSuccess : BillingStatus() object BillingFlow : BillingStatus() object PendingPurchase : BillingStatus() object AcknowledgeSuccess : BillingStatus() object ServiceDisconnected : BillingStatus() object NoPreviousPlanPurchaseHistory : BillingStatus() data class Error(val billingResult: BillingResult) : BillingStatus() } BillingStatus.kt
92. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { ...省略... private val _billingStatus = MutableLiveData<BillingStatus>() val billingStatus: LiveData<BillingStatus> = _billingStatus } BillingViewModel.kt
93. Google Playの課金サービスに接続する
94. • 課金を行うには、Google Playの課金サービス への接続が必要 • 課金サービスへの接続は通常、課金したい画 面のonCreateなどのイベント発生時に実行す る Google Playの課金サービスに接続する
95. • AACのLifecycleObserverを使うとActivityや Fragmentのライフサイクルイベントを任意のメ ソッドで受け取れる • ViewModelにLifecycleObserverを実装して onCreate時に課金サービスへ接続する Google Playの課金サービスに接続する
96. Google Playの課金サービスに接続する ViewModel BillingClient Google Play startConnection onServiceConnected bindService onBillingSetupFinished Fragment OnLifecycleEvent: onCreate LiveData: SetupSuccess
97. Google Playの課金サービスに接続する ViewModel BillingClient Google Play startConnection onServiceConnected bindService onBillingSetupFinished Fragment OnLifecycleEvent: onCreate LiveData: SetupSuccess
98. Google Playの課金サービスに接続する ViewModel BillingClient Google Play startConnection onServiceConnected bindService onBillingSetupFinished Fragment OnLifecycleEvent: onCreate LiveData: SetupSuccess
99. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... private fun startConnection() { billingClient.startConnection(this /* BillingClientStateListener */) } } BillingViewModel.kt
100. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... private fun startConnection() { billingClient.startConnection(this /* BillingClientStateListener */) } } BillingViewModel.kt
101. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... private fun startConnection() { billingClient.startConnection(this /* BillingClientStateListener */) } } BillingViewModel.kt
102. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... override fun onBillingSetupFinished(billingResult: BillingResult) { if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) _billingStatus.postValue(BillingStatus.SetupSuccess) else _billingStatus.postValue(BillingStatus.Error(billingResult)) } override fun onBillingServiceDisconnected() = Unit } BillingViewModel.kt
103. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... override fun onBillingSetupFinished(billingResult: BillingResult) { if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) _billingStatus.postValue(BillingStatus.SetupSuccess) else _billingStatus.postValue(BillingStatus.Error(billingResult)) } override fun onBillingServiceDisconnected() = Unit } BillingViewModel.kt
104. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... override fun onBillingSetupFinished(billingResult: BillingResult) { if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) _billingStatus.postValue(BillingStatus.SetupSuccess) else _billingStatus.postValue(BillingStatus.Error(billingResult)) } override fun onBillingServiceDisconnected() = Unit } BillingViewModel.kt
105. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... override fun onBillingSetupFinished(billingResult: BillingResult) { if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) _billingStatus.postValue(BillingStatus.SetupSuccess) else _billingStatus.postValue(BillingStatus.Error(billingResult)) } override fun onBillingServiceDisconnected() = Unit } BillingViewModel.kt
106. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... override fun onBillingSetupFinished(billingResult: BillingResult) { if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) _billingStatus.postValue(BillingStatus.SetupSuccess) else _billingStatus.postValue(BillingStatus.Error(billingResult)) } override fun onBillingServiceDisconnected() = Unit } BillingViewModel.kt
107. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener { ...省略... override fun onBillingSetupFinished(billingResult: BillingResult) { if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) _billingStatus.postValue(BillingStatus.SetupSuccess) else _billingStatus.postValue(BillingStatus.Error(billingResult)) } override fun onBillingServiceDisconnected() = Unit } BillingViewModel.kt
108. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener, LifecycleObserver { ...省略... @OnLifecycleEvent(Lifecycle.Event.ON_CREATE) fun onCreate() { startConnection() } } BillingViewModel.kt
109. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener, LifecycleObserver { ...省略... @OnLifecycleEvent(Lifecycle.Event.ON_CREATE) fun onCreate() { startConnection() } } BillingViewModel.kt
110. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener, LifecycleObserver { override fun onCleared() { super.onCleared() billingClient.endConnection() } } BillingViewModel.kt
111. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener, LifecycleObserver { override fun onCleared() { super.onCleared() billingClient.endConnection() } } BillingViewModel.kt
112. 課金アイテムの情報を取得する
113. • Google Playの管理アイテムにはそれぞれアイ テムIDが振られている • アイテムIDはPlay Console上でアイテムを追 加する際に自ら設定する • PBL内ではSKUと呼ばれる アイテム情報を取得する
114. • アイテムの種類や金額などの情報がまとまっ たオブジェクトをSkuDetailsと呼び、アイテムID を使って取得できる • SkuDetailsはアイテムを購入する際にも利用 する アイテム情報を取得する
115. アイテムの購入画面を表示するまでの流れ ユーザー アプリ Google Play アイテムの購入ボタンをタップ SkuDetails アイテムの購入画面を表示 SkuDetailsを元に 購入をリクエスト アイテムIDとアイテムの種類を元に アイテム情報をリクエスト
116. アイテムの購入画面を表示するまでの流れ ユーザー アプリ Google Play アイテムの購入ボタンをタップ SkuDetails アイテムの購入画面を表示 アイテムIDとアイテムの種類を元に アイテム情報をリクエスト SkuDetailsを元に 購入をリクエスト
117. アイテムの購入画面を表示するまでの流れ ユーザー アプリ Google Play アイテムの購入ボタンをタップ SkuDetails アイテムの購入画面を表示 アイテムIDとアイテムの種類を元に アイテム情報をリクエスト SkuDetailsを元に 購入をリクエスト
118. アイテムの購入画面を表示するまでの流れ ユーザー アプリ Google Play アイテムの購入ボタンをタップ SkuDetails アイテムの購入画面を表示 アイテムIDとアイテムの種類を元に アイテム情報をリクエスト SkuDetailsを元に 購入をリクエスト
119. アイテムの購入画面を表示するまでの流れ ユーザー アプリ Google Play アイテムの購入ボタンをタップ SkuDetails アイテムの購入画面を表示 アイテムIDとアイテムの種類を元に アイテム情報をリクエスト SkuDetailsを元に 購入をリクエスト
120. • アイテム情報を取得するにはアイテムIDとアイ テムの種類が必要 • アプリで購入できるアイテムが複数ある場合 は、一箇所でまとめて定義しておくほうが便利 アイテムを管理する
121. • PBLではアプリ内のアイテムの種類を SkuTypeとして表す ◦ SkuType.INAPP … 管理対象アイテム ◦ SkuType.SUBS … 定期購入 アイテムを管理する
122. enum class BillingSkuType( @BillingClient.SkuType val skuType: String ) { /** 定期購読 */ Subscription(BillingClient.SkuType.SUBS), /** 消費不可のアプリ内アイテム */ InAppNonConsumable(BillingClient.SkuType.INAPP), /** 消費可能なアプリ内アイテム */ InAppConsumable(BillingClient.SkuType.INAPP), } BillingSkuType.kt
123. enum class BillingItem(val sku: String, val billingSkuType: BillingSkuType) { MonthlyPlan( "monthly_plan", BillingSkuType.Subscription), MonthlyPremiumPlan( "monthly_premium_plan", BillingSkuType.Subscription), NonConsumableItem( "non_consumable_item", BillingSkuType.InAppNonConsumable), ConsumableItem( "consumable_item", BillingSkuType.InAppConsumable), AndroidTestPurchased( "android.test.purchased", BillingSkuType.InAppNonConsumable); } BillingSkuType.kt
124. enum class BillingItem(val sku: String,val billingSkuType: BillingSkuType) { ...省略... fun skusList(): List<String> = listOf(sku) companion object { fun findBySku(sku: String): BillingItem? = values().find { it.sku == sku } } } BillingSkuType.kt
125. private fun getSkuDetails( billingItem: BillingItem, onResponse: (skuDetails: SkuDetails) -> Unit ) { val skuDetailsParams = SkuDetailsParams.newBuilder() .setSkusList(billingItem.skusList()) .setType(billingItem.billingSkuType.skuType) .build() ...省略... BillingViewModel.kt
126. billingClient.querySkuDetailsAsync(skuDetailsParams ) { billingResult: BillingResult, skuDetailList: List<SkuDetails> -> if (billingResult.responseCode == BillingClient.BillingResponseCode.OK && skuDetailList.isNotEmpty() ) { onResponse(skuDetailList[0]) } else { _billingStatus.postValue(BillingStatus.Error(billingResult)) } } } BillingViewModel.kt
127. billingClient.querySkuDetailsAsync(skuDetailsParams ) { billingResult: BillingResult, skuDetailList: List<SkuDetails> -> if (billingResult.responseCode == BillingClient.BillingResponseCode.OK && skuDetailList.isNotEmpty() ) { onResponse(skuDetailList[0]) } else { _billingStatus.postValue(BillingStatus.Error(billingResult)) } } } BillingViewModel.kt
128. billingClient.querySkuDetailsAsync(skuDetailsParams ) { billingResult: BillingResult, skuDetailList: List<SkuDetails> -> if (billingResult.responseCode == BillingClient.BillingResponseCode.OK && skuDetailList.isNotEmpty() ) { onResponse(skuDetailList[0]) } else { _billingStatus.postValue(BillingStatus.Error(billingResult)) } } } BillingViewModel.kt
129. billingClient.querySkuDetailsAsync(skuDetailsParams ) { billingResult: BillingResult, skuDetailList: List<SkuDetails> -> if (billingResult.responseCode == BillingClient.BillingResponseCode.OK && skuDetailList.isNotEmpty() ) { onResponse(skuDetailList[0]) } else { _billingStatus.postValue(BillingStatus.Error(billingResult)) } } } BillingViewModel.kt
130. アイテムの購入画面を表示するまでの流れ ユーザー アプリ Google Play アイテムの購入ボタンをタップ SkuDetails アイテムの購入画面を表示 アイテムIDとアイテムの種類を元に アイテム情報をリクエスト SkuDetailsを元に 購入をリクエスト
131. アイテムの購入画面を表示するまでの流れ ユーザー アプリ Google Play アイテムの購入ボタンをタップ SkuDetails アイテムの購入画面を表示 アイテムIDとアイテムの種類を元に アイテム情報をリクエスト SkuDetailsを元に 購入をリクエスト
132. fun purchase(activity: Activity, billingItem: BillingItem) { getSkuDetails(billingItem) { skuDetails -> val flowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() _billingStatus.postValue(BillingStatus.BillingFlow) billingClient.launchBillingFlow(activity, flowParams) } } BillingViewModel.kt
133. class BillingFragment : Fragment(), View.OnClickListener { ...省略... override fun onClick(v: View?) { billingViewModel.purchase( requireActivity(), BillingItem.NonConsumableItem ) } } BillingFragment.kt
135. 支払いをしてからアイテムを受け取るまでの流れ ユーザー アプリ サーバー 支払いを行う レシート アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
136. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { ...省略... /** 購入完了、購入キャンセルなどのコールバック */ override fun onPurchasesUpdated( billingResult: BillingResult, purchases: MutableList<Purchase>? ) { } } BillingViewModel.kt
137. class BillingViewModel(application: Application) : ViewModel(), PurchasesUpdatedListener { ...省略... /** 購入完了、購入キャンセルなどのコールバック */ override fun onPurchasesUpdated( billingResult: BillingResult, purchases: MutableList<Purchase>? ) { } } BillingViewModel.kt
138. • Purchaseには注文IDや購入したアイテムのア イテムID、購入日時などの購入情報を含むレ シートが入っている • レシートはユーザーが購入したことを証明する 唯一の手がかり レシートの取得、検証
139. • たとえば、ユーザーが購入している定期購入 の契約状況をサーバーが知りたい場合、レ シートに含まれる情報が無ければ契約情報を 取得できない レシートの取得、検証
140. • ユーザーのアイテム購入状況を取得するため にはレシートは必須 • そのためレシートを受け取ったアプリは通常、 サービスのサーバーへレシートを送信する レシートの取得、検証
141. • Purchaseオブジェクトのsignatureというプロパ ティは購入情報を含むレシートデータを開発者 用の秘密鍵で署名しているため、これを送信 する レシートの取得、検証
142. • 署名されたレシートを受け取ったサーバーは 開発者用の公開鍵を使って復号化し、改ざん などを検証する • 検証結果に問題がなければアプリに購入結果 を返却する レシートの取得、検証
143. • 結果を受け取ったアプリはユーザーに対して アイテム購入が完了したことを表示するなどし てアイテムの受け渡しが完了する レシートの取得、検証
144. 定期購入を契約する
145. • 週、月、3ヶ月、6ヶ月、年間のいずれかの期間 で定期的に課金できるアイテム • 新規の定期購入者に対して無料試用期間や お試し価格の設定もできる 定期購入
146. • ある定期購入アイテムから別の定期購入アイ テムへのプラン変更をする仕組みも提供され ている • 初回購入以降の支払いは、アイテムに設定さ れている定期購入の期間に応じて自動的に支 払われる 定期購入
147. class BillingFragment : Fragment(), View.OnClickListener { ...省略... override fun onClick(v: View?) { billingViewModel.purchase( requireActivity(), BillingItem.MonthlyPlan ) } } BillingFragment.kt
148. class BillingFragment : Fragment(), View.OnClickListener { ...省略... override fun onClick(v: View?) { billingViewModel.purchase( requireActivity(), BillingItem.MonthlyPlan ) } } BillingFragment.kt
150. 定期購入のプランを変更する
151. • 定期購入の購入と同じくlaunchBillingFlowメ ソッドを使う • BillingFlowParamsのsetOldSkuメソッドでプラ ン変更前の定期購入アイテムを指定する 定期購入のプラン変更
152. • 以前はsetOldSkuにSKUだけ渡せば良かった が、PBL 2.1.0からSKUだけを渡すメソッドは非 推奨となった • SKUに加えて変更前のプランの PurchaseTokenが必要になった 定期購入のプラン変更
153. fun changePlan( activity: Activity, billingItem: BillingItem, oldBillingItem: BillingItem ) { billingClient.queryPurchaseHistoryAsync( BillingClient.SkuType.SUBS) { _, purchases -> val purchase: PurchaseHistoryRecord? = purchases.find { it.sku == oldBillingItem.sku } if (purchase == null) { _billingStatus.postValue( BillingStatus.NoPreviousPlanPurchaseHistory) return@queryPurchaseHistoryAsync } BillingViewModel.kt
154. fun changePlan( activity: Activity, billingItem: BillingItem, oldBillingItem: BillingItem ) { billingClient.queryPurchaseHistoryAsync( BillingClient.SkuType.SUBS) { _, purchases -> val purchase: PurchaseHistoryRecord? = purchases.find { it.sku == oldBillingItem.sku } if (purchase == null) { _billingStatus.postValue( BillingStatus.NoPreviousPlanPurchaseHistory) return@queryPurchaseHistoryAsync } BillingViewModel.kt
155. fun changePlan( activity: Activity, billingItem: BillingItem, oldBillingItem: BillingItem ) { billingClient.queryPurchaseHistoryAsync( BillingClient.SkuType.SUBS) { _, purchases -> val purchase: PurchaseHistoryRecord? = purchases.find { it.sku == oldBillingItem.sku } if (purchase == null) { _billingStatus.postValue( BillingStatus.NoPreviousPlanPurchaseHistory) return@queryPurchaseHistoryAsync } BillingViewModel.kt
156. fun changePlan( activity: Activity, billingItem: BillingItem, oldBillingItem: BillingItem ) { billingClient.queryPurchaseHistoryAsync( BillingClient.SkuType.SUBS) { _, purchases -> val purchase: PurchaseHistoryRecord? = purchases.find { it.sku == oldBillingItem.sku } if (purchase == null) { _billingStatus.postValue( BillingStatus.NoPreviousPlanPurchaseHistory) return@queryPurchaseHistoryAsync } BillingViewModel.kt
157. billingClient.queryPurchaseHistoryAsync( BillingClient.SkuType.SUBS) { _, purchases -> ...省略... getSkuDetails(billingItem) { skuDetails -> val flowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .setOldSku(purchase.sku, purchase.purchaseToken) .build() _billingStatus.postValue(BillingStatus.BillingFlow) billingClient.launchBillingFlow(activity, flowParams) } BillingViewModel.kt
158. billingClient.queryPurchaseHistoryAsync( BillingClient.SkuType.SUBS) { _, purchases -> ...省略... getSkuDetails(billingItem) { skuDetails -> val flowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .setOldSku(purchase.sku, purchase.purchaseToken) .build() _billingStatus.postValue(BillingStatus.BillingFlow) billingClient.launchBillingFlow(activity, flowParams) } BillingViewModel.kt
159. class BillingFragment : Fragment(), View.OnClickListener { ...省略... override fun onClick(v: View?) { billingViewModel.changePlan( requireActivity(), billingItem = BillingItem.MonthlyPremiumPlan, oldBillingItem = BillingItem.MonthlyPlan ) } } BillingFragment.kt
161. アプリからacknowledgeする
162. acknowledgeに対応した支払いフロー ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
163. acknowledgeに対応した支払いフロー ユーザー アプリ サーバー 支払いを行う レシート 承認リクエスト 承認結果 アイテムを渡す Google Play レシートを送信 レシート検証 購入情報を登録 購入結果
164. private fun acknowledgePurchase(purchase: Purchase) { if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED && purchase.isAcknowledged.not()) { val acknowledgePurchaseParams = AcknowledgePurchaseParams.newBuilder() .setPurchaseToken(purchase.purchaseToken) .build() billingClient.acknowledgePurchase( acknowledgePurchaseParams, this /* AcknowledgePurchaseResponseListener */ ) } BillingViewModel.kt
165. private fun acknowledgePurchase(purchase: Purchase) { if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED && purchase.isAcknowledged.not()) { val acknowledgePurchaseParams = AcknowledgePurchaseParams.newBuilder() .setPurchaseToken(purchase.purchaseToken) .build() billingClient.acknowledgePurchase( acknowledgePurchaseParams, this /* AcknowledgePurchaseResponseListener */ ) } BillingViewModel.kt
166. private fun acknowledgePurchase(purchase: Purchase) { if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED && purchase.isAcknowledged.not()) { val acknowledgePurchaseParams = AcknowledgePurchaseParams.newBuilder() .setPurchaseToken(purchase.purchaseToken) .build() billingClient.acknowledgePurchase( acknowledgePurchaseParams, this /* AcknowledgePurchaseResponseListener */ ) } BillingViewModel.kt
167. private fun acknowledgePurchase(purchase: Purchase) { if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED && purchase.isAcknowledged.not()) { val acknowledgePurchaseParams = AcknowledgePurchaseParams.newBuilder() .setPurchaseToken(purchase.purchaseToken) .build() billingClient.acknowledgePurchase( acknowledgePurchaseParams, this /* AcknowledgePurchaseResponseListener */ ) } BillingViewModel.kt
168. class BillingViewModel(application: Application) : ViewModel(), BillingClientStateListener, PurchasesUpdatedListener, LifecycleObserver, AcknowledgePurchaseResponseListener { override fun onAcknowledgePurchaseResponse(billingResult: BillingResult) { if (billingResult.responseCode() == BillingClient.BillingResponseCode.OK) { _billingStatus.postValue(BillingStatus.AcknowledgeSuccess) } else { _billingStatus.postValue(BillingStatus.Error(billingResult)) } } } BillingViewModel.kt
169. プラン変更時の承認処理
170. • 購入アイテムの承認はプラン変更時も同様に 承認しなければならない • プランを変更すると、Google Playの仕様上、 以前のプランがキャンセルされ、新たなプラン を契約するという形になる プラン変更時の承認処理
171. プラン変更時の支払いの流れ ユーザー アプリ Google Play 支払いを行う レシート プランを利用可能にする 以前のプランを解 約 新しいプランを契 約
172. プラン変更時の支払いの流れ ユーザー アプリ Google Play 支払いを行う レシート プランを利用可能にする 以前のプランを解 約 新しいプランを契 約
173. プラン変更時の支払いの流れ ユーザー アプリ Google Play 支払いを行う レシート プランを利用可能にする 以前のプランを解 約 新しいプランを契 約 プラン変更後3日以内に承認しなかった場合は？
174. プラン変更後3日以内に承認しなかった場合 ユーザー アプリ Google Play 支払いを行う レシート プランを利用可能にする 以前のプランを解 約 新しいプランを契 約 3日以内に承認 されていない 払い戻し
175. プラン変更後3日以内に承認しなかった場合 ユーザー アプリ Google Play 支払いを行う レシート プランを利用可能にする 以前のプランを解 約 新しいプランを契 約 3日以内に承認 されていない 払い戻し
176. プラン変更後3日以内に承認しなかった場合 ユーザー アプリ Google Play 支払いを行う レシート プランを利用可能にする 以前のプランを解 約 新しいプランを契 約 3日以内に承認 されていない 払い戻し ユーザーが新たにプランを契約し、 その契約が承認されない状態でプランを変更した場合は？
177. • テスト購入で確認したところ、以前購入したプ ランが承認されていない状態でもプラン変更は 可能 • 承認されていない変更前のプランは払い戻さ れ、変更後のプランが承認されていれば問題 なく契約が継続される プラン変更時の承認処理
178. • 正しく承認しなければプラン契約中のユーザー が解約される事態になってしまう • 確実に承認されるように慎重にフローを組む 必要がある プラン変更時の承認処理
179. Pending transactionsに対応する
180. • 購入後、通常のアプリ課金と同様に onPurchasesUpdatedメソッドに購入結果が 返却される • 保留中の購入はpurchaseStateが PurchaseState.PENDINGになっている Pending transactionsに対応する
181. private fun acknowledgePurchase(purchase: Purchase) { if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED && purchase.isAcknowledged.not()) { ...省略... } else if ( purchase.purchaseState == Purchase.PurchaseState.PENDING ) { _billingStatus.postValue(BillingStatus.PendingPurchase) } } BillingViewModel.kt
182. class BillingFragment : Fragment(), View.OnClickListener { override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) billingViewModel.billingStatus.observe( viewLifecycleOwner, Observer { billingStatus -> when (billingStatus) { BillingStatus.SetupSuccess -> { // 購入履歴を取得して承認する } } }) } BillingFragment.kt
183. AIDLからPlay Billing Libraryに置 き換えた話
185. • マネーフォワード MEでは2019年の3月に年額 プランの提供を開始した • 年額プランを入れる前までは最初に課金が実 装されてからほぼ手が加えられていなかった ため、AIDLで実装されていた AIDLからPBLに置き換えた話
186. • 年額プランを実装する前にAIDLからPBLに置 き換えることにした AIDLからPBLに置き換えた話
187. 1. aidlファイルを削除 2. Play Billing Libraryを導入 3. Play Billing Libraryによる課金実装 4. 古い定形コードを削除 AIDLからPBLに置き換えた話
188. • PBLにIInAppBillingServiceが含まれているた め、aidlはそのままにできないがaidlを削除す れば他はそのままにできる • aidlを先に削除してPBLの実装を行うことでPR を分けてスムーズに移行ができた AIDLからPBLに置き換えた話
189. 新しいアプリアイテムを追加するとき の注意点
190. • 管理対象アイテム • 定期購入 • 特典アイテム アプリアイテムの種類
191. • 管理対象アイテムと特典アイテムはステータス をいつでも切り替えられる • 定期購入は一度有効にすると無効にはできな い 新しいアプリアイテム追加の注意点
192. • 各アイテムにはそれぞれ任意のアイテムIDを 割り当てる必要がある • アイテムの作成後にアイテムIDを変更すること はできない 新しいアプリアイテム追加の注意点
193. • ステータスが無効であればアイテムを削除で きるが、削除したアイテムIDをもう一度使うこと はできない • やり直しが効かない作業のため、アイテム作 成は十分に確認した上で行うべき 新しいアプリアイテム追加の注意点
194. • マネーフォワード MEではもともと月額のプレミ アムプランしか無かった • 金額の違う新しいプランを追加すると金額が分 かってしまう MEで年額課金を追加したときの話
195. 年額プラン追加前
196. 年額プラン追加前
197. 年額プラン追加後
198. 年額プラン追加後
199. • アプリアイテムは、無効状態ではテスト購入で も購入はできないため、必ず有効にする必要 がある ◦ しかし、有効にすると金額が分かってしまう … MEで年額課金を追加したときの話
200. • アイテム名だけ決めて金額は既存のアイテム と同じ金額にしてアイテムを追加 • リリース直前くらいに年額プランの金額を変え ることでギリギリまで金額が見えないようにし た MEで年額課金を追加したときの話
201. 定期購入のアップグレードと ダウングレードについて
202. • 定期購入はプランの変更ができるアップグ レードやダウングレードの機能が提供されてい る • ユーザーは定期購入期間の終了を待たずに プランを変更できる 定期購入のアップグレードとダウングレード
203. • 無料期間を設定していて、すでに無料期間を 終えている場合はプラン変更をしても新たに無 料期間が発生することはない • プラン変更を行うと有効な定期購入はただち にキャンセルされ、新たな定期購入が作成さ れる　 定期購入のアップグレードとダウングレード
204. • 最初の支払いは前の定期購入の未使用分を 使い切った後から始まる 定期購入のアップグレードとダウングレード
205. 月額プラン 500円 / 月 プラン変更 2019年04月15日 年額プラン 5,500円 / 年 支払い日 2019年04月01日
206. 月額プラン 500円 / 月 プラン変更 2019年04月15日 年額プラン 5,500円 / 年 支払い日 2019年04月01日 500円 / 30日 = 16.66円 / 日 250円分使用
207. 月額プラン 500円 / 月 プラン変更 2019年04月15日 年額プラン 5,500円 / 年 支払い日 2019年04月01日 500円 / 30日 = 16.66円 / 日 250円分使用 前プランの残り = 250円
208. 月額プラン 500円 / 月 プラン変更 2019年04月15日 年額プラン 5,500円 / 年 支払い日 2019年04月01日 500円 / 30日 = 16.66円 / 日 250円分使用 前プランの残り = 250円 5,500円 / 365日 = 15.07円 / 日
209. 月額プラン 500円 / 月 プラン変更 2019年04月15日 年額プラン 5,500円 / 年 支払い日 2019年04月01日 500円 / 30日 = 16.66円 / 日 250円分使用 前プランの残り = 250円 5,500円 / 365日 = 15.07円 / 日 250円 / 15.07円 = 約16日分使用可能
210. 月額プラン 500円 / 月 プラン変更 2019年04月15日 年額プラン 5,500円 / 年 支払い日 2019年04月01日 500円 / 30日 = 16.66円 / 日 250円分使用 前プランの残り = 250円 5,500円 / 365日 = 15.07円 / 日 250円 / 15.07円 = 約16日分使用可能 新プラン支払い開始 2019年05月02日
211. • 定期購入アイテム間のアップグレードやダウン グレードの関係性はPlay Consoleから何か紐 付け作業を行うわけではなく、実装をする際に 関連付けを行う 定期購入のアップグレードとダウングレード
212. • 月額のプレミアムプランから年額のプレミアム プランにアップグレードするなどの見せ方も開 発者が定義する 定期購入のアップグレードとダウングレード
213. アプリ課金の検証について
214. • テスト購入 • 本購入 アプリ課金の購入の検証
215. • テスト購入は、アプリ内課金サンドボックスとも 呼ばれている • 実際の課金をすることなく購入できるため、開 発中や販売準備期間にアプリ内課金のテスト を安全かつ手軽に実施できる テスト購入
216. • 請求権限を追加したAPKがアルファ版または ベータ版にすでにアップロードされていれば、 デバッグ中のアプリでもテスト購入が可能（※ パッケージは製品版の必要有） • 特定のライセンステストユーザーが課金を伴 わずにアプリ内アイテムを購入できる テスト購入
221. • 通常のユーザーが正規の支払いプロセスを経 て実際の課金を伴ってアプリ内課金を購入す る方法 • 購入するにはアルファ版またはベータ版として アプリをリリースする必要がある 本購入
222. • 実際のお金がかかるので、新しい課金アイテ ムを追加したときなどのリリース直前の最終 チェックなどで行うとよい 本購入
223. まとめ
224. • PBLのロードマップが発表された ◦ AIDLとPBL 1.xは2021/05/01までにPBL 2.xに移行必須 • PBL 2.xからはすべての購入に対して acknowledgeが必須 ◦ 3日以内に払い戻しされてしまう まとめ
225. • Pending transactionsやアプリ外購入などを 考慮してどの画面からでも購入を検知し、ユー ザーに購入を伝えることが重要 • アプリアイテムの追加や購入の検証は慎重に まとめ
226. • The “Purchase Anywhere” Paradigm Shift (Android Dev Summit '19) ◦ https://youtu.be/L2aiHRD6Pfk • Required Updates and New Functionality (Android Dev Summit '19) ◦ https://youtu.be/Cj5vq1AOJeQ • What's New with Google Play Billing (Google I/O'19) ◦ https://youtu.be/N4004Set4F8 参考資料
227. ありがとうございました