Oh! Android
  1. Oh! Android
  3. Побочные эффекты изменения фильтра и требования к существующему приложению в Android Play / Market
Intereting Posts
Android Studio добавляет библиотеку rxjava Как отключить строку состояния или панель уведомлений, но не отключить строку заголовка в android? Как настроить экран приложения Google для приложений Android espresso testing: пустой набор тестов. Не было найдено никаких тестов Можно ли установить фоновый цвет значка в ящике уведомлений на Android, если используется Parse Push? Хорошие инструменты для разработки графического интерфейса в Android? Почему мое приложение запрашивает разрешение на использование телефона? Использование разных стилей шрифтов в TextView Android – Каков правильный способ сохранения / восстановления адаптера ListView? Отказ от поддержки библиотеки v7. Что я не так? ArrayAdapter IndexOutOfBoundsException Сохранение нескольких объектов ParseFile в одном ParseObject OBD2 – симулятор Bluetooth ELM327 Как расширить 2 класса? Как сделать скриншоты эмулятора с помощью Eclipse?

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

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

Задний план:

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

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

Вопросов:

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

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

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

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

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

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

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

@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, они LOSE свой набор функций X. Теперь им нужно снова купить X (из меню покупок в приложении). Я взял у них то, что у них уже было , хотя и «менее блестящим». Это похоже на то, что я говорю:

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

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

Вот вам затеянная идея:

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

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

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

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

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