Побочные эффекты изменения фильтра и требований существующего приложения в 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 автору не разрешено покупать собственное приложение (даже лицензия ведет себя иначе), поэтому я не мог » t протестировать сценарий удаления-установки-фильтра.




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

@Sparky:

Я думаю, вы ошиблись. Я знаю несколько APK и, конечно же, документацию. Проблема здесь не только в этом.

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

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

Использование нескольких APK упрощает пользовательскую историю.

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

  1. У меня n платных клиентов, которые купили мою текущую версию приложения Pro.
  2. Они используют набор функций X, который у них есть в версии Pro.
  3. Теперь я решил реализовать покупки в приложении, чтобы предложить набор функций X, Y и так далее ...
  4. К сожалению, эти изменения внесены в приложение API 7+.
  5. Таким образом, как вы предлагаете, я решил предложить несколько APK.
  6. Теперь толпа API 7+ внезапно обновляется до этой новой версии моего приложения.
  7. Поскольку они обновляются до нового APK, они ПОТЕРЯЮТ свой набор функций X. Теперь им нужно снова купить X (из меню покупок в приложении). Я взял у них то, что у них уже было, хотя и «менее блестящим». Это как я говорю:

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

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


person davidcesarino    schedule 04.04.2012    source источник
comment
+1 За гениально сформулированный и точный вопрос. И я, конечно, хотел бы узнать ответ и на этот вопрос.   -  person Siddharth Lele    schedule 04.04.2012
comment
Что ж, то, что я обычно видел, это то, что: A) Возьмите свое старое приложение и снова выпустите его с совместимостью ‹2.1. Б) Выпустите, обновите текущее приложение до новой архитектуры с более высокими требованиями к API. Результат: старые клиенты с версией 2.1+ смогут увидеть обновление и обновить ваше приложение, старые клиенты с ‹2.1 не увидят обновления и будут иметь свое старое приложение. Это работает, только если вы больше не планируете обновлять старое приложение.   -  person Ali    schedule 04.04.2012
comment
Сиддхарт, спасибо. Али, А не работает, потому что я не хочу отказываться от своих старых клиентов. Я не хочу отказываться от своей текущей базы пользователей, а также от моих текущих достижений, комментариев и т. Д. Я просто хочу заблокировать новых клиентов, не мешая ничему текущим. B - это именно то, чего я не хочу: заставлять текущих клиентов покупать все снова, потому что у них не будет новых покупок в приложениях, но у них уже есть (некоторые) функции. Это юридическая катастрофа, поэтому я решил вообще использовать новое приложение.   -  person davidcesarino    schedule 04.04.2012
comment
Кроме того, я планирую продолжать исправлять ошибки в текущем приложении, и я не хочу предавать забвению клиентов api 6-. Также катастрофа - отнимать у них то, что они уже купили. Он также не объясняет, что произойдет, если они удалят и попытаются установить снова из купленного списка.   -  person davidcesarino    schedule 04.04.2012
comment
Если вам понравился этот вопрос, вы можете проголосовать за него на следующей встрече / видеовстрече разработчиков Android ... goo.gl/ mod / d0HR, поскольку это, вероятно, требует от них ответа, гораздо больше, чем от нас здесь, в stackoverflow.   -  person davidcesarino    schedule 09.04.2012
comment
+1 за хороший и интересный вопрос! Я очень хочу прочитать ответ   -  person Paaske    schedule 10.04.2012


Ответы (2)


Вот еще одна неопробованная идея на ваше рассмотрение:

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

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

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

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

person Carl    schedule 30.05.2012

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

Предположим, вы просто обновили свое платное приложение до уровня API 7, снизили его цену до 0 и добавили In-App Payments. Устройствам с уровнем 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 упрощает пользовательскую историю. Публикация нового приложения облегчает вам различение приложений, например, если вы хотите сказать: «Смотри! Теперь ДОПОЛНИТЕЛЬНО блестит!»

person Sparky    schedule 13.04.2012
comment
Обновленный вопрос с вашими комментариями. Насколько я понимаю, вы не решили основную проблему моей проблемы: текущие клиенты API 7+ должны покупать тот же набор функций версии Pro, что и покупки в приложении. См. Ответ на свой комментарий в вопросе. См. Перечисление. Спасибо. - person davidcesarino; 13.04.2012