Possible bugs in android impl of Unity WWW class

Unity Engine
,
1

I’m working on an android game with a paired app that makes a bunch of REST calls using Unity’s WWW class.

In general, when I make a WWW REST request, I start a coroutine, yield on the WWW object and then check for www.error when yield returns.

It looks like on android devices though, that there are cases where the internal WWW code throws an exception and then the code following ‘yield return myWWW;’ never executes.

Below is an example stacktrace from logcat. I’ve seen other (seemingly) uncaught exception types cause the same problem where yield WWW doesn’t work as it’s supposed to.

Device is an HTC Evo, with android 2.2. Unity version is 3.3.0f4:

E/Dhcpcd ( 1846): sending DHCP_DISCOVER with xid 0x1fe75c21, next in 3.65 seconds
W/System.err( 1603): at org.apache.harmony.luni.platform.OSNetworkSystem.connect(OSNetworkSystem.java:115)
W/System.err( 1603): at org.apache.harmony.luni.net.PlainSocketImpl.connect(PlainSocketImpl.java:244)
W/System.err( 1603): at org.apache.harmony.luni.net.PlainSocketImpl.connect(PlainSocketImpl.java:533)
W/System.err( 1603): at java.net.Socket.connect(Socket.java:1055)
W/System.err( 1603): at org.apache.harmony.luni.internal.net.www.protocol.http.HttpConnection.(HttpConnection.java:62)
W/System.err( 1603): at org.apache.harmony.luni.internal.net.www.protocol.http.HttpConnectionPool.get(HttpConnectionPool.java:88)
W/System.err( 1603): at org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnectionImpl.getHTTPConnection(HttpURLConnectionImpl.java:927)
W/System.err( 1603): at org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:909)
W/System.err( 1603): at org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:1152)
W/System.err( 1603): at com.unity3d.player.WWW.run(Unknown Source)

2

We don’t appear to have this exact bug in the database yet, so it would be great if you could file a report for it (menu: Help > Report A Bug).

3

Reported. Interface didn’t give me a bug ID. Is there a user interface to bug tracking?

4

your case number is 406258, and we’re working on your issue, thanks for reporting

5

Interface won’t give you a bug idea, you will get the case number by mail afterwards (you might want to keep the mail as all follow up info you would provide on a bug report is going to be sent as response to it)

6

I’ve got exactly the same problem with some of my WWW requests on Android.
An error message made of the original URL plus the words “short read” is issued, whereas the WWW request never ends.

…quite odd …. what does “short read” means in a WWW error message?
Who issued this error? Unity or maybe the telecom operator gateway?

I am located in France and the problem happened only with a specific telecom operator: Bouygues. With SFR operator the problem never shows up.

I hope this issue is restricted solely to Android …

Has Unity team found something about it?

7

We’ve run into the same problem where WWW requests never end.
Unfortunately we are under pressure to release an Android build of our game really soon.

Is there any update on this issue or are there any known workarounds (that work on WebPlayer, iOS Android)?
E.g. would UniWeb on the Asset Store be a viable option?

Thanks.

8

I have not worked on Android myself but the WWW class have problems on other platforms as well. The UnityWeb project (Google Code Archive - Long-term storage for Google Code Project Hosting.) seems a good replacement for that. UnityWeb handle the basic HTTP request (get / put) . The short-coming of UnityWeb is it does not support a networking environment with proxy.

With some modification (i.e. replacing the ThreadPool), it worked well in our NuTracking library on the AssetStore (NuTracking Library | Integration | Unity Asset Store).

9

I’m not sure if this is the same problem or not, but I’ve had several cases where yield www (js) or yield return www (cs) hangs right at that point.

If this is indeed the problem you all are having a simple workaround is to write it like this:

// javascript
while ( !www.isDone )
{
     yield;
}

// C#
while ( !www.isDone )
{
     yield return null;
}

Again, not sure if this is the same problem, but I hope this helps,
Nathan