| Non - Phone : 핸드폰 번호를 갖고 있지 않는 태블릿 이나 Wifi 만을 제공 하는 디바이스는 TelephonyManager 를 통한 디바이스 번호를 획득 하지 못 할 수도 있다.
| Persistence : 한번 생성된 번호에 대한 지속 여부를 보장 할 수 가 없다. 디바이스가 공장 초기화 될 경우를 예로 들 수 있다. 뿐만 아니라, 현재 까지 몇몇 버그들이 report 되어 왔다. 안드로이드 디바이스는 제조사 마다 다양하게 커스터마이징 하기 때문에 000000000000000 같이 의미 없는 값이나 null 이 반환 되기도 한다.
가장 명확한 방법이며, 디바이스가 최초 Boot 될때 생성 되는 64-bit 값이다. ANDROID_ID는 디바이스의 고유한 번호를 획득 하기 위해 가장 좋은 선택이 될 수 있다.
Settings.Secure.ANDROID_ID
하지만 ANDROID_ID 또한 단점이 있는데, Proyo 2.2 이전 Version 에는 100% 디바이스 고유 번호를 획득 한다고는 보장 할 수 없으며, 몇몇 Vendor 에서 출하된 디바이스에 동일한 고유 번호가 획득 된다는 버그가 report 됐다는 것이다.
결론
지금 까지 안드로이드 플랫폼에서 디바이스를 구별하기 위한 고유한 번호를 획득 하는 방법을 알아 보았는데, 물리적으로 100% 보장 할 수 없다는 것이고, 이로 인해 결코 쉽지 않은 일이라는 것을 알 수 있었다. 가장 좋은 방법은 ANDROID_ID를 통해 획득 하는 방법이며, 다른 해결책을 혼용 해 사용하는 것도 좋을 방법 일 것이다. 여기에 위에 나열된 예상 되는 이슈 들과 같은 만일의 사태에 대한 대비책을 만들어 놓는 것도 좋을 것 이다.
[The contents of this post grew out of an internal discussion featuring many of the usual suspects who’ve been authors in this space. — Tim Bray]
In the Android group, from time to time we hear complaints from developers about problems they’re having coming up with reliable, stable, unique device identifiers. This worries us, because we think that tracking such identifiers isn’t a good idea, and that there are better ways to achieve developers’ goals.
Tracking Installations
It is very common, and perfectly reasonable, for a developer to want to track individual installations of their apps. It sounds plausible just to call TelephonyManager.getDeviceId() and use that value to identify the installation. There are problems with this: First, it doesn’t work reliably (see below). Second, when it does work, that value survives device wipes (“Factory resets”) and thus you could end up making a nasty mistake when one of your customers wipes their device and passes it on to another person.
To track installations, you could for example use a UUID as an identifier, and simply create a new one the first time an app runs after installation. Here is a sketch of a class named “Installation” with one static method Installation.id(Context context). You could imagine writing more installation-specific data into the INSTALLATION file.
public class Installation {
private static String sID = null;
private static final String INSTALLATION = "INSTALLATION";
public synchronized static String id(Context context) {
if (sID == null) {
File installation = new File(context.getFilesDir(), INSTALLATION);
try {
if (!installation.exists())
writeInstallationFile(installation);
sID = readInstallationFile(installation);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
return sID;
}
private static String readInstallationFile(File installation) throws IOException {
RandomAccessFile f = new RandomAccessFile(installation, "r");
byte[] bytes = new byte[(int) f.length()];
f.readFully(bytes);
f.close();
return new String(bytes);
}
private static void writeInstallationFile(File installation) throws IOException {
FileOutputStream out = new FileOutputStream(installation);
String id = UUID.randomUUID().toString();
out.write(id.getBytes());
out.close();
}
}
Identifying Devices
Suppose you feel that for the needs of your application, you need an actual hardware device identifier. This turns out to be a tricky problem.
In the past, when every Android device was a phone, things were simpler: TelephonyManager.getDeviceId() is required to return (depending on the network technology) the IMEI, MEID, or ESN of the phone, which is unique to that piece of hardware.
However, there are problems with this approach:
Non-phones: Wifi-only devices or music players that don’t have telephony hardware just don’t have this kind of unique identifier.
Persistence: On devices which do have this, it persists across device data wipes and factory resets. It’s not clear at all if, in this situation, your app should regard this as the same device.
Privilege:It requires READ_PHONE_STATE permission, which is irritating if you don’t otherwise use or need telephony.
Bugs: We have seen a few instances of production phones for which the implementation is buggy and returns garbage, for example zeros or asterisks.
Mac Address
It may be possible to retrieve a Mac address from a device’s WiFi or Bluetooth hardware. We do not recommend using this as a unique identifier. To start with, not all devices have WiFi. Also, if the WiFi is not turned on, the hardware may not report the Mac address.
Serial Number
Since Android 2.3 (“Gingerbread”) this is available via android.os.Build.SERIAL. Devices without telephony are required to report a unique device ID here; some phones may do so also.
ANDROID_ID
More specifically, Settings.Secure.ANDROID_ID. This is a 64-bit quantity that is generated and stored when the device first boots. It is reset when the device is wiped.
ANDROID_ID seems a good choice for a unique device identifier. There are downsides: First, it is not 100% reliable on releases of Android prior to 2.2 (“Froyo”). Also, there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID.
Conclusion
For the vast majority of applications, the requirement is to identify a particular installation, not a physical device. Fortunately, doing so is straightforward.
There are many good reasons for avoiding the attempt to identify a particular device. For those who want to try, the best approach is probably the use of ANDROID_ID on anything reasonably modern, with some fallback heuristics for legacy devices.
How can I get UDID of Android device via adobe air? I want to get UDID of my device with Android OS installed on it via Adobe AIR. How can I do it? Thanx!
Through the Adobe Flex platform, yes. You can generate and store your own random value, though, which accomplishes just about the same thing in most cases. – RobSep 6 '11 at 13:42
Join the FreshPlanet team - GAME DEVELOPMENT in NYC
We are expanding our mobile engineering teams.
FreshPlanet is a NYC based mobile game development firm and we are looking for senior engineers to lead the development initiatives for one or more of our games/apps. We work in small teams (6-9) who have total product control. These teams consist of mobile engineers, UI/UX designers and product experts.
Actually, not so perfect. Last time I tried this method, it reported the phone number that my phone originally had, before my old mobile number was ported over to it. It probably still does, as the Settings app still shows that defunct number. Also, there are reports that some SIMs cause this method to return null. That being said, I'm not aware of a better answer. – CommonsWareMar 19 '10 at 20:37
4
Mark is right. If the intent to use something that uniquely identifies phone i'd use getDeviceId() which will return IMEA for GSM. – Alex VolovoyMar 19 '10 at 20:40
There is no guaranteed solution to this problem because the phone number is not physically stored on all SIM-cards, or broadcasted from the network to the phone. This is especially true in some countries which requires physical address verification, with number assignment only happening afterwards. Phone number assignment happens on the network - and can be changed without changing the SIM card or device (e.g. this is how porting is supported). I know it is pain, but most likely the best solution is just to ask the user to enter his/her phone number once and store it.
In order to verify the taken number, you can send an sms (containing a code) to the number and control the response by putting a listener on "android.provider.Telephony.SMS_RECEIVED". that way you can make sure that the number is correct and working – Hossein ShahdoostJun 29 '13 at 12:02
Creative solution, but you might want to let the user know that you are doing it just in case they are being charged for that. – Norman HDec 18 '13 at 20:17
Update: This answer is no longer available as Whatsapp had stopped exposing the phone number as account name, kindly disregard this answer. ================================================================================= There is actually an alternative solution you might want to consider, if you can't get it through telephony service. As of today, you can rely on another big application Whatsapp, using AccountManager. Millions of devices have this application installed and if you can't get the phone number via TelephonyManager, you may give this a shot. Permission: <uses-permission android:name="android.permission.GET_ACCOUNTS" /> Code: AccountManager am = AccountManager.get(this); Account[] accounts = am.getAccounts(); for (Account ac : accounts) { String acname = ac.name; String actype = ac.type; // Take your timeto look at all available accounts System.out.println("Accounts : " + acname + ", " + actype); } Check actype for whatsapp account if(actype.equals("com.whatsapp")){ String phoneNumber = ac.name; } Of course you may not get it if user did not install Whatsapp, but its worth to try anyway. And remember you should always ask user for confirmation.
I just saw this today when I was messing around with accounts. It's pretty bad that the number is exposed like that. Of course, you need the GET_ACCOUNTS permission and at that point the user probably doesn't care what permissions the app has. – jargetzFeb 28 at 0:09
4
This solution is out of date, Whatsapp doesn't save the phone number on the acount name anymore, do you know where whatsapp saving the phone number after the new update? – CoheladMar 17 at 11:47
@Cohelad thanks for updating me, i'll have a check later and cross this answer out after confirmation, meanwhile i've no idea where do they save the number – Chor WaiChunMar 18 at 1:27
I don't understand why people vote up because this solution isn't helpful because getLine1Number() can send NULL if your number is not stored so substring(2) will throws an exception!!!! – Rafael Ruiz TabaresApr 29 at 16:03
Just want to add a bit here to above explanations in the above answers. Which will save time for others as well. In my case this method didn't returned any mobile number, an empty string was returned. It was due to the case that I had ported my number on the new sim. So if I go into the Settings>About Phone>Status>My Phone Number it shows me "Unknown".
Although it's possible to have multiple voicemail accounts, when calling from your own number, carriers route you to voicemail. So, TelephonyManager.getVoiceMailNumber() or TelephonyManager.getCompleteVoiceMailNumber(), depending on the flavor you need. Hope this helps.
there is no "getCompleteVoiceMailNumber" function , plus the getVoiceMailNumber() returns a number that is different from the real number of the phone. – android developerJan 8 '13 at 21:40
As posted in my earlier answer Use below code : TelephonyManager tMgr = (TelephonyManager)mAppContext.getSystemService(Context.TELEPHONY_SERVICE); String mPhoneNumber = tMgr.getLine1Number(); In AndroidManifest.xml, give the following permission: <uses-permission android:name="android.permission.READ_PHONE_STATE"/> But remember, this code does not always work, since Cell phone number is dependent on the SIM Card and the Network operator / Cell phone carrier. Also, try checking in Phone--> Settings --> About --> Phone Identity, If you are able to view the Number there, the probability of getting the phone number from above code is higher. If you are not able to view the phone number in the settings, then you won't be able to get via this code! Suggested Workaround:
Get the user's phone number as manual input from the user.
Send a code to the user's mobile number via SMS.
Ask user to enter the code to confirm the phone number.
Save the number in sharedpreference.
Do the above 4 steps as one time activity during the app's first launch. Later on, whenever phone number is required, use the value available in shared preference.
TelephonyManager is not the right Solution,Because in some cases the number is not stored in the SIM, Due to my suggestion,You should use Shared Preference to store user's Phone number first time the application is open, and after that the number will used whenever you need in application.
yes so for this purpose I used a text Message, When User enter a number, so from SmsManager the app message itself, and through this we can use smsReciever to Get the original number – naveed ahmadMar 12 at 16:23
1
I have one more question.. with this method there will be a SMS charge given by user( If it is not a toll free number).. Is there any other method which which I can get phone no of the user? – Zohra KhanMar 13 at 7:08
Yes off course there will be some charge on that SMS if the number is not a toll free number. – naveed ahmadMay 19 at 6:31
Nope I think there is no such method without TelephonyManager until now. and I point out the problem of TelephoneManager in my answer. – naveed ahmadMay 19 at 6:33
On the Android platform, you can use the android element of the application descriptor to add information to the Android application manifest, which is an application properties file used by the Android operating system. ADT automatically generates the Android Manifest.xml file when you create the APK package. AIR sets a few properties to the values required for certain features to work. Any other properties set in the android section of the AIR application descriptor are added to the corresponding section of the Manifest.xml file.
Note: For most AIR applications, you must set the Android permissions needed by your application within the android element, but you generally will not need to set any other properties.
You can only set attributes that take string, integer, or boolean values. Setting references to resources in the application package is not supported.
Note: The runtime requires a minimum SDK version greater than 9. You should ensure that the Manifest includes <uses-sdk android:minSdkVersion="9"></uses-sdk>.
Reserved Android manifest settings
AIR sets several manifest entries in the generated Android manifest document to ensure that application and runtime features work correctly. You cannot define the following settings:
manifest element
You cannot set the following attributes of the manifest element:
package
android:versionCode
android:versionName
xmlns:android
activity element
You cannot set the following attributes for the main activity element:
android:label
android:icon
application element
You cannot set the following attributes of the application element:
android:theme
android:name
android:label
android:windowSoftInputMode
android:configChanges
android:screenOrientation
android:launchMode
Android permissions
The Android security model requires that each app request permission in order to use features that have security or privacy implications. These permissions must be specified when the app is packaged, and cannot be changed at runtime. The Android operating system informs the user which permissions an app is requesting when the user installs it. If a permission required for a feature is not requested, the Android operating system might throw an exception when your application access the feature, but an exception is not guaranteed. Exceptions are transmitted by the runtime to your application. In the case of a silent failure, a permission failure message is added to the Android system log. In AIR, you specify the Android permissions inside the android element of the application descriptor. The following format is used for adding permissions (where PERMISSION_NAME is the name of an Android permission): <android><manifestAdditions> <![CDATA[ <manifest> <uses-permission android:name="android.permission.PERMISSION_NAME" /> </manifest> ]]> </manifestAdditions></android> The uses-permissions statements inside the manifest element are added directly to the Android manifest document. The following permissions are required to use various AIR features:
ACCESS_COARSE_LOCATION
Allows the application to access WIFI and cellular network location data through the Geolocation class.
ACCESS_FINE_LOCATION
Allows the application to access GPS data through the Geolocation class.
ACCESS_NETWORK_STATE and ACCESS_WIFI_STATE
Allows the application to access network information the NetworkInfo class.
CAMERA
Allows the application to access the camera.
Note: When you ask for permission to use the camera feature, Android assumes that your application also requires the camera. If the camera is an optional feature of your application, then you should add a uses-feature element to the manifest for the camera, setting the required attribute to false. See Android compatibility filtering.
INTERNET
Allows the application to make network requests. Also allows remote debugging.
READ_PHONE_STATE
Allows the AIR runtime to mute audio during phone calls. You should set this permission if your app plays audio while in the background.
RECORD_AUDIO
Allows the application to access the microphone.
WAKE_LOCK and DISABLE_KEYGUARD
Allows the application to prevent the device from going to sleep using the SystemIdleMode class settings.
WRITE_EXTERNAL_STORAGE
Allows the application to write to the external memory card on the device.
For example, to set the permissions for an app that impressively requires every permission, you could add the following to the application descriptor: <android> <manifestAdditions> <![CDATA[ <manifest> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /> <uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.DISABLE_KEYGUARD" /> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <uses-permission android:name="android.permission.RECORD_AUDIO" /> <uses-permission android:name="android.permission.WAKE_LOCK" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> </manifest> ]]> </manifestAdditions> </android>
Android custom URI schemes
You can use a custom URI scheme to launch an AIR application from a web page or a native Android application. Custom URI support relies on intent filters specified in the Android manifest, so this technique cannot be used on other platforms. To use a custom URI, add an intent-filter to the application descriptor within the <android> block. Both intent-filter elements in the following example must be specified. Edit the <data android:scheme="my-customuri"/> statement to reflect the URI string for your custom scheme. <android><manifestAdditions><![CDATA[ <manifest><application><activity><intent-filter><action android:name="android.intent.action.MAIN"/><category android:name="android.intent.category.LAUNCHER"/></intent-filter><intent-filter><action android:name="android.intent.action.VIEW"/><category android:name="android.intent.category.BROWSABLE"/><category android:name="android.intent.category.DEFAULT"/><data android:scheme="my-customuri"/></intent-filter></activity></application></manifest> ]]> </manifestAdditions></android> An intent filter informs the Android operating system that your application is available to perform a given action. In the case of a custom URI, this means that the user has clicked a link using that URI scheme (and the browser does not know how to handle it). When your application is invoked through a custom URI, the NativeApplication object dispatches an invoke event. The URL of the link, including query parameters, is placed in the arguments array of the InvokeEvent object. You can use any number of intent-filters.
Note: Links in a StageWebView instance cannot open URLs that use a custom URI scheme.
Android compatibility filtering
The Android operating system uses a number of elements in the application manifest file to determine whether your application is compatible with a given device. Adding this information to the manifest is optional. If you do not include these elements, your application can be installed on any Android device. However, it may not operate properly on any Android device. For example, a camera app will not be very useful on a phone that does not have a camera. The Android manifest tags that you can use for filtering include:
supports-screens
uses-configuration
uses-feature
uses-sdk (in AIR 3+)
Camera applications
If you request the camera permission for your application, Android assumes that the app requires all available camera features, including auto-focus and flash. If your app does not require all camera features, or if the camera is an optional feature, you should set the various uses-feature elements for the camera to indicate that these are optional. Otherwise, users with devices that are missing one feature or that do not have a camera at all, will not be able to find your app on the Android Market. The following example illustrates how to request permission for the camera and make all camera features optional: <android><manifestAdditions> <![CDATA[ <manifest> <uses-permission android:name="android.permission.CAMERA" /> <uses-feature android:name="android.hardware.camera" android:required="false"/> <uses-feature android:name="android.hardware.camera.autofocus" android:required="false"/> <uses-feature android:name="android.hardware.camera.flash" android:required="false"/> </manifest> ]]> </manifestAdditions></android>
Audio recording applications
If you request the permission to record audio, Android also assumes that the app requires a microphone. If audio recording is an optional feature of your app, you can add a uses-feature tag to specify that the microphone is not required. Otherwise, users with devices that do not have a microphone, will not be able to find your app on the Android Market. The following example illustrates how to request permission to use the microphone while still making the microphone hardware optional: <android><manifestAdditions> <![CDATA[ <manifest> <uses-permission android:name="android.permission.RECORD_AUDIO" /> <uses-feature android:name="android.hardware.microphone" android:required="false"/> </manifest> ]]> </manifestAdditions></android>
Android 3 menu button
In Android 3, which runs on tablet devices, applications are expected to provide their own button for opening an options menu. The Android SDK now provides an ActionBar component that displays a menu button. The menu button displayed by the OS at the bottom of the tablet screen (next to the Back, Home, and Recent Apps buttons) is no longer shown for applications that target Android SDK level 11+.
Install location
You can permit your application to be installed or moved to the external memory card by setting the installLocation attribute of the Android manifest element to either auto or preferExternal: <android><manifestAdditions> <![CDATA[ <manifest android:installLocation="preferExternal"/> ]]> </manifestAdditions></android> The Android operating system doesn’t guarantee that your app will be installed to the external memory. A user can also move the app between internal and external memory using the system settings app. Even when installed to external memory, application cache and user data, such as the contents of the app-storage directory, shared objects, and temporary files, are still stored in the internal memory. To avoid using too much internal memory, be selective about the data you save to the application storage directory. Large amounts of data should be saved to the SDCard using the File.userDirectory or File.documentsDirectory locations (which both map to the root of the SD card on Android).
Enabling Flash Player and other plug-ins in a StageWebView object
In Android 3.0+, an application must enable hardware acceleration in the Android application element in order for plug-in content to be displayed in a StageWebView object. To enable plug-in rendering, set the android:hardwareAccelerated attribute of the application element to true: <android><manifestAdditions> <![CDATA[ <manifest> <application android:hardwareAccelerated="true"/> </manifest> ]]> </manifestAdditions></android> AIR validates the elements and attributes included in the Android portion of the application descriptor. By default, AIR validates against the Android 2.3 SDK. Since the android:hardwareAccelerated attribute was added in Android 3.0, you must set the AIR ADT utility to validate against the Android 3.0 SDK (or later). First, download the Android 3 SDK: Android Developers: Installing the SDK . When packaging, set the -platformsdk option to the path containing the appropriate Android SDK (set the path to the directory containing the Android tools folder). For example: adt-package-targetapk-storetypepkcs12-keystorecert.p12-storepassfoomyApp.apkmyApp-app.xml-platformsdkc:\androidSDKmyApp.swfother.files You can also set the AIR_ANDROID_SDK_HOME environment variable to the path containing the Android SDK. Since Flash Builder and Flash Professional do not allow you to add extra parameters when packaging, setting this environment variable allows you to use Android SDK settings that were not available when the AIR SDK you are using was released. See ADT environment variables.
Color depth
In AIR 3 and later, the runtime sets the display to render 32-bit colors. In earlier versions of AIR, the runtime uses 16-bit color. You can instruct the runtime to use 16-bit color using the <colorDepth> element of the application descriptor: <android><colorDepth>16bit</colorDepth><manifestAdditions>...</manifestAdditions></android> Using the 16-bit color depth can increase rendering performance, but at the expense of color fidelity.
I am starting down the path of creating a mobile application and I have a need for a deviceid (something unique to the particular mobile device.) so that I can register the application for use with Multi-Factored Authentication. Is there an API somewhere in the Flex Framework or the upcoming mobile release where I can access a unique id for the device the app is running on?
I was just going to open a thread about this myself for what ultimately is the most important thing of all MobileApplications advertisement banners.
Your question only addresses one of these requirements, and there is a load of concern around this issue. I suppose I'm kind of documenting some of my research around these issues so bear with me and I'm sure it will be useful in varying ways to varied people and their needs.
The UDID is the Unique Device ID and is a truly globally unique value. It's ideal but a privacy concern.
If like myself you’re tracking banners or a potentially limited user base and a random (actually impossible) duplicate isn't really critical you can generate one randomly.
I actually wanted to get the phone-number as a global UUID but I don't think that’s ever going to be possible or acceptable (security policies).
It's critical to access this, but I suppose asking for an email is an alternative that transcends the device and is more to the user and grants permission which will eventually be an issue.
In ActionScript all objects can get Unique IDs and you can use this utility Class method to do basically the same thing...
And store them in the Application's PersistanceManager or preferences ultimately.
Also you'll want the Locale which is a lowercase Language "Underscore" uppercase Region or country code (2 letters I believe).
Sure you can ultimately Localize your app with string loading but knowing the Language and Country of the user is again potentially best a preference but this typically is not something we want to deal with (especially for the purpose of monetizing MobileApplications).
var loc:LocaleID = new LocaleID("es"); trace(loc.getLanguage()); // es trace(loc.getRegion()); // ES
Anyway next is the position (as in Map location) Longitude & Latitude, (for ads needs a UTC timestamp as long as well ~ ya javay to json issues) You could at a given moment consider this as unique as well as us it to get the Region but as to how I'm not certain either.
I'm not certain about getting the country at the moment of banner display from this stuff yet either. Still one can pass that and it probably overrides the Locale fields transmitted to AdMob for instance.
stuff would let you get language for whatever language your apps capible of. Of course the AreaCode of the phone number would also help with region and language somewhat I suppose, but not ideal either.
Basically your right MobileApplications and AIR 10.3+ and need a class for accessing all the device information! Where is it? Or please Adobe create it. [wishlist] MobileDeviceInfo might be a good name for that it would contain. Ideally... The Device Phone Number, maybe a user’s email, the UDID, the Locale (Language and Region), etc. We do have various ways to peck at Language, Region, randomly generate unique id's and store them per app/user.
Oh here's another final thought for you there is the option of using Facebook APIs to get an email or unique ID as well. I'm guessing it's a complicated set of combined techniques that will ideally do it's best to create what's needed from what info is available for all the different deployable platforms one AS3 SWF can be deployed on.
Also as an afterthought you might setup a server to acquire the random IDs and therefore retain uniqueness that way. I don't thing the banner services are smart enough to provide that idea yet. I'm questing there's something like that out there already.
I think I've said enough for now. Let me think about it some from my perspective do some more research and maybe I'll hit back here later and try to provide an ordered list of techniques I've resorted to.
It's just build properties for Android, no phone UDID in that file but it could be located somewhere similarly...
I recall there was something I believe (can't find it now) to do with possibly RTMP and getting a free AppID to find and connect devices, this would probably have a Unique ID somewhere. Maybe silly to use it for just that though. It was something where the second generation version allowed Peer replaying for video conferencing etc.
Thank you for trying to answer my question, but I dont' have a question about how to create a uniqueid as in a GUID. My question is in the first part of your answer, the unique id of the device.
This is important to me because for me to use an encryption scheme for Multi Factored authentication, I need to register the device and sync it up with my authentication system so that the app can generate a random number based on that ID and the date/time stamp as inputs.
I could just generate my own key, but it can't be persisted across a flash of the OS on the mobile device. Only the ID of the device will persist, so I am looking for a Flash method I can call to obtain the deviceid.
Did you ever find an answer to this? AS4more's answer is certainly very detailed, but talks mostly about getting the phone number. I'm guessing from the lack of documentation and forum replies that getting the UDID is not possible, but can you confirm either way? Thanks!
Thanks everyone for the replies. Sadly, lack of a persistent (and consistent) per-device identifier is a bit of a dealbreaker for me, so I guess I'll just watch and wait for a helpful update from Adobe. curtis33321, please do post again if you hear anything about timeframes.
My system is now very complicated with a rich set of features, and beyond this discussion. It's basically the same as hardwareAddress involves a little external remote_ip.php optionally too etc. and I feel no need for Neustar, or more.
I will say that in the end it's in the laws to ask them to "opt in" (and have a way out), so you might as well ask for an email or phone number or whatever if that's what you want, but it better be worth their while or forget it.
Ditto. No device id is a MAJOR drawback to Flex for me. I really want to be able to write once and deploy to all platforms with Flex. But, when I can't positively ID the device with Flex, it makes it a less appealing choice than it could be. Flex is great, in general. If this issue could be fixed, it would really help.
Adobe has created a NativeExtension for this for iOS - though I'm not quite sure why Adobe didn't build this as part of the built-in NetworkInterface class that can be used for the Desktop and AIR for TV?
Relying on a device id is bad practice. They are easily spoofable and not consistent across platforms. IMHO, It is better (more secure and more reliable) to issue revocable certificates that are not hardware dependant.
android
