11

それについての以前の質問はないので、ここで私は尋ねます。

バックグラウンド:

Playマーケットに、無料版と有料版の古いアプリがあります。私は新しいバージョンを作成し、根本的に変更し、別の支払いシステムを使用しました(無料アプリ+アプリ購入のみ、有料バージョンではありません:メンテナンスコストを削減します)。minSdkVersionまた、1.5から2.1に変更されました。

これらすべての違いのため、現在のアプリを更新するだけでなく、新しいアプリをアップロードすることにしました(つまり、API 7+に新しいapkを選択的に提供しない---複数のAPK)。これは、新しい支払いシステムのために特に重要です。古い有料の顧客にすべてを再度購入するように強制したくないからです。そのままにして幸せにしたいと思います(4.4 / 4.7レーティング)。要するに、私は人々を何かに「強制」したくありません。この場合、新しいアプリが提供する他のものに加えて、アプリ内購入を通じて同じものを再度購入することになります。

質問:

私の経歴をあなたに説明したので、それは明白な質問を提起します:

1. API 7以降のすべての顧客、つまりすでにアプリを購入した顧客に表示したまま、古いアプリをAPI7以降のオーディエンスから非表示にするにはどうすればよいですか。

ここでの私の最大の関心事は有料アプリです。6に設定された新しいバージョンmaxSdkVersion(SDK 2.0.1)をプッシュして、新しいAPI7以降の顧客を古いアプリに効果的にブロックすることを考えています。しかし、現在のAPI7以降のお客様が突然アプリにアクセスできなくなるのではないかと心配しています。それは2つの質問を提起します:

2.彼らはアプリを更新し続けることができますか?「はい」と推測するのは合理的ですか?

3.前の質問に対する答えが「はい」であったとしても、ユーザーがアプリをアンインストールしてから、(更新するだけでなく)マーケットで再度検索するとどうなるかは、私にはまだわかりません。その間にアプリのフィルター要件が変更されたことを考えると、それは消えますか、それとも彼の「購入した」アプリリストの下に表示されますか?

備考:テストアプリをアップロードして確認しますが、作成者が自分のアプリを購入することは許可されていないため(ライセンスの動作が異なる場合でも)、アンインストール-フィルター-インストールのシナリオをテストできませんでした。




#######回答への返信:#######

@スパーキー:

私はあなたがそれを間違えたと思います。私は複数のAPK、そしてもちろんドキュメントを回避する方法を知っています。ここで問題となるのはそれをはるかに超えています。

また、これは非推奨であることに注意maxSdkVersionしてください。これにより、新しいAPKを発行するときに、古いAPKに上限を設定するための提案に少しレンチがかかります。

ありがとうございました。私は逃しました。

複数のAPKは、よりシンプルなユーザーストーリーを提供します。

あなたがそう言うなら(私が引用しなかった他のことを除いて)、あなたはおそらくこの問題に頭を悩ませていなかったと思います。私に従ってください:

  1. 現在のProアプリバージョンを購入した有料の顧客はn人います。
  2. 彼らは、Proバージョンで持っている機能セットXを使用しています。
  3. 私は今、アプリ内購入を実装して、機能セットXYなどを提供することにしました...
  4. 残念ながら、これらの変更はアプリAPI7以降によって行われました。
  5. したがって、あなたがそう示唆するように、私は複数のAPKを提供することにしました。
  6. 現在、API 7以降の群衆は、私のアプリのこの新しいバージョンに突然更新されます。
  7. 新しいAPKに更新されるため、機能セットXが失われます。Xを再度購入する必要があります(アプリ内購入メニューから)。「光沢が少ない」方法ではありますが、私は彼らからすでに持っているものを取り出しました。それは私が言っているようなものです:

あなたは私にもう一度支払うか、あなたがすでに持っているものを失うかのどちらかです。

あなたは今問題を見ますか?私が新しいアプリを提供せざるを得ない理由がわかりますか?それとも私はまだあなたが言ったことを理解していませんか(私はそうではないと思います)?

4

2 に答える 2

1

既存の有料ユーザーのアップグレードが複雑になるため、少なくとも複数のAPKを考慮せずに、更新の代わりに新しいアプリを発行することに不利益を被ることになります。

有料アプリをAPIレベル7に更新し、価格を0に下げて、アプリ内支払いを追加するとします。APIレベル>=7のデバイスにはアップグレードが提供されますが、APIレベル<= 6のデバイスは通知されず、Play(Market)に表示されず、アンインストールすると再インストールできません。それはあなたの質問2と3には「ノー」です。

しかし今では、複数のAPKを実装することが可能です:http: //developer.android.com/guide/market/publishing/multiple-apks.html http://developer.android.com/training/multiple-apks/

問題に固有に、APIレベルに基づいて複数のAPKを提供できます:http: //developer.android.com/training/multiple-apks/api.html

これにより、APIレベルで区切られた同じアプリの2つのバージョンを維持できます。したがって、質問1の答えは、引用された記事ごとに複数のAPKを実装することです。

まったく新しいアプリを公開することで、質問2に対する答えは「はい」になります。複数のAPKを実装することで、質問2の答えも「はい」になります。アプリケーションの系統/アップグレードのストーリーは、ユーザーの観点からははるかに単純です(技術的には少し難しく、カスタマーサービス部門では簡単です)。また、これは非推奨であることに注意maxSdkVersionしてください。これにより、新しいAPKを発行するときに、古いAPKに上限を設定するための提案に少しレンチがかかります。

質問3と同様に、新しいアプリを公開するか、複数のAPKを実装することで、ユーザーが見つけてインストールできるレガシーAPIレベルのAPKを提供し続けることができます。

複数のAPKは、よりシンプルなユーザーストーリーを提供します。新しいアプリを公開すると、たとえば「見て!今すぐさらに光沢がある!」と言いたい場合に、アプリを簡単に区別できるようになります。

于 2012-04-13T11:17:20.347 に答える
1

これがあなたの考慮のための未熟な考えです:

  • 現在のアプリ内支払いアプリをアップグレードして、ランダムシードに応答して生成する方法を知っている暗号化ハッシュを提供するContentProviderを含めます(リプレイ攻撃を防ぐため)。

  • アプリ内支払いを別のAPKとして使用する新しいアプリをリリースし、今説明したContentProviderにアクセスしてランダムな値を渡し、応答が正しい。そのような応答を受け取った場合、ユーザーは古いアプリを所有しており、アプリ内支払いを必要とせずに、新しいアプリで古いアプリの対応する機能を有効にすることができます。

これで、一部のユーザーが新しいContentProviderを提供する古いアプリへのアップグレードをスキップして、新しいアプリに直接アクセスすると、支払いが滞ります。ただし、必要に応じてアップグレードし、新しいアプリを再度実行して検証を受けることができます。

これはあなたの問題に対処します。ただし、独自の問題があります。それで、それをあなたのツールキットに入れて、それがそのままで、または後で考案するかもしれない何かと組み合わせて、それが役に立つかどうか確かめてください!

于 2012-05-30T05:18:02.090 に答える