Italian Licensing library esperienza

maxware

Well-Known Member
Licensed User
Longtime User
sono in ferie e stanotte non ho dormito un ca.... pensando a sta cosa
e cosi mi e' venuta in mente che si potrebbe beccare almeno i più " impediti "
partendo dal presupposto che chi scarica app craccate di solito scarica il file apk ...perche' non pensare ad un semplice " cerca file apk " e se lo trovo dove penso che " l'impedito " l'abbia scaricato es. cartella dowload , o nella memoria esterna o direttamente nella cartella del programma o che altro ...gli faccio lo scherzetto
 

udg

Expert
Licensed User
Longtime User
In pratica dici che la differenza tra un acquisto regolare ed uno pirata è che nel regolare non rimane traccia dell'apk mentre l'altro (se non lo cancella dopo l'installazione) deve averlo per forza?
Non è malvagia...
 

maxware

Well-Known Member
Licensed User
Longtime User
ottimo
ma non solo....di solito chi cracca installa una app che permette di scaricare appa craccate...esempio aptoi devi installarti l'app
nella tua app cerchi se esiste l'app instalalta di apto...se esiste sai gia' che l'utente e' a conoscenza dello store paralello ed e' gia un buon indizio
 

udg

Expert
Licensed User
Longtime User
Vedi se ti piace quest'altra idea.

1. collezioni le mail o i dati di tutti gli utilizzatori attuali dell'app (onesti e pirati, non puoi distinguere)
2. pubblichi un finto aggiornamento (cambi solo il numero di versione)
2.1 ricevi e collezioni i dati da chi ha aggiornato in un definito lasso di tempo (e questi devono essere regolari perchè anche i pirati hanno bisogno di tempo)
3. confronti le due liste e sai con buona approsimazione chi sono gli onesti (il numero dovrebbe avvicinarsi molto a quello degli acquirenti)
3.1 l'altra lista contiene pirati e gente onesta che non ha ancora aggiornato l'app

Ripetendo la cosa 2-3 volte dovresti poter affinare sempre meglio le liste dei buoni e dei cattivi (come sulla lavagna a scuola..)
 

LucaMs

Expert
Licensed User
Longtime User
Gli ho ridato un'occhiata adesso.

In effetti non è poi tanto semplice, ma considera che io sto per andare a domire adesso, dopo tutta la notte in bianco!

A meno che non voglia studiare UDG, poi proverò a capire meglio (il fatto è che per il momento non mi attira molto, dato che non ho app pronte :()
 

udg

Expert
Licensed User
Longtime User
Se si tratta di dare una mano (ed imparare cose nuove), una lettura non mi farà certo male :)

Buon riposo!
 

udg

Expert
Licensed User
Longtime User
Ho dato una rapida lettura sia al tutorial di Erel sia alla documentazione su Android Developer.
Il sistema appare ovviamente complesso, ma credo che restringendo le cose solo a ciò che occore veramente ad una specifica app molti aspetti possono essere "trascurati".
La prima decisione da prendere è se vendere un Prodotto (nei giochi sono monete, trucchi e strumenti vari) oppure un Abbonamento (mensile, annuale o di periodo definito).
I primi possono essere "consumati", ovvero l'acquirente li utilizza nell'app (ad esempio, spende le monete) e quindi si possono riacquistare.
I secondi consentono di applicare un canone all'utilizzo temporale di un modulo dell'app (o anche dell'intera app); ad esempio un'app che fornisca notizie meteo e sportive potrebbe avere la parte meteo gratuita e quela sportiva ad abbonamento mensile. Ogni mese ci pensa BigG a riscuotere (e nel caso la transazione fallisca, l'app ne sarebbe informata semplicemente perchè il modulo non rinnovato non verrebbe elencato tra quelli "posseduti" dallo specifico utente; ciò dalla versione n3 di in-app billing).

Tutti gli elementi acquistabili vanno definiti nel pannello dello sviluppatore con codici identificativi e prezzi.

In pratica è come se l'app interrogasse la sezione privata dell'utente sullo Store per sapere quali moduli e funzionalità ha al momento attivi e poi si regolasse di conseguenza.
Ciò che mi lascia leggermente perplesso è che, secondo il tutorial, una variabile Process_Global dovrebbe contenere la Key dell'app definita nel pannello sviluppatore (benché eventualmente offuscata). Craccando l'app salterebbe fuori questa key, quindi mi domando se sia possibile sostituire (in un apk pirata) la Key originale con quella del truffatore e ricevere così compensi per il lavoro altrui.. Se così fosse, avremmo il famoso gigante con i piedi d'argilla!

udg
 

LucaMs

Expert
Licensed User
Longtime User
Ho dato una rapida lettura sia al tutorial di Erel sia alla documentazione su Android Developer.
Il sistema appare ovviamente complesso, ma credo che restringendo le cose solo a ciò che occore veramente ad una specifica app molti aspetti possono essere "trascurati".
La prima decisione da prendere è se vendere un Prodotto (nei giochi sono monete, trucchi e strumenti vari) oppure un Abbonamento (mensile, annuale o di periodo definito).
I primi possono essere "consumati", ovvero l'acquirente li utilizza nell'app (ad esempio, spende le monete) e quindi si possono riacquistare.
I secondi consentono di applicare un canone all'utilizzo temporale di un modulo dell'app (o anche dell'intera app); ad esempio un'app che fornisca notizie meteo e sportive potrebbe avere la parte meteo gratuita e quela sportiva ad abbonamento mensile. Ogni mese ci pensa BigG a riscuotere (e nel caso la transazione fallisca, l'app ne sarebbe informata semplicemente perchè il modulo non rinnovato non verrebbe elencato tra quelli "posseduti" dallo specifico utente; ciò dalla versione n3 di in-app billing).

Tutti gli elementi acquistabili vanno definiti nel pannello dello sviluppatore con codici identificativi e prezzi.

In pratica è come se l'app interrogasse la sezione privata dell'utente sullo Store per sapere quali moduli e funzionalità ha al momento attivi e poi si regolasse di conseguenza.
Ciò che mi lascia leggermente perplesso è che, secondo il tutorial, una variabile Process_Global dovrebbe contenere la Key dell'app definita nel pannello sviluppatore (benché eventualmente offuscata). Craccando l'app salterebbe fuori questa key, quindi mi domando se sia possibile sostituire (in un apk pirata) la Key originale con quella del truffatore e ricevere così compensi per il lavoro altrui.. Se così fosse, avremmo il famoso gigante con i piedi d'argilla!

udg


Si, il fatto della key l'avevo già letto altrove: non si dovrebbe mettere nel codice ed in chiaro. Però non dovrebbe essere un problema: alla fine i dindini finiscono all' "intestatario" di quella chiave.

Grassie per la spiegazione (lo dico a nome di altri perché, poco modestamente, l'avevo capito); per me il "problema" STAMATTINA era seguire i singoli passi da effettuare nel codice... adesso, invece... pure, appena sveglio e col mal di testa :mad::).

Ah proposito di "pure"... la conoscete, vero?
 
Top