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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

На мой взгляд, у вас есть две возможности «отключить» обновления:

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

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

---

EDIT:

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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