Search Issue Tracker
Fixed in 2019.2.X
Fixed in 2019.3.X
Votes
24
Found in
2019.2
2019.2.0f1
Issue ID
1178696
Regression
Yes
[Android] Application.internetReachability returns NotReachable on certain devices even if internet is available
To reproduce:
1. Open attached project "InternetReachability.zip"
2. Build and run on Android device
3. Observe the output on screen
Expected: "ReachableViaCarrierDataNetwork" or "ReachableViaLocalAreaNetwork" is returned
Actual: NotReachable is returned
Reproduced in: 2018.4.8f1, 2019.2.3f1, 2019.3.0b1, 2020.1.0a1
Reproduced on devices:
VLNQA00012, Samsung Galaxy S6 (SM-G920F), Android 7.0, CPU: Exynos 7 Octa 7420, GPU: Mali-T760
VLNQA00013, Samsung Galaxy S6 edge+ (SM-G928F), Android 7.0, CPU: Exynos 7 Octa 7420, GPU: Mali-T760
VLNQA00123, Google Pixel 2 XL (Pixel 2 XL), Android 9, CPU: Snapdragon 835 MSM8998, GPU: Adreno (TM) 540
Not reproduced on devices:
VLNQA00115, Sony Xperia Z3 (D6603), Android 6.0.1, CPU: Snapdragon 801 MSM8974AC, GPU: Adreno (TM) 330
VLNQA00017, Huawei Nexus 6P (Nexus 6P), Android 8.0.0, CPU: Snapdragon 810 MSM8994, GPU: Adreno (TM) 430
VLNQA00057, Htc One M9+ (HTC_M9pw), Android 5.0.2, CPU: MediaTek Helio X10 MT6795T, GPU: PowerVR Rogue G6200
VLNQA00272, Samsung Galaxy S10+ (SM-G975U), Android 9, CPU: Snapdragon 855 SM8150, GPU: Adreno (TM) 640
VLNQA00015, Samsung Galaxy Note8 (SM-N950W), Android 8.0.0, CPU: Snapdragon 835 MSM8998, GPU: Adreno (TM) 540
Note: could not test on 2017.4 and 2019.1 due to broken components
-
yosun
Feb 14, 2020 04:01
Which Fixed in 2019.2 has it been fixed in? Currently using 2019.2.2f1 and experiencing this for both Pixel XL 2 and OnePlus normal Android phones
-
enescetin1903
Oct 23, 2019 14:41
I have the same problem. Unity Version: 2019.2.4f1
-
VGMFR
Oct 22, 2019 15:59
Very annoying issue, 100% reproductible on all our Android devices. I hope it can be fixed soon in 2019.2, as it forces us into making really ugly workarounds...
-
angelsm85
Oct 16, 2019 10:10
Hi! Is there an estimated date this issue will be fixed?
-
jackatfp
Oct 12, 2019 11:27
The problem is even worse that we found out the game can only connect to our AWS load balancer via mobile data but not WiFi. It will keep saying that there is no connection if we use WiFi. It becomes a serious issue now.
-
justtime
Oct 12, 2019 09:52
Same here on 2019.2.8f
-
angelsm85
Oct 11, 2019 15:42
Same issue when upgrade to 2019.2.6.f1
-
robertsze
Oct 04, 2019 13:33
After weeks of not a single reply from the Unity team we decided to workaround this issue with a simple android plugin. Just makes us wonder if its worth the time reporting bugs in future at all...
-
robertsze
Sep 28, 2019 08:56
We can confirm that it shows the correct state once coming back from background.
So, after initial start (while there is a valid connection)
Second 0 : NotReachable
Second 1 : NotReachable
...
Second 60: NotReachableSwitch app to background
Switch app to foregroundSecond61: ReachableViaLocalAreaNetwork
-
remi-sormain-vrdirect
Sep 23, 2019 10:18
Noticed the same on OnePlus 3T, Galaxy S9, Oculus Go.
The resolution note does not work, I checked the result in the next frames, waited for 10 seconds, the result was still Unreachable.
However I noticed on OnePlus at least that if you do send an HTTP request, then the result of Application.InternetReachability is correct.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Asset Bundles retain their previous hash and CRC values when an object within a bundle is changed and rebuilt
- APV Reflection Probe Normalization breaks when SSGI is enabled
- Default Custom Components in project have Library counterparts
- [iOS]"The destination host has an erroneous SSL certificate" error is thrown when using UnityWebRequest to connect to the server with a self-signed certificate
- Freeze/crash on DynamicHeapAllocator::Allocate when opening a specific project
Resolution Note (fix version 2019.2):
First frame does really return "Unreachable", but the second frame is already good. Since the OS API is async and we don't want to wait for the callback on the main thread on the first frame, this is an expected behavior. Please wait for the second frame to get a reliable result.