Memory leak in HandleProxyFactory.kt DroidGuard class cache ClassLoader not Unloaded java.lang.UnsatisfiedLinkError Library already loaded in another classloader
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 14.6k
- Forks
- 3.2k
- Avg merge
- 12d 11h
- Merged PRs (30d)
- 4
Description
Describe the bug
HandleProxyFactory keeps a cache of DroidGuardClass in classMap fun loadClass https://github.com/microg/GmsCore/blob/048a6e59f1cd9192eb614fb73db3304c058574cb/play-services-droidguard/core/src/main/kotlin/org/microg/gms/droidguard/core/HandleProxyFactory.kt#L214.
but DroidGuardHandleImpl.kt creates a new copy of the class everytime PlayIntegrity or Safetynet is checked so the previous DroidGuardClass cache never gets unloaded and you get error java.lang.UnsatisfiedLinkError Library already loaded in another classloader when you try to check PlayIntegrity or Safetynet multiple times
To Reproduce
1.) Install SPIC - Play Integrity Checker
2.) Check Integrity It works fine for the first time
3) Check Integrity Multiple time. It fails and crash occur internally on adb with error java.lang.UnsatisfiedLinkError Library already loaded in another classloader
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
System
Android Version: 11
Custom ROM: LineageOS 18
Additional context
This was tested with official playstore
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in play-services-droidguard/core/src/main/kotlin/org/microg/gms/droidguard/core/HandleProxyFactory.kt at loadClass around line 214, then inspect DroidGuardHandleImpl.kt and how repeated PlayIntegrity or Safetynet checks create class copies. Reproduce the failure by checking integrity multiple times and verify that repeated checks no longer produce UnsatisfiedLinkError or retain obsolete class loaders.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100