Run code only once after a fresh installation,Shared Preference is not a solution please see below description

Question

I want to run a specific code only once in my android application.Shared preferences solution is not the solution as when you go to application manager and perform Clear Data then shared preferences gets deleted so application treats it a new fresh installation. I even tried Application class that too failed,it works same as shared preferences. Any help except Shared preferences and Application Class will be appreciated.

Thanks.

Answer 1

The answer hinges on what "only once" means.

Once per application install

Set a SharedPreference.

If the user clears data, or uninstalls then reinstalls, the code will be run again.

Once per device

Save a empty file (a flag file) in a well-known location on external storage.

You can either do that:

• in the application's own storage, which will be cleared at uninstall but not when the user hits Clear Data.
• in shared external storage.

This second approach is promising: it is resistant to Clear Data and reinstalls.

However, using external storage where the storage is removable, or unmountable is tricky, and I'm not sure what your fallback would be if the storage isn't available. (clue: fail fast).

You also may not trust your users not to (accidentally or deliberately) delete the carefully placed files.

Once per user

I think this is out of scope for this question. But you should start by looking at AccountManager docs, and go from there.

Once per device, seriously this time

Ok, so:

• we don't want to fail fast if we can't read external storage.
• we don't want to do belt and braces with the above, because bad actors delete the flag files on external storage, and Clear Data.
• we must only do once per device ever, even if the device is factory reset and external storage is wiped?

We'll have to check that with an external source which can store the state for this device; let's call that a "server".

We need an identifier to uniquely identify ourselves to the server.

Ordinarily, you would generate a UUID, and store it somewhere. But we can't trust any of our storage options.

So we need to generate an identifier from our static external environment. iPhone's now deprecated UDID was exactly this, generated from various hardware identifiers.

Copying this link would be a great start, but depending on your security clearance you may want to make your own. There may be privacy implications if everyone in the world used your app or the same algorithm as your app (this is why Apple deprecated UDID, and why each app should use its own UUID).

Either way, this is an extremely large amount of engineering effort (including the server) for (at best) an edge case, so I'd avoid it.

Worse, it ties your app to having an internet connection, which depending on your context, may be a bad thing.

Furthermore, a rooted device will have access to change any or all of these identifiers. It gets a bit philosophical after that.

Once per application lifetime

Do it manually. Seriously, do it by hand, either before you deploy, or sometime after.

If you need to pick a winning device, then you need a server and some way of identifying the device, as above. Do it manually, then pick then tell the winner. But that's also out of scope for this Android question.

Answer 2

If you can't rely on data being present on the phone itself (since the user can delete it), you need to somehow store that you have performed the initialization online. Define a service online and track on which devices and for which users the initialization has been run.

You can uniquely identify a device this way: Is there a unique Android device ID?

Out of curiosity, what is the scenario?