Previous iterations of Windows 10 have the HardwareToken API (aka ASHWID) to get a unique identifier for the device, but it had several drawbacks:
It was only available on Desktop and Mobile platforms, which required you to add an Extension SDK to your project (and wasn't available on HoloLens or other platforms)
On the PC, the value could "drift" as hardware changed (even just plugging a laptop into a docking station would change the ID), so you needed complex backend logic to correlate device IDs
The value was specific to a single app, and couldn't be shared across apps by the same publisher
Is there a new way in the Anniversary Update to get a more useful / stable ID that's consistent across all Windows 10 platforms? I want to use the ID in my apps to correlate telemetry from the same device for purposes of usage metrics and advertising. I will not use the value for identifying the user, creating anonymous accounts, encrypting data, or anything else like that. It will only be used for telemetry purposes.
I want to do something like:
var id = Windows.Something.GetDeviceId(); // hypothetical OS function
var telemetry = MyApp.GetUsageTelemetry(); // my own function
// Use (eg) HttpClient to send both id and telemetry to my
// cloud infrastructure for processing and correlation
SendDataToCloudForProcessing(id, telemetry)
Updated Nov 3rd 2017 (new Registry value, below)
The Windows 10 Anniversary Update introduced the new SystemIdentification type which does exactly what you want. It has several benefits over the old ASHWID:
It is available on all Windows 10 platforms
Note: The ASHWID is now also available on all platforms, but still has the other drawbacks listed above
It returns a stable value (even on PCs) that will not change due to hardware upgrades or re-installations of the OS
It returns a value that is the same for all apps by the same publisher, allowing correlation across your portfolio of apps
It can also return a value that is the same across all apps, for a specific user, if you have the userSystemInfo Restricted Capability
Note: This is most useful for Enterprise scenarios; you are unlikely to have an app approved for the Windows Store that uses this feature without a very good justification, since it represents a privacy concern
There is one minor drawback to the API: it won't work on some old PCs, since it requires either UEFI or a TPM. Most PCs built in the last 5+ years should have this hardware, and all other non-PC devices (phone, Xbox, HoloLens, etc.) have the correct hardware. If you find a PC that doesn't have the hardware, you will need to fall back to the ASHWID or some other mechanism.
Update Nov 3 2017
Starting with the Windows Fall Creator's Update (aka 1709 or RS3 or Universal API Contract 5) there is a new Registry identification source which provides a relatively stable ID in case the user doesn't have appropriate hardware. It will change if the user does a fresh re-install of the OS (not an upgrade, but a new install) or if the user changes the registry, but otherwise has the same benefits as Uefi or Tmp.
End update Nov 3 2017
Using the API is simple; there is no need for complex parsing or accounting for drift on the back-end:
using Windows.System.Profile;
IBuffer GetSystemId()
{
// This sample gets the publisher ID which is the same for all apps
// by this publisher on this device.
// Use GetSystemIdForUser if you have the userSystemId capability
// and need the same ID across all apps for this user (not
// really applicable for apps in the Windows Store)
var systemId = SystemIdentification.GetSystemIdForPublisher();
// Make sure this device can generate the IDs
if (systemId.Source != SystemIdentificationSource.None)
{
// The Id property has a buffer with the unique ID
return systemId.Id;
}
// This is a very old PC without the correct hardware. Use
// another mechanism to generate an ID (or perhaps just give
// up due to the small number of people that won't have the ID;
// depends on your business needs).
return GetIdFromAshwidOrSomethingElse();
}
As noted in the question, this ID should only be used for purposes of correlation in a back-end service (eg, for telemetry, advertising, usage metrics, etc.). It should never be used to create anonymous user accounts, to identify or track users, to encrypt user data, etc. This is because different users can share the same device, or the same user can roam across different devices, so the ID doesn't map 1:1 with a user or their data.
This API is available in the Universal API Contract v3, and can be found in the Windows Universal SDK version 10.0.14393.0 (remember that if you're doing multi-version apps and want to light-up usage of this API, you should not do runtime version check; instead you should just query the OS to see if the API is available).
Related
I have deployed an application to the Windows Store. Is there any way to find out how many of users have uninstalled the app?
The store does not get updated when an app is uninstalled, so you would instead need to consider some other way of measuring it with your analytics (for example, you might consider an app uninstalled if it is unused after thirty days for a given device id)
To achieve what Rowland Shaw proposed, you must manually implement some kind of telemetry in your app.
You can do it all by yourself by retrieving the Device ID via the appropriate API (a quick search on the web could help here) and later send that ID to your web service on a periodic basis.
Alternatively you can use third party frameworks, Application Insights, just to name one, but I don't know if it allows you to track a specific Device ID natively.
I don't know whether this question belongs to SO or UX (or Programmers.SE) but here it goes.
We have built a mobile app a couple of months back, which we intend to alter in some major ways (like authentication and security) in next release. We published it to AppStore/PlayStore and it has a download count between 5k-10k range.
Now the question is;
whether if we retire our current API rightaway and show current version users a popup which forces them to update the app (via stores)
or
create a new API under a different URL and maintain both APIs at the same time (in this case should we maintain it forever or should we set up an expiration date) ?
EDIT:
It'll be our first and possibly last update, since our app is a cordova based hybrid app, we intend to use silent cloud deployments without relying on app stores.
I would say - for a mobile application, forcing your users to upgrade straight away isn't a unreasonable expectation. The exception to that is if you have users on an older operating system (e.g. old iOS) that cannot upgrade. Then you might want to maintain a legacy API.
Can you give a legitimate reason why a reasonable user wouldn't be prepared to update your app?
I'm testing my Windows Phone 8 app for scenarios where my app goes to the background before it can fulfill a consumable purchase. So, on every app-launch I check if there are any unfulfilled in-app purchases, if there are, I fulfill them using the CurrentApp.ReportProductFulfillment method.
However, while testing I noticed this method works even if the device isn't connected to the Internet. So how and when does the app let the Marketplace know that the purchase has been successful? More importantly, should I only do this only if I have an Internet connection?
This is my code by the way :
var licenses = CurrentApp.LicenseInformation.ProductLicenses;
if (licenses["PRODUCT_ID"].IsConsumable && licenses["PRODUCT_ID"].IsActive) {
// Fulfill consumable purchases
// Let the Marketplace know
CurrentApp.ReportProductFulfillment("PRODUCT_ID");
}
Marketplace communications occur on a background task spawned by the OS on regular intervals. You can observe this traffic if you attach Fiddler to a machine running Windows Phone emulator
The following statements are merely suppositions on my part, so take it with a grain of salt. I would imagine the background Marketplace communication handles a number of tasks. The most common of these would be checking for application updates. However, this would also be an ideal time for the OS to communicate fulfillment of an order. In that vein, Marketplace services likely queue your report request and, if it cannot be communicated immediately, defers it for the background task to handle at a later time, allowing the method to run even when the phone does not have data access. Given the nature of modern cashless transactions, I don't see any reason the Marketplace would require immediate notification of fulfillment, as it has time to complete a transaction once initialize authorization is acquired.
CurrentApp.LicenseInformation.ProductLicenses is cached by the windows phone operating system.
Does WP8 have any OS hook or callback (sync mechanism) I can implement to get a notification when a contact changes?
For example I'm running an application as a background agent, and a user randomly changes a contact's details. I want to get notified in my background engine so that I can do various operations.
I could always implement a periodic check (say every minute I read all contacts and check to see if there are any modifications - assuming I'm remembering the last configuration somehow). But this solution is not efficient for a large number of contacts, especially when I want the application to run on the low end phones.
Windows Phone does not support any built in way for applications to be notified of contact changes.
As you've noted, the only way to do this would be to track the details and periodically look for differences. Yes, you'd have to do this with the app running (rather than a background agent) if you want to support WP7 devices with one 256MB of memory.
As an alternative and assuming that the user is syncing their contacts with their live.Windows account you could create an external service that periodically polls their live account (via http://msdn.microsoft.com/en-us/live/ff519582.aspx) for changes and then send a notification to the device/app regarding the change.
I am wondering if someone knows the best method for storing data in a global DB against a mobile device (iOS and Android)?
I am building an app that writes/retrieves information based on a query however I need to know if any of the records returned were sent from that device.
Basically the idea is that if a user submits some information (which is stored in the DB) they gain access to additional features of the app. When the app is launched, I will check the DB to see if they submitted information in the past and allow access to other areas.
I use local storage for the information they submitted but also store remotely so if the local storage becomes corrupted for any reason there is still a record of the information the user submitted.
The ID needs to be unique to the device as there could be 100 of users (hoping for millions) so the ID needs to be unique enough that it will never conflict with another device. Any information submitted will be available for retrieval by all other users.
Thanks :)
There are three options as I see it:
1. User
You can create a typical username + password user scheme and use this to verify the user. A possible advantage of this method would be that the user can log in from any of their devices (for instance, under your method a user using the app from their iPhone and iPad would have two different views - which you may not want). Of course, this means forcing every user of the app to register within your system, which is not ideal.
2. App Install
You can uniquely identify an app install by having your app generate a UUID the first time that the app is run (you can use an AS3 helper library to generate the UUID). You can store this UUID locally and send it along with every request the app makes. The downside to this approach is that it doesn't uniquely identify the device - only a specific app install. For instance, if the user deletes the app and then reinstalls it at a later point, it will now count as a new unique device, even though the user is on the same device.
3. Device
AIR does not have a built-in way of reading device identifying info. However, you can retrieve device info through AIR Native Extensions, for example this one can get the MAC address and some other things. There are privacy concerns and other issues involved in reading and storing device info such as these, so you are probably best served trying to implement the OpenUDID project as an AIR Native Extension, since they have already dealt with all such issues. Unfortunately, I have never looked too far into developing ANE's so I am not sure how complicated or feasible it will be to turn OpenUDID into an ANE.
Summary: I would recommend the app install method due to the ease of implementation. If you really need the unique device and are worried about the multiple app installs case, you will have to work out how to use native extensions to get the info you need. If you decide that you would rather identify by user rather than device, use the user method.
As of now I don't think its possible to get the hardware devices guid using air mobile. However you do have a couple of options.
If the MAC address is good enough for you there is an ANE that will let you grab it on both iOS and Android.
http://www.adobe.com/devnet/air/native-extensions-for-air/extensions/networkinfo.html
and an example of how to use it
http://cookbooks.adobe.com/post_Getting_NetworkInfo_from_both_Android_and_iOS-19473.html
You could also write your own ANE, it should be pretty simple to wrap both Android and iOS implementations.
Objective-c: [[UIDevice currentDevice] uniqueIdentifier]
Android: TelephonyManager.getDeviceId()
If your app requires any kind of user account or login the best option would be to store this setting in the remote db.