Побочные эффекты изменения фильтра и требования к существующему приложению в Android Play/Market

Никаких предыдущих вопросов об этом, поэтому я спрашиваю.

Фон:

У меня есть старое приложение в бесплатных и платных версиях на Play Market. Я создал новую версию, радикально измененную и с другой платежной системой (бесплатное приложение + только в покупках приложений, не более платная версия: сокращение затрат на обслуживание). minSdkVersion также изменился с 1,5 до 2,1.

Из-за всех этих различий я решил загрузить новое приложение, а не просто обновлять текущее (т.е. не выборочно предоставлять новый apk для API 7+ --- несколько APK). Это особенно важно из-за новой платежной системы, поскольку я не хочу принуждать старых, платных клиентов покупать все снова. Я хочу оставить их в покое и счастливых, как они (рейтинг 4.4/4.7). Короче говоря, я не хочу "принуждать" людей к чему-либо. В этом случае, в снова покупать то же самое через покупки в приложении, помимо других вещей новое приложение предлагает.

Вопросы:

Объяснив вам мой опыт, возникают очевидные вопросы:

1. Как скрыть старые приложения от аудитории API 7+, сохраняя их видимыми для всех существующих клиентов API 7+, т.е. Тех, кто уже купил его?

Мое самое большое беспокойство здесь - платное приложение. Я думаю о том, чтобы нажать новую версию с maxSdkVersion на 6 (SDK 2.0.1), эффективно заблокировав новых пользователей API 7+ старыми приложениями. Но я обеспокоен тем, что нынешние клиенты API 7+ внезапно потеряют доступ к приложению. Это вызывает два вопроса:

2. Смогут ли они продолжать обновлять приложение? разумно ли угадать "да"?

3. Даже если ответ на предыдущий вопрос "да", мне все еще не ясно, что произойдет, если пользователь удалит приложение, а затем снова найдет его на рынке (а не просто обновит). Он исчезнет или будет отображаться в его списке "купленных" приложений, учитывая, что в то же время изменились требования к фильму приложения?

Примечание: Я бы загрузил тестовое приложение, чтобы увидеть это, но автору AFAIK запрещено покупать его собственное приложение (даже лицензия ведет себя по-другому), поэтому я не смог протестировать удаление сценарий установки сценария.

# # # # # # # Ответ на ответы: # # # # # # #

@Sparky:

Я думаю, вы поняли это неправильно. Я знаю свой путь вокруг нескольких АПК и, конечно же, документацию. Проблемным здесь является путь, выходящий за рамки этого.

Заметьте также, что maxSdkVersion устарел, поэтому в ваш проект добавляется немного ключа, чтобы закрыть старый APK при выпуске нового APK.

Спасибо. Я пропустил это.

Несколько APK предлагают более простой пользовательский рассказ.

Если вы так говорите (помимо других вещей, которые я не цитировал), я думаю, вы, вероятно, не обернули вокруг этой проблемы. Пожалуйста, следуйте за мной:

  • У меня есть n платных клиентов, которые купили мою текущую версию приложения Pro.
  • Они используют набор функций X, который у них есть с версией Pro.
  • Теперь я решил реализовать покупки в приложениях, чтобы предложить набор функций X, Y и т.д.
  • К сожалению, эти изменения внесены приложением API 7 +.
  • Таким образом, по вашему мнению, я решил предложить несколько APK.
  • Теперь толпа API 7+ внезапно обновляется до этой новой версии моего приложения.
  • Поскольку они обновляются до нового APK, они LOSE имеют свой набор функций X. Теперь им нужно снова купить X (из меню покупки в приложении). Я взял у них что-то, что у них уже было, хотя и "менее блестящим" способом. Мне нравится, когда я говорю:

Вы либо платите мне снова, либо теряете то, что у вас уже есть.

Вы видите проблему сейчас? Вы видите, почему я вынужден предоставить новое приложение? Или я до сих пор не понимаю, что вы сказали (я думаю, нет)?

ОТВЕТЫ

Ответ 1

Вот вам запомнилась идея:

  • Обновите свое настоящее приложение до приложения в приложении, чтобы включить ContentProvider, который предоставляет криптографический хеш, который только он знает, как генерировать в ответ на случайное семя (чтобы предотвратить повторные атаки).

  • Отпустите новое приложение, которое использует платежи в приложении в качестве отдельного APK, и попросите его проверить наличие более раннего приложения в пользовательской системе, пытаясь получить доступ к только что описанному ContentProvider, передав ему случайное значение и подтверждение правильности ответа. Если такой ответ получен, тогда пользователю принадлежит старое приложение, и вы можете включить соответствующие функции старого приложения в новом приложении, не требуя каких-либо платежей в приложении для этого.

Теперь, если некоторые из ваших пользователей пропустите обновление до старого приложения, которое предоставит им новый ContentProvider, и перейдите прямо к вашему новому приложению, они будут использоваться для платежей. Но они могут обновиться, если захотят, и снова запустите новое приложение, чтобы получить подтверждение.

Это касается вашей проблемы. Однако у него есть свои проблемы. Итак, поместите его в свой набор инструментов и посмотрите, пригодится ли оно, как есть или в сочетании с чем-то другим, которое вы позже можете придумать!

Ответ 2

Вы сделаете себе плохую публикацию нового приложения вместо обновления, не считая, по крайней мере, нескольких 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/

В зависимости от вашей проблемы вы можете предлагать несколько APK на основе уровня API: http://developer.android.com/training/multiple-apks/api.html

Это позволяет поддерживать две версии одного и того же приложения, разделенные уровнем API. Таким образом, ответ на ваш вопрос 1 заключается в реализации нескольких APK в цитированных статьях.

Публикуя новое приложение, ваш ответ на вопрос 2 "да". Реализуя несколько APK, ответ на вопрос 2 также "да", и история вашего приложения/обновления намного проще с точки зрения пользователя (немного сложнее для вас технически, проще в отделе обслуживания клиентов). Обратите также внимание на то, что maxSdkVersion устарел, поэтому вы выбрасываете немного ключа в свое предложение, чтобы закрыть старый APK при выпуске нового APK.

Аналогично вопросу 3. Либо опубликовать новое приложение или внедрить несколько APK, вы можете продолжать предлагать APK для устаревших уровней API, которые ваши пользователи могут найти и установить.

Несколько APK предлагают более простой пользовательский рассказ. Публикация нового приложения упрощает вам различать приложения, если, например, вы хотите сказать: "Посмотрите! Теперь EXTRA блестящий!"