libGDX asset ownership
Clarifies which screen owns each texture, sound and native resource. It keeps shared assets alive while needed and accounts for mobile activity recreation, avoiding stale references and repeated disposal.
libgdx-assets-native-memory
See how it helpsWhen is it useful?
Use it when scene changes or Android recreation cause missing textures, double disposal or growing native memory.
What does it help you do?
- Distinguishes AssetManager assets from manually owned Disposable resources.
- Tracks shared load counts and graphics-thread requirements.
- Handles Android activity recreation without stale static resources.
Try asking this
Our RPG shares a character atlas between the map and equipment screen. Open and close equipment repeatedly, then simulate Android activity recreation. Check shared assets reload through their owner, manually created resources are released once and no old static reference points to disposed graphics.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
libGDX — assets native memory
Use when loading libGDX assets or diagnosing native/GPU memory growth.
Version and project gate
Inspect Gradle wrapper and modules, libGDX/backend versions, Java toolchain, ApplicationListener/Game/Screen structure, AssetManager ownership, viewport policy, native libraries and supported desktop/mobile/web targets. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Use the project’s AssetManager ownership consistently and distinguish managed assets from manually created Disposable resources. Track load/unload reference counts. Keep graphics object creation on the required thread. Avoid static resource ownership that survives an Android activity unexpectedly.
Deliver
An asset ownership inventory and loading/unloading path with explicit failure behavior. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
Do not dispose an AssetManager-owned object behind the manager or assume a Java reference count reflects GPU lifetime.
Acceptance scenario
Load shared textures in two screens, unload one owner and recreate the activity/screen without invalidating the other owner. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Keiko. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Included files 1
SKILL.md