Attribute Qt::AA_EnableHighDpiScaling must be set before QCoreApplication is created.
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QObject(0x7f810b42a740), parent’s thread is QThread(0x7f812b414cd0), current thread is Thread(0x7f812b7fd560)
Which is a compression issue that was supposed to be fixed in 2022.1.0a14
Stack below complains about ALLOC_TEMP_UnityGfxDeviceWorker, only one ref on the internet:
Unloading 6 Unused Serialized files (Serialized files now loaded: 3)
Scanning for USB devices : 0.641ms
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Calling Deallocate on pointer, that can not be deallocated by allocator ALLOC_TEMP_UnityGfxDeviceWorker
Got a bus while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
Thread 0x70000456d000 may have been prematurely finalized* Assertion at mono-threads.c:702, condition `info’ not met, function:mono_thread_info_current,
Obtained 0 stack frames.
Launching bug reporter
AcceleratorClientConnectionCallback - disconnected - :0
Attribute Qt::AA_EnableHighDpiScaling must be set before QCoreApplication is created.
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QObject(0x7fd83dc53aa0), parent’s thread is QThread(0x7fd83de05640), current thread is Thread(0x7fd83dee15e0)
@darashayda Hi there, me and the team looked at your issue and we have a couple of suggestions.
Would it be possible for you to double check the issue number you provided in your post earlier? The issue number you provided (#1142238) doesn’t lead to anything for me.
The 404 error that comes up in this post seems to suggest that the file that you’re trying to access doesn’t exist within the APK you’re using - if you’ve rebuilt addressables without also rebuilding the APK, this could be the source of your issue. I would recommend taking a look at the specific APK giving you issues and make sure that any local files that are giving you errors actually exist within the APK before going any further. The reason why checking inside the APK is important despite the fact that it says that it’s a 404 error is because android will often use web requests and urls for local files, making it seem like a CCD error when it may not necessarily be one.
Another possibility is that if you’re building addressables on one project (project A), and building the player on another project (project B), then its possible that the error you’re encountering could be because since project B didn’t have addressables built with it it has no settings.json file - this is worth looking out for. If this is the case, you have two main options.
If project B has no Addressables content itself and gets all of it from the addressables project, you should include the entirety of your Library/com.unity.addressables folder from project A in project B so that it can access all of the addressables data needed to run the project.
if project B also has Addressables data and you’re using LoadContentCatalogAsync to use different projects’ catalogs, then you should copy the link.xml file from each of the other addressables projects into project B to ensure that the player knows what data to not strip away. Alternatively, you could just disable code stripping all together to avoid this problem.
I built the Addressable , a null group. And this is the correct way and worked well 2020 and 2021.
We cannot copy any actual files from Project A to Project B i.e. the player, since we are circulating through large number of Addressable scenes which often share nothing between themselves.
So copy such local files then defeats the purpose of CCD and Addressables all together.
Before we go forward, I need to make sure we are talking about the same thing, since these local file copying is a huge setback for our entire strategic plan!
Project A is a normal Unity project. Except one of its scenes is selected as Addressable.
Project B is a copy of Project A except all the CONTEN e.g. player geometry or weapons and so on which were in the scene were removed!
However Project B has all the original directory structure and all the animators and UI and scripts are included.
This is correct usage of Addressable per documentation and our previous versions.
For example we have multiple entire scene content loaded into a single scene in Project B, all read by Adrdessables and CCD over the net. And it worked!
So we could have TB of content in CCD, and have a tiny Android project of less than 100MB! that can serve all the content without local file copying.
If I copy all the files that were in Project B into Project A, then the entire purpose of CCD and Addressables is defeated.
Shane one other fact: The Project B is intermittent! It does not always crash! So the theory that some files are not properly copied might not explain it all, there are other factors.
I am noticing for a while that LoadSceneAsync () does not fully works as specified. It does not delete the previous scene and does not clean up the residual related variables.
As a result a race condition or corruption might occur.
This I know because I place delays in the code and the Project B behaves drastically different in those regards.
I will try to build a particular project for your perusal to see for yourself.
Dara
SOURCE: Choose a game on Android platform in Unity 2022.1.0a16, then select a scene or bunch of assets and turn them into Addressables.
Build group with local build path any directory under Assets directory, and it is called Assets/aa by default.
Go to CCD and make a bucket ONLY FOR ANDROID use, and then copy the Assets/aa to that ccd bucket.You can place the latter anywhere else.
TARGET: Copy the Unity project into a new clone project, call it different name
WARNING: DO NOT COMBINE SOURCE AND TARGET INTO ONE PROJECT.
Create an empty Asset group, Build it once only. There might be another way of doing this, but it works.
Delete, in TARGET directories, only the corresponding content related to SOURCE Addressables e.g. prefabs for characters or related textures or weapons and so on, MAKE SURE NOT TO DELETE ANY DIRECTORIES and make sure NOT TO DELETE ANY SCRIPTS OR ANIMATORS …
This deleting will reduce the size of the binary and reduces confusions at Addressable Groups.
7. DO NOT RUN THE EDITOR AT ALL, MAKE SURE EDITOR IS FRESHLY STARTED
8. ONLY BUILD or Build and RUN while connected to an Android box!!! <— If you Run the Editor prior to this step, it does not work! And intermittently causes crash, hang on the Editor with the odd /aa error messages on Android box!!!
If need be , exit Editor and start a fresh Editor for TARGET and make the final BUILD.
FYI, the above anomaly, maybe not a bug so to say, still requires handling at your ends.
I was able to find a workaround and reproduce the problem.
I truly suggest you take @xwin28 comments seriously, we are seeing some strange Unwanted Residual States in Addressables and possibly CCD.
And the errors we reported in log files are odd! And as you indicated they are not even Unity errors, they are Android errors caused by some unwanted configuration at the Build process. ← Conjecture.
I spoke with the team a bit more about recommended ways to set up the project for your use case and one of my team members gave this advice:
"In Project B (Content project)
Target build location for the Groups outside of the Library folder location for managed internal data from Addressables.
Setup a Remote catalog, in the Addressables settings. With this also set to the groups locations / ccd load and custom build path.
Upload the Bundles and remote catalog (.json and .hash)
In Project A (Player project)
Ensure all Scripts are included in this project - this is important as otherwise the player will not be able to reference the scripts necessary to run the project
We need the Player to know where to load the content from.
2a. Initialise Addressables into the project and setup the AddressableAssetSettings the same as Project B
2b. We now need to make a Addressables build in order to generate settings.json which these settings for the runtime.
Disable code stripping so that none of the scripts are stripped from the Player (as the build sees that they are not used)
Build Player
Alternative to 2:
2a. Copy settings.json and link.xml from Project B to Project A. This gives project A the information about where to find data from Project B and what was used.
These two files need to be included when doing the Player build in order to make sure that the Player can correctly identify where to get information about Assets from Project B:
settings.json - Contains information about where to get the catalog of from. And what settings are setting from AddressableAssetSettings.
link.xml - Tells the Player build what scripts not to strip. Because the Player does not include content set in Addressable, it does not know if the code for it should be stripped out or not. "
This business with entering play mode causing an issue with Android sounds concerning and I believe is worth getting into. If you could please send a bug report to QA with a simple project we can use to reliably recreate the issue we would be more than happy to take a look into it.
I highly recommend that any further issues you encounter, particularly issues that you believe to be bugs, you send in bug reports to QA as opposed to posting on the forums. While posting on the forums is an excellent way to get fixes to small issues or advice on certain things, the platform is simply not intended for long term, involved debugging conversations such as these. The entire team wants to help, and we take the concerns you’ve raised very seriously. Hopefully this explanation gives some useful guidance.
I hope that this correspondence has helped you gain a better understanding of your issue and that the combined insights of all of these posts will help you solve your issue. Once your bug report(s) make it through QA, the team will be sure to take a look at them and fix any issues we’re able to identify in future versions. Thank you.
Hello Shane
Thank you for your professional assessment and aid in this matter.
I shall work on the bug report, I just do not like to file bogus bugs to clutter your systems. So please be patient with the introductory communications.
ALTERNATIVE 2 defeats the purposes of Addressables and CCD for our organization.
The preceding for both A and B are 100% what we already put in place and THEY WORK!
So this is the plan per your guidance:
Create a simple small enough testbed
File a bug report ON PLAY MODE anomaly
We will take care of all this in coming 12 hours and thank you.
Working on releasing some samples. Demo bug in actual projects + videos for the support. This particular bug is now found all over 2021 and 2022, at least on our mac machines.
BUT good news is, if we avoid running the games in the Editor and instead do BUILD&RUN … no issue per LogCat, the minute the game runs once in the Editor horror ensues
Thank you, xwin28, I don’t use any clouds, but had this issue. Your info helped workaround the issue (restart unity, do not play in the editor, rebuild addressable, build and run on Android).
Just to drop my issue and solution to it, it might help some other addressables wonderer
I also had an issue with loading settings.json file noted in the original post. The reason for it was that we are exporting android project and then performing build from Android Studio (apk + obb) and then deploying manually on the phone. I believe that settings.json ends up in the the .obb (since it gets copied in StreamingAssets during Player build) and that is why it had trouble loading it. In order to make the work, the following steps should be respected:
Connect the phone to PC
Copy .apk
Install .apk and launch the game (not sure if launching is mandatory)
During install the folder will be created in [your phone]\Internal shared storage\Android\obb[bundle id]. This folder is recreated each time you install the apk so you’ll need to copy it each time you reinstall apk
Find your .obb created by Android Studio and rename it to main.[build version].[bundle id].obb
This error still happens in Unity 2021.3.1f1, Addressables 1.19.19. I am not using Unity Cloud.
Steps:
Build addressables (Play Asset Delivery)
Build Android Project
Upload to google play console
Install on device
Open the game
Has this issue been already solved? I tried everything that was mentioned above, except the unity cloud solutions and nothing helped. This error still persists. I am about to drop addressables already, it is a big showstopper.
However, I somehow made it work just for one time, but I am not sure how - I was using the Unity samples (https://github.com/Unity-Technologies/Addressables-Sample) to build my project just for a try if it will work from there and for some reason it worked, the error was gone, but that project uses windows platform. But now after some times again, the error is still there.
For someone who copies .apk and pastes on your connected phone, see KwahuNashoba’s post.
I didn’t even know what .obb file was, which caused this error in my case.
You can try his solution or my workaround which was to uncheck “Split Application Binary” (https://docs.unity3d.com/2018.4/Documentation/Manual/android-OBBsupport.html) under Publishing Settings so that I can install an app without .obb file.
I hope that it logs in android something like “You better check obb file” to clarify the issue.
I have the same problem with localization, and the reason is that i forgot to click build in addressables groups.
This thread will help anybodoy have the same problems, it simple: [SOLVED] Loading localization (Addressables) fails in Android ?fbclid=IwAR1IhDHcj-2ae6d8x5BaeMB2jwwak8RkehrfVOkVbwsbOfuEAnSde52irJo