Is this method of a Unique Id good?

Im adding a time bomb to my application... I wanted to know your thoughts if this is a robust idea:

Bare in mind ive done alot of research on a unique ID android can provide,but found if its a phone, telephony.getDeviceID is useful... for other devices like tablets, android_id is usefull... (formatting a device to reset the unique id to cheat is unlikely for my app)

So ive decided to join them together as a big string for a unique id, regardless if the telephony will return null for non gsm devices.

So what do you think of this,

• check,join and create the unique ID

• connect to an FTP and upload a txt file with "20" within it.

NOW, whenever the user reopens

• check,join and create the unique ID

• connect to the FTP and check if that file exists

• if it does, read, -1 the text within it, write it back to the ftp (so now the txt is 19)

Gradually... when 20 uses are over, and the text file has "0" in it, post a message linking to the mar开发者_运维百科key to buy the app, otherwise exit app before anything is accessible.

What are your thoughts?

Th biggest problem I see with that will be WiFi firewalls, etc., that may pass HTTP (port 80) but not FTP traffic, in some cases.

Assuming you mean "HTTP, port 80" (or HTTPS, etc) when you say "internet based app", I'd suggesting using the same access technique as the rest of your app... ie., use http with a POST or GET to a little PHP app on your server to take the ID, decrement it in a sql database, and return a 'yes' or 'no' response. Using HTTPS would also get around the snooping that Roland mentions. That way your authentication mechanism won't fail if the rest of the app could work, or will at least fail in the same way.

You are in the right path but need to improve a little bit the way your system test for each running time. First of all, forget about an FTP, that's for sure would be a big trouble passing thru firewalls or whatever structure user data travels.

Better if you do a small PHP script or even an HTML page with a challenge-reply scheme, at your server. You construct a challenge of say 128 bytes with phone ID and some encryption inside your code, and then you decode in your server and send an encrypted reply that your code must process to decide if its ok to continue. Its very easy to sniff packets and FTP traffic, but is not easy if you send a lot of nonsense data embedded together!

Research in Google "send binary data with HTML", I've found this page useful