I’m not sure when this change happened but the built in android post processor is forcing all activities in the manifest to have android:hardwareAccelerated=false
This means it is impossible to override without writing out own post processor to undo this change. It should never be forced to be false or true on all activities as this could negatively interfere with other native activities a developer adds.
It would be helpful to have this at least as a flag in the editor settings along with the correct name of the main activity (for the times when you need to override the default Unity activity)
Hi. We patch android:hardwareAccelerated to false to disable hardware acceleration for native UI. This is never useful for Unity activities (if not, please shout), but still uses various resources. In particular, a separate render thread is created causing the GPU driver to take slow, properly synchronized path and slowing down the app regardless of whether native UI is used or not.
When legacy internal build system was used the android:hardwareAccelerated setting was parsed as false even if not specified in the manifest. When we switched to Gradle by default, we noticed the performance regression due to setting switching to true for some reason and after some investigation concluded that hardcoding this value to the manifest is the best fix. The parsing of the manifest happens in the zygote process, so we concluded this to be some obscure bug of Android and moved on.
What exact problems does this cause to you? Hardware acceleration should be turned off only for Unity activities.
We’ve observed severe performance issues (up to 70% slowdown of draw calls) on some devices when hardware acceleration was enabled. @povilas explained why in the post before. On the other hand, there is zero performance improvement when it is enabled on Unity activity because we don’t make use of native UI elements.
If you are absolutely sure you need the hardware acceleration, you can to the following:
Extract your native UI into a separate activity and enable hardware acceleration there (preferred way)
Maybe but, our plugin adds webview to existing unity activity as we can pass the information from webview to unity very quickly.
Whereas, if we go for a new activity, all unitysendmessage calls are queued and won’t fire until we finish the new activity where webview is rendered. As hardware flag was disabled, the scrolling of webviews and other content was too slow.
Glad I found this thread! Thanks to @KJoanette for creating a thread on this!
Anyways, thanks for pointing at IPostGenerateGradleAndroidProject as it should be good enough for handling the situation. It would be great if you can let us know from which unity version this was changed so that we can add the fix accordingly.
I’m stuck with this issue too. I’m using @Voxel-Busters ’ plugin and without this flag set to true gifs won’t be animated in the webviews.
I’ve tried to use IPostGenerateGradleAndroidProject but it’s 2018 only, and although I’ve been able to use it to fix the manifest there are too many new bugs for me to do such an update, as I’m close to the release date.
Using IPreprocessBuild/IPostprocessBuild isn’t a solution, because the first one is called too early and the latter too late.
The only workaround I have is to export the gradle project, patch the manifest myself and then build the apk, which is painful.
You can enable hardware acceleration for whole app by forcing a manifest change but I have observed various negative side effects of this in the Unity content (apart from the possible slowdown mentioned above) so I suggest only enabling hardware acceleration for a webview activity and not the unity activity - you can do on per-activity basis as detailed here: 硬件加速 | App quality | Android Developers
This will not work in 2017.4.11/LTS and nor does adding a root manifest with hardware acceleration set to true as somewhere between 2017.4.0 and 2017.4.11 you/Unity changed the unity content to use an activity with hardware acceleration off.
I am using Unity 2017.4.3f1.
In the same way, “android: hardwareAccelerated = false” is set on all screens.
How can I make it true? I am very embarrassed.
Actually I’m experiencing issues with this, because I’m using package to add WebView to Unity app with AR also inside it.
All Android phones, even top tier, experiencing lags-to-freeze and heat the phones with hardwareAccelerated=false.
Package developer recommends to set to true, and it worked for some times, as I see it, but now Unity, as I suspect, overrides it and just uses false instead.
I have nothing else to add at the moment.
Use the external packages and webviews in a separate activity; feel free to allow hardware acceleration for that activity.
There are obviously legitimate use cases. Why are we not given any options here? Not every plugin can be modified and this was something that could much more easily be controlled in previous Unity versions…
For webviews, we don’t see any other option if Unity chooses this way. Also, I need to accept this was mentioned sometime back that its better to avoid adding to Unity’s default activity. But we mostly use because of the ease it gives us for better handling.
However, do you have any restrictions on using fragments with in Unity’s default activity?
Unfortunately I don’t have a 100% answer, but our permissions dialog is shown from a fragment so it should be doable.
Feel free to submit a bug report if it doesn’t work for you.