Création d'une application d'essai Android qui expire après une période de temps fixe

Question

J'ai une application que je veux mettre sur le marché en tant qu'application payante. J'aimerais avoir une autre version qui serait une version "d'essai" avec une limite de temps de, disons, 5 jours?

Comment puis-je procéder?

Answer 1

Actuellement, la plupart des développeurs accomplissent cela en utilisant l'une des 3 techniques suivantes.

La première approche est facilement contournable, la première fois que vous exécutez l'application, enregistrez la date/heure dans un fichier, une base de données ou des préférences partagées et à chaque fois que vous exécutez l'application par la suite, vérifiez si la période d'essai est terminée. C'est facile à contourner car désinstaller et réinstaller permet à l'utilisateur d'avoir une autre période d'essai.

La deuxième approche est plus difficile à contourner, mais reste contournable. Utilisez une bombe à retardement codée en dur. Fondamentalement, avec cette approche, vous coderez en dur une date de fin pour l'essai, et tous les utilisateurs qui téléchargent et utilisent l'application cesseront de pouvoir l'utiliser simultanément. J'ai utilisé cette approche car elle est facile à mettre en œuvre et pour la plupart je n'avais tout simplement pas envie de passer par les tracas de la troisième technique. Les utilisateurs peuvent contourner cela en changeant manuellement la date sur leur téléphone, mais la plupart des utilisateurs ne prendront pas la peine de le faire.

La troisième technique est la seule façon dont j'ai entendu parler pour vraiment accomplir ce que vous voulez faire. Vous devrez mettre en place un serveur, et ensuite chaque fois que votre application est lancée, votre application envoie l' [identifiant unique du téléphone](http://developer.android.com/reference/android/telephony/TelephonyManager.html#getDeviceId()) au serveur. Si le serveur ne possède pas d'entrée pour cet identifiant de téléphone, il en crée une nouvelle et enregistre l'heure. Si le serveur a une entrée pour l'identifiant du téléphone, il effectue simplement une vérification pour voir si la période d'essai est expirée. Il communique ensuite les résultats de la vérification d'expiration de l'essai à votre application. Cette approche ne devrait pas être contournable, mais nécessite la mise en place d'un serveur web, etc.

Il est toujours recommandé de faire ces vérifications dans le onCreate. Si la période d'expiration est terminée, affichez une AlertDialog avec un lien vers le marché vers la version complète de l'application. Incluez uniquement un bouton "OK", et une fois que l'utilisateur clique sur "OK", faites un appel à "finish()" pour mettre fin à l'activité.

Answer 2

C'est une vieille question mais de toute façon, cela pourrait aider quelqu'un.

Si vous souhaitez opter pour l'approche la plus simpliste (qui échouera si l'application est désinstallée/réinstallée ou si l'utilisateur modifie manuellement la date de son appareil), voici comment cela pourrait être :

private final SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
private final long ONE_DAY = 24 * 60 * 60 * 1000;

@Override
protected void onCreate(Bundle state){
    SharedPreferences preferences = getPreferences(MODE_PRIVATE);
    String installDate = preferences.getString("InstallDate", null);
    if(installDate == null) {
        // Première exécution, enregistrer la date actuelle
        SharedPreferences.Editor editor = preferences.edit();
        Date now = new Date();
        String dateString = formatter.format(now);
        editor.putString("InstallDate", dateString);
        // Enregistrer les modifications !
        editor.commit();
    }
    else {
        // Ce n'est pas la première exécution, vérifier la date d'installation
        Date before = (Date)formatter.parse(installDate);
        Date now = new Date();
        long diff = now.getTime() - before.getTime();
        long days = diff / ONE_DAY;
        if(days > 30) { // Plus de 30 jours ?
             // Expiré !!!
        }
    }

    ...
}

Answer 3

Cette question et la réponse de snctln m'ont inspiré à travailler sur une solution basée sur la méthode 3 pour mon mémoire de licence. Je sais que l'état actuel n'est pas destiné à un usage productif mais j'aimerais savoir ce que vous en pensez! Utiliseriez-vous un tel système? Aimeriez-vous le voir comme un service cloud (sans avoir de problème avec la configuration d'un serveur)? Craignez-vous des problèmes de sécurité ou de stabilité?

Dès que j'aurai terminé la procédure de licence, je souhaite continuer à travailler sur le logiciel. C'est maintenant le moment où j'ai besoin de vos retours!

Le code source est hébergé sur GitHub https://github.com/MaChristmann/mobile-trial

Quelques informations sur le système : - Le système a trois parties, une bibliothèque Android, un serveur node.js et un configurateur pour gérer plusieurs applications d'essai ainsi que des comptes éditeur/développeur.

• Il prend en charge uniquement les essais basés sur le temps et utilise votre compte (Play Store ou autre) plutôt qu'un ID de téléphone.

• Pour la bibliothèque Android, elle est basée sur la bibliothèque de vérification de licence Google Play. Je l'ai modifiée pour se connecter au serveur node.js et en plus la bibliothèque essaie de reconnaître si un utilisateur a changé la date du système. Elle met également en cache une licence d'essai récupérée dans les préférences partagées cryptées AES. Vous pouvez configurer la durée de validité du cache avec le configurateur. Si un utilisateur "efface les données", la bibliothèque forcera une vérification côté serveur.

• Le serveur utilise https et signe également numériquement la réponse de vérification de licence. Il possède également une API pour CRÉER, LIRE, METTRE À JOUR et SUPPRIMER des applications d'essai et des utilisateurs (éditeur et développeur). De la même manière que la bibliothèque de vérification de licence, les développeurs peuvent tester leur implémentation comportementale dans l'application d'essai avec un résultat de test. Ainsi, dans le configurateur, vous pouvez définir explicitement votre réponse de licence à "licenciée", "non licenciée" ou "erreur serveur".

• Si vous mettez à jour votre application avec une nouvelle fonctionnalité géniale, vous voudrez peut-être que tout le monde puisse l'essayer à nouveau. Dans le configurateur, vous pouvez renouveler la licence d'essai pour les utilisateurs dont les licences ont expiré en définissant un code de version qui devrait déclencher cela. Par exemple, si un utilisateur exécute votre application sur le code de version 3 et que vous souhaitez qu'il essaie les fonctionnalités du code de version 4. S'il met à jour l'application ou la réinstalle, il peut à nouveau utiliser la période d'essai complète car le serveur sait sur quelle version il l'a essayée la dernière fois.

• Tout est sous la licence Apache 2.0

Answer 4

La manière la plus facile et meilleure de faire cela est de mettre en œuvre BackupSharedPreferences.

Les préférences sont préservées, même si l'application est désinstallée et réinstallée.

Sauvegardez simplement la date d'installation en tant que préférence et vous êtes prêt à partir.

Voici la théorie : http://developer.android.com/reference/android/app/backup/SharedPreferencesBackupHelper.html

Voici l'exemple : Android SharedPreferences Backup Not Working

Answer 5

Maintenant, dans la version récente d'Android, un abonnement d'essai gratuit a été ajouté, vous pouvez débloquer toutes les fonctionnalités de votre application uniquement après avoir acheté l'abonnement dans l'application pour une période d'essai gratuite. Cela permettra à l'utilisateur d'utiliser votre application pendant une période d'essai, si l'application est toujours désinstallée après la période d'essai, l'argent de l'abonnement sera transféré à vous. Je n'ai pas essayé, mais je partage juste une idée.

Voici la documentation