Last 12 weeks ยท 1 commit
5 of 6 standards met
Thanks for proposing a pull request! To help us review the request, please complete the following: [x] sign contributor license agreement [x] I've ensured that all existing tests pass and added tests (when/where necessary) [x] I've updated the documentation (when/where necessary) and Changelog (when/where necessary) [x] I've added the proper label to this pull request (e.g. for bug fixes) Pull Request Details Describe what you accomplished in this pull request (for example, what happens before the change, and after the change) Test Plan Test Plan: Add your test plan here
Hello Facebook! I'm trying this PR again, which got closed as stale by your bot previously. @rageandqq any chance you can take a look? โ sign contributor license agreement โ I've ensured that all existing tests pass and added tests (when/where necessary) โ I've updated the documentation (when/where necessary) and Changelog (when/where necessary) ๐ซ I've added the proper label to this pull request (e.g. for bug fixes) (I don't seem to have permission to do this) Pull Request Details We have an issue with high ANR rates on our Unity app, and the stack trace points to these two long standing open issues with this SDK: com.android.installreferrer is called in the main thread which leads to ANR #1039 InstallReferrerUtil.kt com.facebook.internal.InstallReferrerUtil$tryConnectReferrerInfo #672 I am not a Kotlin expert, but it seemed like this was a simple change to bring the call to over to a different thread. [!WARNING] This change assumes it is okay to make the callback from a different thread than . In my brief check of the codebase, this looked okay, but if necessary we may want to bring the callback back to the main thread. While doing this, I noticed that the try/catch for cleaning up the wouldn't work if an exception was thrown from , so I moved that cleanup to a finally block instead. Test Plan I have run the test app, but cannot test this code quite yet in my own app, as I haven't explored how to bring this over to Unity. I was hoping by starting here with this repository so I could get feedback before trying to get this brought in to the Unity package as well. If there is something I can do to help test this, please let me know! My goal here is to get the ball rolling with this conversation so that we can address the high ANR rates caused by this SDK.
Repository: facebook/facebook-android-sdk. Description: Used to integrate Android apps with Facebook Platform. Stars: 6467, Forks: 3695. Primary language: Kotlin. Languages: Kotlin (93.5%), Java (6.3%), Shell (0.2%), AIDL (0%). Homepage: https://developers.facebook.com/docs/android Latest release: sdk-version-18.0.3 (10mo ago). Open PRs: 1, open issues: 147. Last activity: 1mo ago. Community health: 87%. Top contributors: jingping2015, KylinChang, jawwad, maxalbrightmeta, mingflifb, swiese, dreamolight, mingcaozhang, kongxinzhu, laughingguitarist and others.
Checklist before submitting a bug report [x] I've updated to the latest released version of the SDK [x] I've searched for existing Github issues [x] I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group [x] I've read the Code of Conduct [x] This issue is not security related and can safely be disclosed publicly on GitHub Java version 17.0.0 Android version API 33, API 34, API 35 Android SDK version 17.0.0 Installation platform & version Gradle Package Login Goals Login with Facebook Expected results Eliminated ANR reported when users attempt to Login with Facebook. Actual results Application Not Responding Stacktrace "main" tid=1 Timed Waiting at jdk.internal.misc.Unsafe.park (Native method) at java.util.concurrent.locks.LockSupport.parkNanos (LockSupport.java:252) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await (AbstractQueuedSynchronizer.java:1757) at com.facebook.internal.security.OidcSecurityUtil.getRawKeyFromEndPoint (OidcSecurityUtil.kt:50) at com.facebook.AuthenticationToken.isValidSignature (AuthenticationToken.kt:157) at com.facebook.AuthenticationToken. (AuthenticationToken.kt:66) at com.facebook.login.LoginMethodHandler$Companion.createAuthenticationTokenFromWebBundle (LoginMethodHandler.kt:249) at com.facebook.login.NativeAppLoginMethodHandler.handleResultOk (NativeAppLoginMethodHandler.kt:134) at com.facebook.login.NativeAppLoginMethodHandler.processSuccessResponse (NativeAppLoginMethodHandler.kt:60) at com.facebook.login.NativeAppLoginMethodHandler.onActivityResult (NativeAppLoginMethodHandler.kt:95) at com.facebook.login.LoginClient.onActivityResult (LoginClient.kt:135) at com.facebook.login.LoginFragment$getLoginMethodHandlerCallback$1.invoke (LoginFragment.java:73) at com.facebook.login.LoginFragment$getLoginMethodHandlerCallback$1.invoke (LoginFragment.java:71) at com.facebook.login.LoginFragment.onCreate$lambda-1 (LoginFragment.java:67) at androidx.activity.result.ActivityResultRegistry.doDispatch (ActivityResultRegistry.kt:350) at androidx.activity.result.ActivityResultRegistry.dispatchResult (ActivityResultRegistry.kt:311) at androidx.activity.ComponentActivity.onActivityResult (ComponentActivity.kt:756) at androidx.fragment.app.FragmentActivity.onActivityResult (FragmentActivity.java:151) at android.app.Activity.dispatchActivityResult (Activity.java:8985) at android.app.ActivityThread.deliverResults (ActivityThread.java:5793) at android.app.ActivityThread.handleSendResult (ActivityThread.java:5839) at android.app.servertransaction.ActivityResultItem.execute (ActivityResultItem.java:67) at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45) at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:139) at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:96) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2560) at android.os.Handler.dispatchMessage (Handler.java:106) at android.os.Looper.loopOnce (Looper.java:243) at android.os.Looper.loop (Looper.java:338) at android.app.ActivityThread.main (ActivityThread.java:8524) at java.lang.reflect.Method.invoke (Native method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (Runtim Steps to reproduce This happens on a percentage of our users login flow. Affected devices Infinix Infinix-X6532 OPPO OP575DL1 OPPO OP5B16L1 Infinix Infinix-X6531 realme RE5C9F vivo V2310 vivo V2333 realme RE58BC TECNO TECNO-KL5 realme RE6054 Itel itel-A667LP Itel itel-A669L OPPO OP571F OPPO OP5759L1 Redmi gale realme RE6095 realme RE8DDCL1 Infinix Infinix-X6525D Infinix Infinix-X6711 Itel itel-A667L OPPO OP571DL1 OPPO OP574FL1 OnePlus OP5955L1 TECNO TECNO-KL4 TECNO TECNO-LH7n VGO_TEL Flex_2 google tokay Code samples & details
Hello Facebook Android SDK team, We are using the Facebook Android SDK in our app, and it is failing a third-party security audit (4.1.2.3.6 ๆๆๆง่ณๆๆๆก็จ้ฉ็ถไธๆๆไน้้ฐ้ทๅบฆ่ๅ ๅฏๆผ็ฎๆณ๏ผ้ฒ่กๅ ๅฏ่็ๅๅฒๅญ) due to usage of insecure random number generators. Specific finding (from decompilation via jadx-gui and Semgrep rule mastg-android-random-apis-insufficient-entropy): https://github.com/facebook/facebook-android-sdk/blob/1b75585d2cad512f745af6657f0ad688ad237e96/facebook-core/src/main/java/com/facebook/FacebookException.kt#L28-L39 Breakdown of the Finding: File: (from Facebook Android SDK, detected via decompilation) Rule: (OWASP MASTG-derived Semgrep rule) MASVS Reference: [MASVS-CRYPTO-1] - requires strong cryptography and sufficient entropy for crypto-related operations Issue: is an instance of (weak PRNG with insufficient entropy), and is used for conditional sampling (likely error reporting throttling or debug logging) Why flagged: Auditors require all RNG usage in the APK to use cryptographically secure sources (e.g., , NIST SP 800-90A compliant) when evaluating encryption-related criteria โ even if the specific usage is non-crypto Context: This line appears to be for lightweight random sampling (e.g., throttling logs, error reporting probability), not for cryptographic key/IV/nonce generation. However, strict audits (common in Taiwan, government/finance sectors) fail the entire app if any or appears in the binary, without deep context analysis. We cannot patch the SDK ourselves, and upgrading to the latest version (18.x as of Jan 2026) did not remove this pattern (based on our testing). Our Concerns and Questions**: We're concerned that this pattern is blocking compliance/certification for our app, even though the usage appears to be non-cryptographic. What is the Facebook team's position on using in SDK code for non-crypto purposes? Is this considered acceptable, or are there plans to migrate to ? How should developers handle this situation when facing strict security audits that flag all RNG usage regardless of context? If this has already been addressed in a recent or upcoming version, could you point us to the relevant changelog or commit? This appears to be a low-severity issue in practice (no real security risk from sampling), but it's blocking certification/compliance for our app and potentially others in regulated markets. We'd appreciate the team's guidance on how to proceed and understand your perspective on this matter. Thank you! Best regards Checklist before submitting a bug report [x] I've updated to the latest released version of the SDK [x] I've searched for existing Github issues [x] I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group [x] I've read the Code of Conduct [x] This issue is not security related and can safely be disclosed publicly on GitHub Java version 21.0.8 Android version API 23, Android 11 Android SDK version 36.0.2-14143358 Installation platform & version Gradle 8.7 Package Core & AppEvents