I thought there would be some straight forward solution to this.
Requirements:
Uniquely identify device across app install/uninstall sessions.
Options:
Use some kind of Android's device-identifier-API each time when needed (read it every time from Android's API). According to Identififying-app-installations blog post this is not recommended and not reliable solution.
Generate UUID once (on first app start) and persist it somewhere somehow that it would be preserved across multiple app installs/uninstalls. This "somewhere somehow" part is the mystery. Solutions like storing onto the SD card or Cloud are not an option. iOS has keychain that can be used for this kind of stuff but I didn't find Android's equivalent of it.
What are my other options here? I prefer going the (2) route because of my server implementation (server is generating UUID for the first time if not present). But if it is not an option, I can fallback to (1) and modify the server.
Thanks.
To uniquely identify an application between application installs/reinstalls, you need to get it's hardware ID and use that as your credentials/key.
To fetch the hardwareID, you can use the following method:
public static String getHardwareId(Context context) {
return Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);
}
it's partially equivallent to a UUID with the following exception: The value may change if a factory reset is performed on the device.
The reason why i call it "partially equivallent" is this:
The HardwareID is a 64-bit number (as a hex string) that is randomly generated when the user first sets up the device and should remain constant for the lifetime of the user's device. The value may change if a factory reset is performed on the device.
Note: When a device has multiple users (available on certain devices running Android 4.2 or higher), each user appears as a completely separate device, so the ANDROID_ID value is unique to each user.
But this hits the #2 problem: where and how to store it; storing it in SharedPreferences is useless as that is wiped if the app is uninstalled. Same for /data/data/your.package.name/my_stored_keys folder as that one gets deleted from the phone during uninstallation as well.
You will need to save it server-side if you wish to persist between uninstalling and reinstalling the app.
Related
I'm making a server that sends messages using FCM to clients depending on what happens (temperature and/or humidity change, a door is opened, etc.).
But if the token can change, how can I keep track of the device to send messages to the correct one (w/o using a login system)?
I was thinking to link the token to the sim iccid in a database, is this correct?
Use device's advertising id. It won't change unless the user manually changes it. Please check the thread How to get Advertising ID in android
Update 05/18/2017:
Starting Android O, ANDROID_ID will now be different per app per user in the device.
Original Answer:
If you're looking for a long lasting (possibly permanent) ID that you can use, I guess you can make use of ANDROID_ID:
String ANDROID_ID
A 64-bit number (as a hex string) that is randomly generated when the user first sets up the device and should remain constant for the lifetime of the user's device. The value may change if a factory reset is performed on the device.
Note: When a device has multiple users (available on certain devices running Android 4.2 or higher), each user appears as a completely separate device, so the ANDROID_ID value is unique to each user.
Constant Value: "android_id"
However, there are still some factors that you should consider depending on your use-case. I recommend going through the Best Practices for Unique Identifiers documentation.
FCM wise, it is usually associated with a user, hence it is commonly paired with the user details.
In Android Open Source Project, a lot of core API declarations have an integer parameter userId in the end. I traced back and figured out the integer comes from a class called "UserHandle.java". There is a simple comments saying this class represents a user on the device. It still confuses me. Why do we need such a class? What's the difference between different values of the class, such as "USER_OWNER", "USER_CURRENT", "USER_CURRENT_OR_SELF"?
Thanks in advance!!!
Ever since Jelly Bean, Android platform has supported multiple users. This means that multiple users may be able to use one device, yet not be able to access other user's files or communicate with another user's app.
The first user on the device is user 0. The rest start their numbering from 10,11,... (In JB the numbering was 1,2...).
USER_OWNER is user 0.
He has some extra privileges over the other users (mostly access certain settings that others can't or uninstall an app for all users).
Multiple users on one device requires that only one user can be active in a specific point in time, this user is referred to as USER_CURRENT (since Kitkat().
In general one user's application can't send a broadcast message or an Intent to other user's apps.
Only apps with system permissions can do that (for example when the battery is running low, an intent will be sent to all).
Whenever you send an Intent from your app, the system service verifies whether this is a valid Intent i.e. if its supposed to reach all users then it's not.
This means that even if you were to use a certain api with the wrong userId (for example you force userId=0 even though this is user 10), then your call will receive a SecurityException.
To avoid such exceptions, there is also the option to send an Intent with USER_CURRENT_OR_SELF.
This means you're trying to send to the current user, but if he's not allowed to receive the Intent, let the same user who sent the Intent receive it.
I always wonder how Android's BackupManager will act when the same BackupManager enabled App is installed on multiple devices (e.g. Smartphone and Tablet) linked to the same Google Account. It seems that I am not the only one, but I couldn't find any specification about this.
What's your experience with this scenario? Are there any official resources that describe that case?
This mechanism doesn't have any user-facing documentation, nor a lot of documentation for app developers, since it's supposed to automatically do the right thing, but the code is available. All the information below comes from inspecting the source code and from the documented options of the bmgr tool. This answer is adapted to be more developer-oriented, from a user-friendly answer I originally wrote on the Android Stack Exchange.
Let's talk about sets, baby
Android's backup service has a concept called a set: the set of all data backed-up from one device on one transport. Each set is identified by a unique string, such as the IMEI on the device. When an app (or the list of installed apps) is backed up, its backup data go into the set associated with the device it's being backed up from. All the sets are still specific to the user's Google account. If you wipe your device and sell it to someone else, he won't be able to access that device's set unless he can log into your Google account.
Default behaviour
When an app is installed, or a device has its list of apps restored, the backup system first looks in that device's set for backup data for that package. If it doesn't find any (either because it's a completely new device with no backed-up data, or because that package has never been installed on that device), it'll expand the search to other sets. (If there's a choice, it'll use the last set that was used for a full-device restore.)
Thus, when you set up a new device, it'll restore the list of apps from an old device's backup, and restore each app from the old device's backup. If you had an app installed on one device and you install it on another device, the app will be restored with its data from the old device. In either case, the data are now backed up into the new device's set, which means that the backup data from the two devices are separate from now on.
After you factory-reset a device, it'll restore from that device's last backup if there is one, and failing that, from some other device's backup if there is one, but it will start to create its own set from then on.
bmgr: basic use
The bmgr tool is intended for debug and test, and gives you a little control over the backup/restore process. You can use this tool in an adb shell to trigger backups and restores of chosen packages, wipe packages' backed-up data, and even a whole-device restore.
Don't try to use it in an on-device shell except as root: you need the system-level android.permission.BACKUP to do anything interesting with it.
For testing, you can make a package update its backed-up data immediately:
bmgr backup com.shadowburst.showr
bmgr run
(or whatever the package name is). To restore one package from the backed-up data it would choose by default:
bmgr restore com.shadowburst.showr
This only works on already-installed packages: it won't install a package in order to restore the data. Both these commands are just for testing, since normally the device backs-up and restores data whenever it needs to.
More control
Now for the stuff that the backup system won't do on its on. To see what sets of backed-up data are available:
bmgr list sets
and you'll get some output like this:
3ff7800e963f25c5 : manta
3f0e5c90a412cca7 : manta
3dd65924a70e14c8 : TF101
3baa67e9ce029355 : m0
The 64-bit hex number on the left is called a token, and uniquely identifies the set. The thing on the right is a (relatively) friendly name for the device that owns the set. For example, manta is the code name for the Nexus 10; TF101 refers to the original Asus Transformer. You can restore a package's data from a set of your choice, by specifying its token:
bmgr restore 3ff7800e963f25c5 com.shadowburst.showr
You can add more package names to the end of the command to restore several packages at once, or you can specify no package name (just the token) to restore every package with data in that set (that is, it does a full-system restore).
Finally, you can wipe an package's data from the current set:
bmgr wipe com.shadowburst.showr
This will make its next backup operation start from scratch. This might be useful while debugging your backup code.
You can't make a device start writing into a different set, nor can you wipe a whole set in one go.
This is a theoretical situation:
I am writing an app to detect the presence of another on the phone
The classpath, name, Activity names etc. of the target app have been randomized, I can't just check if it's there (it is semantically the same but syntactically unique)
I have root access to the phone
The app is open source, and (apart from the package name and application name) I know everything about it.
The app generates no Log output.
I've been thinking of ways to detect whether this other app is present on the phone (assuming it is actually run from time to time), are the following methods feasible at all?
Look periodically for the presence of certain classes in memory
Search for known chunks of the compiled code in each installed apk
Detect the app running by inspecting the memory of the device at certain intervals and look for usage patterns matching the app
Are there any other ways of detecting another app under these circumstances?
Use PackageManager. It has a method returning info about all the apps, installed on the system: getInstalledPackages().
I'm writing an application that must not run on rooted devices. I want to store some secure data and which is possible only on non-rooted devices as nobody can access files in /data/data/package-name.
Does anyone know:
1) Is it possible to prevent the installation of an application on rooted devices? I read something about the "copy-protection mechanism" of Android Market. This feature seems to be outdated and replaced by the licensing feature. However, licensing is only possible for paid application and mine is free...
2) Is it possible to check programmatically whether a device is rooted or not? If it would be possible to do so I could simply stop the application if the device is rooted.
Any help regarding this topic is appreciated!
Execute
Runtime.getRuntime().exec("su");
and check the result code.
In other words, if you can exec su, then you have root access. it doesn't matter if the user allows or denies it, you have your answer.
I think your approach is a bit flawed. First of all, the user can first install your application and data, then "root" the device (even if rooting wipes the data, one can make the backup first). Next, the general rule is that whatever is in user's hands is not yours anymore. The hacker will find a way to get to your data sooner or later.
If you care about secure data, don't put it to device. As Android is net-centric device (yes, I know, that's subjective, but it was initially developed and positioned as such), accessing the data online is not uncommon.
What I would say is to run su and then check the output. If the user allows your app to have root, then use root to uninstall your own application (one way might be to place a script into init.d and then force a reboot).
If the user DOES NOT allow your app to run as root, then:
They DENIED your app permissions.
They are not rooted.
Now, denying permissions (and rooted) means that they have some sort of SUPERUSER management app, and that's where this next part comes in.
I would then proceed to use PackageManager to retrieve a list of all packages and then check them against the handful SuperUser management apps available, namely the ones by Koush, ChainsDD, and Chainfire
The relevant package names are:
com.noshufou.android.su
eu.chainfire.supersu
com.koushikdutta.superuser
Use those methods which will help you check for root
public static boolean findBinary(String binaryName) {
boolean found = false;
if (!found) {
String[] places = { "/sbin/", "/system/bin/", "/system/xbin/",
"/data/local/xbin/", "/data/local/bin/",
"/system/sd/xbin/", "/system/bin/failsafe/", "/data/local/" };
for (String where : places) {
if (new File(where + binaryName).exists()) {
found = true;
break;
}
}
}
return found;
}
private static boolean isRooted() {
return findBinary("su");
}
Now try to check whether the device is rooted.
if (isRooted() == true){
//Do something to prevent run this app on the device
}
else{
//Do nothing and run app normally
}
For example you can force stop the app if the device is rooted
If you are trying to protect data for the user, it's their business to worry about other apps.
If you are trying to protect data from the user, what business do you have putting it on their device?
To answer your question, they are in control of the machine so expect them to be able to trap any call to an API checking 'Is this rooted?' and lie to you. Instead, encrypt the data on the client with a key known to the client, but make it non-obvious where and how you are doing it. Generally make things annoying for whoever is looking.
Enjoy the ensuing game of whack-a-mole. Every time someone cracks into it, you'll make a better fix, they'll make a better crack, and all along the way you will be raising the barrier for cracking it.
Don't fight against freedom - why should you turn away customers with free devices anyway? - instead, if you want a particular outcome, make it so Bother To Get Data > Value Of Getting Data. Then it won't happen. If you truly must have fool-proof security, keep the data server-side.
I believe that one of the 'drawbacks' of the traditional copy protection was that it did not allow the application to be installed on rooted devices, but it also has its own share of problems and will be deprecated soon.
As for client-side checks, you simply cannot rely on a programmatic approach to detect if you're running on a rooted device or not -- anything that is in client-side code can and will be hacked and removed. You'd be surprised at how easy it is to modify even Proguard-obfuscated code. At best, you force the hacker to spend a few hours or days to edit the code and recompile. This is security through obscurity, and not a viable protection mechanism.
1) no. how would you deny installation? why would a rooted device deny installation of something the user wants to install on the fs? being the whole point of rooting that you can make the device do basically whatever.
2) no. not for your purposes. you can check if you can gain root for your application through the usual methods. so you can make a check for a positive but you cannot prove programmatically that it is not rooted, from within your app.
also, what you are asking if you can make perfect copy protection drm system - you might also be missing the point that the user can alter your application, removing your root check. if you have a checksum/crc check of some kind, the user can fake the result of that as well.