Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Bug (Case 1344710) Addressables method calls never complete on Android if hosting service is unreachable

Discussion in 'Addressables' started by Peter77, Jun 21, 2021.

  1. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,591
    Unity 2019.4.20f1 and Addressables 1.18.4.

    On Android, methods like
    Addressables.DownloadDependenciesAsync
    never complete, if the hosting service is unreachable.
    On Windows it does work and those method calls return with the status "Failed".

    I attached videos to bug-report Case 1344710 where I go over each of the reproduce list to proof the issue exists.

    Reproduce
    1. Open project on Windows
    2. Open File > Build Settings and turn on "Development Build"
    3. Switch Platform to PC Standalone
    4. Open "Window > Asset Management > Addressables > Hosting" and enable it
    5. Open "Window > Asset Management > Addressables > Profiles" and enable "Editor Hosted"
    6. Open "Window > Asset Management > Addressables > Groups" window and click "Build > New Build > Default Build Script"
    7. Open File > Build Settings and turn on "Development Build"
    8. Press "File > Build and Run"
    9. In the Player click "Check for new Content" and quickly switch back to Unity to disable the local hosting service
    10. In the Player it now displays "Download failed". Press retry. It displays "Download failed" again. (this is expected)
    11. Enable local hosting service in Unity
    12. In the Player press retry. It continues the download. (this is expected)
    At this point you figured out it works on Windows. Now let's try it on Android...
    1. Switch Platform to Android
    2. Open "Window > Asset Management > Addressables > Profiles" and enable "Editor Hosted"
    3. Open "Window > Asset Management > Addressables > Groups" window and click "Build > New Build > Default Build Script"
    4. Press "File > Build and Run"
    5. In the AndroidPlayer click "Check for new Content" and quickly switch back to Unity to disable the local hosting service
    6. In the AndroidPlayer it now displays "Download failed". Press retry.

    Actual
    Pressing "Retry" in the AndroidPlayer never completes.
    The method call Addressables.DownloadDependenciesAsync never completes on Android if the hosting service is unreachable.

    Expected
    Addressables.DownloadDependenciesAsync and Addressables.CheckForCatalogUpdates return "Failed" if the hosting service is unreachable.
    Calling Addressables.DownloadDependenciesAsync after it failed, now with a valid connection to a hosting service, should be able to download the data again.

    Notes
    I also tested the "Request Timeout" setting found an AddressablesGroup asset. However, this causes that larger files can't be downloaded anymore without a timeout. So this isn't a solution/workaround.
     

    Attached Files:

    Last edited: Jun 21, 2021
    KingKRoecks and TreyK-47 like this.
  2. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,591
    This issue continues to exist in Addressables 1.19.6. When the remote location is unreachable, e.g. no Wi-Fi,
    CheckForCatalogUpdates
    never returns and the app is stuck in this step.

    This is very basic and important functionality that's malfunctioning. Do you have any idea why it's ignored, @TreyK-47 ?

    Not even QA responded to this bug-report yet. It's been more than 3 months since I submitted the issue. That's very disappointing.
     
    KingKRoecks likes this.
  3. TreyK-47

    TreyK-47

    Unity Technologies

    Joined:
    Oct 22, 2019
    Posts:
    1,816
    Lemme ping the team for some insight.
     
    Peter77 likes this.
  4. pillakirsten

    pillakirsten

    Unity Technologies

    Joined:
    May 22, 2019
    Posts:
    346
    Hi @Peter77 sorry for the delay. I've messaged QA about your ticket. There was a blocking issue that prevented them from investigating the reported bug. It's been resolved now, so you should see some new movement on it soon.
     
    xLeo likes this.