Effetti collaterali della modifica del filtro e dei requisiti di un'app esistente in Android Play/Market

Question

Nessuna domanda precedente, quindi qui chiedo.

Background:

Ho un vecchio app, in libera e pagato versioni, nel mercato Play. Ho creato una nuova versione, radicalmente modificata e con un sistema di pagamento diverso (app gratuita + solo negli acquisti di app, non più una versione a pagamento: riduzione dei costi di manutenzione). minSdkVersion cambiato anche da 1.5 a 2.1.

A causa di tutte queste differenze, ho deciso di caricare una nuova app, non solo aggiornare quella corrente (cioè non fornire selettivamente un nuovo apk per API 7+ --- più APK). Ciò è particolarmente importante a causa del nuovo sistema di pagamento, in quanto non voglio forzare i clienti vecchi e retribuiti a ricomprare tutto. Voglio lasciarli soli e felici così come sono (voto 4.4/4.7). In breve, non voglio "forzare" le persone in qualcosa. In questo caso, in acquistando di nuovo la stessa cosa tramite acquisti in-app, oltre ad altre offerte della nuova app.

Domande:

Dopo aver spiegato a voi il mio background, solleva le domande ovvie:

1. Come faccio a nascondere le vecchie applicazioni da API 7+ pubblico pur mantenendo sono visibili a tutti gli attuali clienti di API 7+, cioè a quelli che l'hanno già acquistato?

La mia più grande preoccupazione è l'app a pagamento. Sto pensando di spingere una nuova versione con maxSdkVersion impostata su 6 (SDK 2.0.1), bloccando in modo efficace i nuovi clienti API 7+ alle vecchie app. Ma temo che gli attuali clienti di API 7+ perderanno improvvisamente l'accesso all'app. Ciò solleva due domande:

2. Saranno in grado di continuare ad aggiornare l'app? è ragionevole indovinare "sì"?

3. Anche se la risposta alla domanda precedente è "sì", non è ancora chiaro per me che cosa accadrà se l'utente disinstalla l'applicazione, e poi andare a trovare di nuovo nel mercato (non solo l'aggiornamento) . Scomparirà o apparirà ancora sotto la sua lista di app "comprate", considerando che nel frattempo i requisiti del filtro app sono cambiati?

Nota: vorrei caricare un applicazione di test per vedere che, ma per quanto ne so l'autore non è permesso di acquistare la propria app (anche della licenza comporta in modo diverso), quindi non ho potuto testare la uninstall- scenario di installazione del filtro.

---

---

---

# # # # # # # Rispondi a risposte: # # # # # # #

@Sparky:

penso ti sei sbagliato. Conosco molti degli APK e, naturalmente, la documentazione. Il problema qui è ben oltre.

Si noti inoltre che maxSdkVersion è deprecato, quindi questo getta un po 'di una chiave nella vostra proposta di limitare il vecchio APK quando si emette il nuovo APK.

Grazie. Ho perso questo.

APK multipli offre una user story più semplice.

Se lo dici tu (oltre alle altre cose che non ho citato), penso che probabilmente non hai pensato a questo problema. Si prega di seguire me:

1. devo n pagato i clienti che hanno acquistato il mio attuale versione Pro app.
2. Si sta utilizzando il set di funzioni X che hanno con la versione Pro.
3. decido ora da implementare in-app-acquisti di offrire set di funzionalità X, Y e così via ...
4. Purtroppo, queste modifiche apportate da un'applicazione API 7+.
5. Pertanto, come suggerito, decido di offrire più APK.
6. Ora, la folla di API 7+ viene improvvisamente aggiornata a questa nuova versione della mia app.
7. Perché l'aggiornamento alla nuova APK, hanno perdere loro set di funzionalità X. Ora devono acquistare di nuovo X (dal menu di acquisto in-app). Ho preso da loro qualcosa che avevano già, anche se in un modo "meno brillante". E 'come me dicendo:

Si sia me pagare di nuovo o si perde ciò che hai già.

Vedete ora il problema? Capisci perché sono costretto a a fornire una nuova app? O non riesco ancora a ottenere quello che hai detto (penso di no)?

Answer 1

Ecco un'idea non ancora sperimentato per la vostra considerazione:

• Amplia il tuo presente, pre-in-app-pagamenti app per includere un ContentProvider che fornisce un hash crittografico che solo sa come generare in risposta a un seme casuale (per impedire attacchi di replay).

• Rilascia la tua nuova app che utilizza i pagamenti in-app come APK separato e fa controllare l'esistenza dell'app precedente sul sistema dell'utente tentando di accedere al ContentProvider appena descritto, passandogli un valore casuale e confermando che la risposta è corretta. Se tale risposta viene ricevuta, l'utente possiede la vecchia app e puoi abilitare le funzioni corrispondenti della vecchia app nella nuova app senza richiedere alcun pagamento in-app.

Ora, se alcuni utenti saltare l'aggiornamento alla vecchia app che dà loro la nuova ContentProvider, e andare dritto per la tua nuova applicazione, saranno dinged per i pagamenti. Ma possono quindi eseguire l'aggiornamento, se lo desiderano, ed eseguire nuovamente la nuova app per essere convalidati.

Questo risolve il problema. Tuttavia, ha problemi a sé stanti. Quindi, mettilo nel tuo kit di attrezzi e vedi se è utile, così com'è o in combinazione con qualcos'altro che potresti escogitare in seguito!

Answer 2

Ti farai un disservizio emettendo una nuova app invece di un aggiornamento senza considerare almeno più APK, perché complica l'aggiornamento degli utenti a pagamento esistenti.

Supponiamo di aggiornare semplicemente l'app a pagamento al livello API 7, ridurre il prezzo a 0 e aggiungere pagamenti in-app. Ai dispositivi con livello API> = 7 verrà offerto un aggiornamento, mentre i dispositivi con livello API < = 6 non verranno notificati, non lo vedranno in Play (Mercato) e non potranno essere reinstallati se si disinstalla. Questo sarebbe 'no' alle vostre domande 2 e 3.

Ma ora è possibile implementare diversi APK: http://developer.android.com/guide/market/publishing/multiple-apks.html http://developer.android.com/training/multiple-apks/

Specifico per il tuo problema, puoi offrire più APK in base al livello API: http://developer.android.com/training/multiple-apks/api.html

Ciò consente di gestire due versioni della stessa app, separate dal livello API. Quindi la risposta alla domanda 1 è, implementa più APK per gli articoli citati.

Pubblicando una nuova app, la risposta alla domanda 2 è "sì". Implementando più APK, la risposta alla domanda 2 è anche "sì", e la storia di lineage/aggiornamento dell'applicazione è molto più semplice dal punto di vista dell'utente (un po 'più difficile per te tecnicamente, più facile nel reparto di assistenza clienti). Nota anche che maxSdkVersion è deprecato, quindi questo genera un po 'di chiave nella tua proposta per limitare il vecchio APK quando si rilascia il nuovo APK.

Allo stesso modo con la domanda 3. O pubblicando una nuova app o implementando più APK, è possibile continuare a offrire un APK per i livelli di API legacy che gli utenti possono trovare e installare.

Gli APK multipli offrono una user story più semplice. Pubblicare una nuova app facilita la differenziazione delle app, se per esempio vuoi dire "Guarda! Ora EXTRA lucido!"