Android basic - "upgraded" myself into no System.Net.Socket

So here’s the story. I’m travelling to do an install on a Unity Android app I maintain (android devices are used as kiosks). I have an Android basic license (two actually since I had to buy one for a sub), and have been fine to date. I upgraded (edit: updated) from 3.5.5 to 3.5.7 (which fixed some issues I had in Unity), but now I can’t compile my project since that feature has been pulled.

So my options are:

  • Roll back to 3.5.5 (would rather not as 3.5.7 is running much better)
  • Run multiple versions side by side? (if that’s possible)
  • Spend $3K for a feature which I previously had for $500 :frowning:

Due to the timeline I don’t want to mess with upgrading to Unity 4. I assume I can still get a Pro/Android Pro license (I’d hope unity 4 allows downgrading). I’ll eventually move to 4, but not until this project is running in the field.

I’m more than a little upset that I am now faced with being forced to pay to keep a feature I had or revert to a buggier version of Unity. I could understand pulling it from 4, but pulling it from a product that had it from the get go is not cool. It leaves a really bad taste in my mouth (especially when time is tight and I just now discover it won’t compile). Imagine taking your car in for a firmware update (had to recently on my vehicle actually) to fix something buggy, then they also remove traction control, “Oh we decided the base model won’t have traction control anymore.” Ok, fair enough, but wouldn’t you just do that to the 2013/2014 model, not my 2010 that came with it?

Anyhow, whining aside, can anyone suggest any other options? How have other users dealt with this?

It’s not like I can suddenly inflate my bill by $3K to cover this.

The System.Net.Socket API has always been Pro only. If you were using them with a basic license in 3.5.5 that is a violation of the contract :wink: That said, we had a bug in < 3.5.6 that allowed access to the socket api and I can fully understand that users trust us to disable API’s which are not part of the license agreement.

from 3.5.6 release notes:
“Android: Enforce that System.Net.Sockets use is only allowed with an Android Pro license.”

Really? Show me that contract.

I had been using it since 3.4.2. I have also been told by sales that if I want to use a previous version that still had that enabled that is OK, but if I want to use 3.5.6 or 3.5.7 I’ll need pro.

I’ll modify my analogy.

It’s like taking your vehicle in for a warranty repair (which the update reminders in Unity are akin to), then having “traction control” or similar removed from your vehicle during a fix because, “That wasn’t supposed to be in that model.” Then having them point at the sales brochure and say, “See it wasn’t in that model.”

The fact is what I paid for and started using had that feature. Whether it was in the license comparison is inconsequential. It’s a sales brochure and may or may not be correct (and may or may not be read by the purchaser). It is not a contract, it’s just marketing material. What matters is what I received and also the precedent set by repeated updates that still allowed me to use that feature. It was only pulled in the penultimate update (assuming 3.5.7 stays the final update).

I really think it should have been pulled in 4, not in the last updates of 3. Yes, it may have not supposed to have been in there, but for whatever reason that mistake was made and it was in 3. In the car analogy wouldn’t you be upset if the dealership removed a feature from the vehicle? I mean, sure pull it from the 2013/2014 model, but pulling it from my 2010 model when I take it in for warranty repair then asking me for more money to upgrade to the model that they want to exclude it to? The difference is it’s easier to do in software. Just because it’s easy doesn’t make it right.

Also, as a side point: does it make sense to have a feature in Free, but when you add an add-on license that feature is removed? I think any of my confusing was from looking at free vs pro then seeing, “Oh free has sockets… so I just need that plus android so I can deploy to that.” So that’s what I purchased and it worked. It’s up to UT’s testers and devs to get it right. It’s not a bug, it was a mistake in access restrictions that happened to benefit the end user which I was oblivious to up until yesterday (ignorance is bliss as they say).

Funnily enough I read release notes before I update, but I jumped from 3.5.5 to 3.5.7 so I missed that. Anyhow, definitely an unwelcome surprise.

So I read through the EULA. While there is a separate license agreement for pro and non-pro editions there is no mention of what’s allowed and what’s not allowed to be used in the API. Where’s the contract that says I’m not allowed to use sockets in non-pro android?

Maybe bad wording on my part. I don’t really now anything about the legal stuff, and if sales says that you can use the sockets in 3.5.5 who I’m I to argue. Go nuts! That said, if you want to upgrade to a later version of unity where we are enforcing what is stated to be pro-only I would try talking to sales and see if you can work something out.

Actually since you are posting this in the android forum there is a workaround if you want socket access on android - which is to use the java socket api. This may not be an attractive solution but if you don’t want to pay for the pro license that is one way to solve the issue.