サーバーを使用せずに、部分的に目的を達成する方法を次に示します。
SharedPreferences に一意の値を書き込む新しいバージョンでアプリを更新します。この値は、デバイスに固有の (または少なくとも、他の多くのデバイスが共有しない) ID のハッシュである必要があります。値が比較的一意である必要がある理由は、後のユーザー間で共有されないようにするためです。再インストール後も保持したい場合は、アプリのインストール時に削除されないユーザーの外部メモリの領域に書き込むこともできます。
現在のユーザーのほとんどが新しいバージョンに更新されるまで、十分な時間待ちます。その過程で、このフェーズの新しいユーザーは、SharedPreferences で一意の値も取得します。
一意の ID を書き込まず、ID が存在する場合、またはユーザーがアプリ内課金で支払った場合にのみ課金する機能を有効にする新しいバージョンをリリースします。
これは完全ではありませんが、少なくとも現在のユーザーのほとんどが引き続き機能にアクセスできるようにすることができます。
これが Google Play との契約に違反するかどうかはわかりません。この問題については、ご自身で確認していただく必要があります。アプリを現在のユーザーに無料として提示し、現在その機能の一部を課金したいと考えているという事実は、既存のユーザーの祖父でない限り、虚偽の表示と見なされる可能性があります。また、私が概説したアプローチは、既存のすべてのユーザーにアクセス権が正常に付与されます。
独自のサーバーを使用する必要がある別の回答で提出されたアプローチには、これらと同じ問題があるように見えることに注意してください。これは、サーバーと通信するコードを含む新しいバージョンのアプリをリリースする必要があり、強制する方法がないためです。現在のユーザーが特定の時間内に新しいバージョンに更新できるようにします。それ以外の場合、無料アプリのユーザーは一般に開発者には知られていないため、サーバーのデータベースで現在のユーザーを識別する一意の ID をどのように収集しますか?
よりクリーンなアプローチは、既存の機能と緊密に統合する新しい機能を追加して、それらをより価値のあるものにし、古い機能を使用して既に入力されたコンテンツをより価値のあるものにすることです. 既存の機能は引き続き無料で提供できますが、新しい機能は有料になります。
このアプローチを採用することで、現在のユーザーが機能を奪われることはなく、付加価値機能に対して (新規ユーザーだけでなく) 現在のユーザーに課金することもできます。このアプローチを使用すると、ユーザーにとってより快適になるだけでなく、現在のユーザーベース全体が潜在的な有料顧客になるため、潜在的により報酬が高くなる可能性があります.
また、アプリの現在の人気は、課金したい機能によるものである可能性が高いと考えるかもしれません。そのため、これらの機能が無料でなくなると、継続的な新規ユーザーの流れを引き付けることができなくなる可能性があります.