I have a application which have a refer system
I get user imei no. to as a id of the user
but I checked my application I bypass my application using some app cloner have a funtion to set random imei no.
so how to protect my application from this things
Don't use the IMEI. First off- you can't get the IMEI on modern versions of Android. The OS itself will lie to you unless you're a preinstalled carrier app, the device owner app, or require a permission that normal apps cannot be given.
Secondly- not all devices have IMEIs. A tablet without cellular connectivity won't, for example.
Thirdly, its a massive invasion of the user's privacy (and illegal to do in some locations). Here's google's guidance on what to do for unique ids for your app https://developer.android.com/training/articles/user-data-ids Specifically note that you are NOT supposed to use any permanent hardware id as a user id.
Related
Being an EMM organization, we have an application that provides a device owner and a user's work profile enrollment of their devices.
As an MDM application, we must manage the device information by accessing privileged identifiers. Since Android 11, we can access these identifiers in the Device Owner enrollments but not in the work profile enrollments. How do we qualify to read privileged device identifiers in the user's work profile enrollment?
I want to share the response that I received in the Android Discussion Forum:
Since work profiles set up on a personally owned device will no longer
be granted access to the device's hardware identifiers (IMEI, MEID,
serial number) in Android 12, there is currently no way for you
to have a special privilege to access these identifiers. We suggest
you leverage the enrollment-specific ID. The enrollment-specific
ID remains stable across factory resets when re-enrolled to the same
organization managed by the same device policy application. Here is
the link for best practices for working with Android
identifiers.
What is the least invasive way to uniquely identify a user or a user's device in Cordova. I've not yet been looking at iOS yet, but it looks like ANDROID_ID is definitely not unique, which rules out org.apache.cordova.device.Device's uuid property.
Specifically, this is for recovering remote user account data in case of a phone- or application-data reset and I am trying to figure out how to do this with the fewest app permissions and the smallest cognitive load on the user.
Currently, I think the only routes I have are:
Ask user for email
Use third-party authentication (OpenID, Facebook, Twitter, Weibo, etc.)
Ask user for a uname/password
If your problem is only about backups, I don't know about Cordova/iOS, but Android has a standard backup service meant for this, which should work on even non-Google firmwares (assuming the ROM-maker did integrate a backup service)
Concerning having a unique ID, I don't think there is any obvious answer, it depends on your more precise need:
According to the link you gave, the non-unique ANDROID_ID bug only applies to <= 2.2, is that relevant for your use-case ? (Edit: Though ANDROID_ID will change after phone-reset, so that doesn't match your need)
Asking user for email means taking care of spams
username/password means have proper security, not to leak infos
My personal preference is third-party authentificatino, but then you'll need your users to have a google account/facebook/etc, which you might not want
Also, one problem you might want to consider, is that Android devices are getting more and more multi-user capable. Do you want to a identify a device or a user ?
If the later, one user might have multiple devices for the same application.
If you want to identify an user then you have to use any of the routes you though and any of them will require permissions, so it's up to you which one to choose.
For identifying a device, the best choice is to use the IMEI for phones and the Build.SERIAL for devices that don't have IMEI (tablets, media players), you will have to create a plugin to get those values
http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID
This link says that :
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.
http://developer.android.com/about/versions/android-4.2.html#MultipleUsers
While this link says:
Beware that if your app requests one of the hardware device identifiers (such as the WiFi MAC address, the SERIAL number, or the ANDROID_ID number), they will provide the same value for each user because these identifiers are tied to the hardware and not the user.
Both are from android developer and have got me confused?
Is the ANDROID_ID actually unique or not for multiple users on a single device?
There is an issue opened here.
It appears to be an error in the doc, so ANDROID_ID should be different for multiple users on a single device.
Best thing is to test yourself, if you have a 4.2 tablet, but some others have tested it here for example, and it appears to work well.
I need to know how to get the phone UID when read by an NFC reader. The reader has to uniquely identify my phone so that it can be used to open a door.
Do you know if this is possible? I've been looking and have not found how.
In the event that it isn't possible, what do you recommend?
The current Android does not support tag emulation, so I must assume you will be using some kind of P2P protocol when talking to your door. If the phone sees the door as a passive unit, thats the same.
A key insight in your plan is that you should encrypt the communication to your door, and that the encryption key is really what matters. Any unique id you come up with can be faked, no matter where it comes from.
I'd put the encryption key somewhere online in a properly stored file. So then you are also covered once you loose your phone or it just breaks.
My approach would be to make a Google App Engine app which lets you sign in using your Android (email) account; i.e. an app which signs the user in using the built-in Android accounts. Put the encryption key there, possibly behind yet another password.
There are different device specific numbers which you may use.
IMEI = International Mobile Equipment Identifyer, a number phones have specific for their hardware
Mobile phone number, this is depending on your mobile subsciption
There is also the ANDROID_ID, which is a unique number for a Android device. However there appears to be a glitch in V2.2
See also these articles:
How to find serial number of Android device?
Android Tablet Serial Number (not IMEI/DEVICE_ID/SERIAL)
Device SERIAL NUMBER
I have been trying to find a way around validating a phone number (Android and iPhone) without using the SMS verification system. The reason is purely around cost. I would like a FREE solution.
Can I safely assume that Android OS will provide me with the user's phone number (no need for verification), making it a free solution?
How about iOS?
Thanks all for your help.
Android allows you to get the phone number. Your app will need the READ_PHONE_STATE permission from the user.
Then it's simple to get the phone number like so:
TelephonyManager tMgr =(TelephonyManager)mAppContext.getSystemService(Context.TELEPHONY_SERVICE);
mPhoneNumber = tMgr.getLine1Number();
ios does not allow you to get the user's phone number. They consider it a security risk.
one developer who tried this received a response from apple that said:
"For security reasons, iPhone OS restricts an application (including its preferences and data) to a unique location in the file system. This restriction is part of the security feature known as the application's "sandbox." The sandbox is a set of fine-grained controls limiting an application's access to files, preferences, network resources, hardware, and so on."
The device's phone number is not available within your application's container. You will need to revise your application to read only within your directory container and resubmit your binary to iTunes Connect in order for your application to be reconsidered for the App Store.
So, you will still probably need to use the SMS service. Good luck!