Efectos secundarios de cambiar el filtro y los requisitos de una aplicación existente en Android Play/Market

Question

No tengo preguntas previas, así que aquí pregunto.

Antecedentes:

Tengo una aplicación de edad, en libre y versiones de pago, en el Mercado de reproducción. Creé una nueva versión, radicalmente cambiada y con un sistema de pago diferente (aplicación gratuita + solo en compras de aplicaciones, no más una versión de pago: reducir los costos de mantenimiento). minSdkVersion también cambió de 1.5 a 2.1.

Debido a todas esas diferencias, decidí subir una nueva aplicación, no solo actualizar la actual (es decir, no proporcionar selectivamente una nueva aplicación para la API 7+ --- múltiples APK). Esto es especialmente importante debido al nuevo sistema de pago, ya que no quiero obligar a los clientes antiguos y pagos a comprar todo de nuevo. Quiero dejarlos solos y felices como están (4.4/4.7 calificación). En resumen, no quiero "forzar" a la gente a nada. En este caso, en comprando de nuevo lo mismo a través de compras en la aplicación, además de otras cosas que ofrece la nueva aplicación.

Preguntas:

Tras explicar que a mis antecedentes, se plantea la pregunta obvia:

1. ¿Cómo oculto las antiguas aplicaciones de la API 7+ audiencia mientras se mantiene visibles para todos los clientes API 7+ actuales, es decir, aquellos que ya lo compraron?

Mi mayor preocupación aquí es la aplicación de pago. Estoy pensando en impulsar una nueva versión con maxSdkVersion establecida en 6 (SDK 2.0.1), lo que efectivamente bloquea el acceso de los nuevos clientes API 7+ a las aplicaciones anteriores. Pero me preocupa que los clientes API 7+ actuales de repente pierdan el acceso a la aplicación. Eso genera dos preguntas:

2. ¿Podrán seguir actualizando la aplicación? ¿Es razonable adivinar "sí"?

3. Incluso si la respuesta a la pregunta anterior es "sí", aún no está claro qué sucederá si el usuario desinstala la aplicación y luego vuelve a buscarla en Market (no solo actualizando) . ¿Desaparecerá o seguirá apareciendo en su lista de aplicaciones "compradas", teniendo en cuenta que, mientras tanto, los requisitos de filtro de la aplicación cambiaron?

Observación: Me gustaría subir una aplicación de prueba para ver eso, pero que yo sepa el autor no se le permite comprar su propia aplicación (incluso la licencia comporta de manera diferente), así que no pude probar la uninstall- escenario de instalación de filtro.

---

---

---

# # # # # # # Responder a respuestas: # # # # # # #

@Sparky:

creo lo entendiste mal. Conozco muchos APK y, por supuesto, la documentación. La problemática aquí va mucho más allá.

Nótese también que maxSdkVersion está en desuso, por lo que esto arroja un poco de una llave en su propuesta para limitar el viejo APK cuando se emite el nuevo APK.

Gracias. Me lo perdí.

Varios APK ofrece una historia de usuario más sencilla.

Si dices eso (además de las otras cosas que no cité), creo que probablemente no hayas entendido este problema. Por favor, sígame:

1. que tienen n clientes que compraron mi actual versión Pro aplicación de pago.
2. Están utilizando el conjunto de características X que tienen con la versión Pro.
3. que decidir ahora a aplicar en-app-compras para ofrecer conjunto de características X, Y y así sucesivamente ...
4. Desafortunadamente, estos cambios realizados por la aplicación API 7+.
5. Por lo tanto, como usted sugiere, decido ofrecer múltiples APK.
6. Ahora, la multitud API 7+ de repente se actualiza a esta nueva versión de mi aplicación.
7. Debido a que actualicen a la nueva APK, que PERDER su conjunto de características X . Ahora necesitan comprar X nuevamente (desde el menú de compra en la aplicación). Tomé de ellos algo que ya tenían, aunque de una manera "menos brillante". Es como si yo dijera:

Usted o me pagan de nuevo o perder lo que ya tiene.

¿Ves el problema ahora? ¿Ves por qué estoy obligado para proporcionar una nueva aplicación? ¿O todavía no entiendo lo que dijiste (creo que no)?

Answer 1

Aquí es una idea no probada para su consideración:

• Actualiza tu presente, pre-in-app-pagos aplicación para incluir un ContentProvider que proporciona un hash criptográfico que sólo se sabe cómo generar en respuesta a una semilla aleatoria (para evitar ataques de repetición).

• Libere su nueva aplicación que utiliza los pagos en la aplicación como un APK por separado, y haga que compruebe la existencia de la aplicación anterior en el sistema del usuario intentando acceder al ContentProvider que acaba de describirse, pasándole un valor aleatorio y confirmando que la respuesta es correcta. Si se recibe dicha respuesta, el usuario es dueño de la aplicación anterior y puede habilitar las funciones correspondientes de la aplicación anterior en la nueva aplicación sin que sea necesario ningún pago en la aplicación para hacerlo.

Ahora, si algunos de sus usuarios omitir la actualización a la aplicación de edad que les da la nueva ContentProvider, e ir directamente a su nueva aplicación, que van a ser dinged para los pagos. Pero luego pueden actualizar si les gusta y ejecutar la nueva aplicación nuevamente para obtener la validación.

Esto soluciona su problema. Sin embargo, tiene problemas propios. Por lo tanto, colóquelo en su kit de herramientas y vea si es útil, como lo es o en combinación con otra cosa que luego podrá idear.

Answer 2

Usted hará un flaco favor emitiendo una nueva aplicación en lugar de una actualización sin al menos considerar múltiples APK, porque complica la actualización de sus usuarios pagados existentes.

Supongamos que simplemente actualiza su aplicación paga al nivel 7 de la API, reduce su precio a 0 y agrega pagos dentro de la aplicación. Los dispositivos con nivel de API> = 7 recibirán una actualización, mientras que los dispositivos con nivel de API < = 6 no serán notificados, no lo verán en Play (Market) y no podrán reinstalarse si se desinstalan. Eso sería 'no' a las preguntas 2 y 3.

Pero ahora es posible implementar varios archivos APK: http://developer.android.com/guide/market/publishing/multiple-apks.html http://developer.android.com/training/multiple-apks/

Específico para su problema, puede ofrecer varios APK basados ​​en el nivel de API: http://developer.android.com/training/multiple-apks/api.html

Esto le permite mantener dos versiones de la misma aplicación, separadas por nivel de API. Entonces, la respuesta a su pregunta 1 es, implementar múltiples APK por los artículos citados.

Al publicar una aplicación completamente nueva, su respuesta a la pregunta 2 es 'sí'. Al implementar múltiples APK, la respuesta a la pregunta 2 también es 'sí', y la historia del linaje/actualización de la aplicación es mucho más simple desde la perspectiva del usuario (un poco más difícil para usted técnicamente, más fácil en el departamento de servicio al cliente). Tenga en cuenta también que maxSdkVersion está en desuso, por lo que esto arroja un poco de una llave en su propuesta para limitar el antiguo APK cuando se emite el nuevo APK.

De la misma manera que con la pregunta 3. Ya sea publicando una nueva aplicación o implementando múltiples APK, puede seguir ofreciendo una APK para los niveles de API heredados que los usuarios pueden encontrar e instalar.

Varios APK ofrece una historia de usuario más simple. La publicación de una nueva aplicación hace que sea más fácil para ti diferenciar las aplicaciones, por ejemplo, si quieres decir: "¡Mira! ¡Ahora brillante!"