Как запретить некоторым пользователям обновлять приложение с Android-рынка?

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

Так можем ли мы каким-то образом предложить рыночному приложению не предлагать обновления для конкретного пользователя или какой-либо взлом для достижения этой цели?

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

Solutions Collecting From Web of "Как запретить некоторым пользователям обновлять приложение с Android-рынка?"

Как я вижу это, у вас есть два варианта «отключить» обновления:

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

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


РЕДАКТИРОВАТЬ:

Полностью согласен, что приведенные выше варианты являются громоздкими и на самом деле не решают проблему как есть.

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

Я предполагаю, что у вас уже есть большая часть этой инфраструктуры, чтобы обрабатывать распространение данных.

Могут ли данные не содержать номер «формат версии» в начале файла?

Затем вы можете запрограммировать приложение для чтения файлов версии 1, для нового приложения требуется больше полей в источнике данных, поэтому вы создаете данные 2-й версии, добавляя дополнительные поля, приложение версии 1 видит, что данным требуется новое приложение, поэтому сообщает пользователю обновить.

Приложение Version 2 должно знать, как читать файлы версии 1 и файлы версии 2 (возможно, создать интерфейс Reader и реализовать загрузчики для разных версий файлов.)

Вам придется обрабатывать недостающие данные в файлах v1 / old в загрузчике в приложении v2. Загрузка старых файлов является самым приятным способом для клиента, так как приложение не должно просто перестать работать после обновления.

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

Ок. Я видел, что один из плакатов подсказывает, что у вас есть способ прочитать старые данные.
Сначала это, скорее всего, лучший вариант, но, как вы говорите, ваши приложения беспорядок. Вы должны потратить некоторое время на перенос чтения / записи данных на уровень абстракции. Боль, которую вы испытываете на (вероятно, менее 4-летнем проекте), только ухудшится.

Хорошо .. так вот как я справился с этим в долговечных приложениях ..

Создайте путь миграции. Создайте новый вызов класса Миграция. В нем есть несколько функций для преобразования версии файла с n на n-1 convert_1_to_2 (имя_файла) {проверьте версию и обновите данные.) Convert_2_to_3 (fileName) …

Я подозреваю, что у вас есть старый код, и вы можете написать метод для преобразования одного бита данных в следующий. Когда вы добавляете новые функции в данные, вы создаете новый конверт. Никакое знание о более ранних из них не было бы И все было бы хорошо и самодостаточно. У вас могут быть и суб-миграции, поэтому частично по циклу dev вы можете конвертировать_3a_to_3b.

Теперь … вы можете архивировать исходную версию данных, если пользователь хочет вернуться.

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

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

Я придумал вариант, который на рынке будет содержать установщик, который будет загружать и устанавливать другой .apk содержащий ядро ​​приложения локально.

У нас уже есть диалоговое окно установщика в приложении для загрузки данных, и пользователь должен ввести его при первом использовании приложения, поэтому он также может быть ответственным за ядро ​​приложения.

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