Flurry sdk and deprecation of UDID

Solar2D General Questions/Discussion
#1

Hi there,

As some of you noticed too, flurry sent an email, stating that we should upgrade to their latest sdk 3.0.9. Apple is deprecated UDID usage as you may know, and flurry is going to use a new system for tracking devices. The important thing is, if we continue to use their old sdk, some historical data may be lost :confused:

Do ansca plan to release an update including those new flurry sdk? What will deprecation of UDID mean for us corona users? We tend to get deviceID by calling system.getInfo(“deviceID”), and some of us may use it as an authentication mechanism for device user. How would this function will be affected? 

I personally use UDID to authenticate users to a backbone server on one of my online games and I am very curious about the future (and replacement) of this functionality.

Below I copy and pasted flurry’s notice:

Important Notice Regarding Your Flurry Analytics Service

As you may know, Apple is in the process of deprecating the UDID for the iOS platform. To ensure that
 your Flurry Analytics service continues normally, we ask that you now update your SDK to Flurry SDK 
3.0.9. The steps to download the SDK can be found here.

In response to Apple's deprecation of the UDID, Flurry has created an alternate identification scheme. 
During testing, we have identified a few cases where if you do not make this SDK update, your 
historical data could be affected. To avoid this, please update your SDK by Friday, March 23. 

If you have any questions, please don't hesitate to contact us at support@flurry.com.

Thank you,

The Flurry Team

[import]uid: 11686 topic_id: 23394 reply_id: 323394[/import]

#2

yup, what should we do if we continue to use it? [import]uid: 128551 topic_id: 23394 reply_id: 93728[/import]

#3

+1 – I was just about to publish an update for one of my apps that uses Flurry, but now I’m wondering if I should hold off. [import]uid: 87249 topic_id: 23394 reply_id: 93772[/import]

#4

Yep. We are aware and will address this ASAP.

C. [import]uid: 24 topic_id: 23394 reply_id: 93852[/import]

#5

Right after the iPadGate :smiley:

When it rains it pours.

Thanks for the quick response Carlos [import]uid: 110373 topic_id: 23394 reply_id: 93865[/import]

#6

Subscribing to keep track of updates to this. Any estimate on how long it will be? Days? Weeks? Months? [import]uid: 91921 topic_id: 23394 reply_id: 94016[/import]

#7

It would also be great if we could get event parameters during the Flurry update.
[import]uid: 122310 topic_id: 23394 reply_id: 95475[/import]

#8

@Carlos,

What is the status of getting a build out that uses the new Flurry SDK? This article was just posted on TechCrunch:

Amid Privacy Concerns, Apple Has Started Rejecting Apps That Access UDIDs
[import]uid: 16734 topic_id: 23394 reply_id: 96031[/import]

#9

This is huge.

We need a way to get unique, device specific identifiers. And the problem here is; If you already have a system which is based heavily on UDID usage, you must change all those obsolete ids with new ones. To do this operation one already should be able to access old UDID system :slight_smile: If apple is rejecting UDID usage, how one can possible fix this issue with an update??

For corona side; we definitely need a new function. But old functionality (eg: system.getInfo(“deviceID”) ) should be still there. Also this ‘patch’ should be applied to latest stable 704, so we can update our versions for pre 4.3 devices.

I am using UDIDs to authenticate unique users without requiring an username/password pair and this ‘rejection’ issue is driving me crazy now :confused: [import]uid: 11686 topic_id: 23394 reply_id: 96259[/import]

#10

Eep! Just submitted an update to my app last night and I’m using Flurry. Any ETA on this guys? [import]uid: 44127 topic_id: 23394 reply_id: 96600[/import]

#11

We’re looking into this. We saw a strange message from Flurry’s VP on another mailing list:

> I want to make sure everyone is aware that Flurry SDKs absolutely use the SDK and we have no version in the market that is “UDID free.”

We think this is odd b/c this implies that the updated Flurry SDK still uses the “outlawed” API. We’re trying to get to the bottom of this. So we may be forced to remove Flurry if that’s the case, which is obviously not ideal for you folks using Flurry today. Please bear with us.

The current solution we are looking at involves using OpenUDID.
[import]uid: 26 topic_id: 23394 reply_id: 96698[/import]

#12

Hi Walter,

Have you checked out SecureUDID as well? http://www.secureudid.org/ [import]uid: 27183 topic_id: 23394 reply_id: 96714[/import]

#13

This extends beyond Flurry. Based on an Amazon rejection, Inneractive is using the UDID on their calls to get ads. I don’t know if this impact inMobi, but I suspect they are using the UDID as well.

[import]uid: 19626 topic_id: 23394 reply_id: 96725[/import]

#14

@robmiracle,

That’s bad news, but good to know. We were just about to release an app with Inneractive ads. Now we will have to skip that and charge for the app, which as you know means a lot fewer downloads than a free ad supported app. [import]uid: 16734 topic_id: 23394 reply_id: 96730[/import]

#15

Ken, I’m not sure we should panic yet. This was an android build and perhaps Inneractive does something different for iOS.

What we need is to know what all is impacted.

[import]uid: 19626 topic_id: 23394 reply_id: 96731[/import]

#16

Ansca,

Is there an update on this? We have 3 new apps, and an app that was already released, and we would like to have analytics in all of them.

The apps are all ready to go, just waiting on this issue.

Thanks! [import]uid: 16734 topic_id: 23394 reply_id: 99866[/import]

#17

Ken, we think that you should go ahead and publish (with the current Flurry SDK in Corona). There is very little chance it will get rejected. And once it is published, Apple will NOT take it out because of this. Over the next few weeks, once we get the new SDK in there, you can put out an update.

We are still working on this with all partners. Everyone (Inmobi, inneractive, flurry, openfeint, etc.) is/was using UDIDs. We need to coordinate this as much as possible to make the transition reasonably painless for everyone.

David
[import]uid: 10668 topic_id: 23394 reply_id: 99869[/import]

#18

Why don’t you give us access to the device MAC address? [import]uid: 86243 topic_id: 23394 reply_id: 103596[/import]

#19

The device MAC address poses the same problems a UDID does. It uniquely identifies the device.

[import]uid: 19626 topic_id: 23394 reply_id: 103602[/import]

#20

That’s the point: a way to uniquely identify the device. [import]uid: 86243 topic_id: 23394 reply_id: 103605[/import]