GameActivity has the following dependencies:
GameActivity uses CMake to produce the bridge code (libgame.so) during the build process.
Note: If you provide a custom Android SDK, be sure the SDK has CMake 3.22.1 included.
GameActivity requires the following AndroidX GradleAn Android build system that automates several build processes. This automation means that many common build errors are less likely to occur. More info
See in Glossary dependencies:
androidx.appcompat:appcompatandroidx.games:games-activityandroidx.core:coreAndroidx.constraintlayoutGradle installs AndroidX and these dependencies automatically.
If you use GameActivity, your application player loop runs on a native thread rather than a Java thread. This means that calling Java APIs like myLooper from plug-insA set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
See in Glossary will fail. In the case of myLooper it’s because there’s no Java looper present on the native thread. This also means that any API that uses APIs such as myLooper will also fail. For example, registerInputDeviceListener will fail if the handler is null. It’s important to understand this limitation when you create Android plug-ins.
If you use GameActivity, Unity tries to use the NDK choreographer to synchronize frame times. If the Device API Level is lower than 24, or your application uses a 32-bit Player and the Device API Level is lower than 29, Unity uses the Java choreographer.