Hi all, while testing the current version of SimpleX on Pixel 8, a crash occurs right after entering the app.
Who wants to discuss this and those who have experienced a similar problem I would be very grateful for your comments.

type: memory_DCL
osVersion: google/shiba/shiba:14/AP2A.240805.005/2024083100:user/release-keys
package: chat.simplex.app:235

DCL denial type: DENY_EXECMEM
type: storage_DCL
osVersion: google/shiba/shiba:14/AP2A.240805.005/2024083100:user/release-keys
package: chat.simplex.app:235

DCL denial type: DENY_EXECUTE_APP_DATA_FILE
thread: ghc_worker
targetPath: /data/data/chat.simplex.app/cache/#64051 (deleted)
    2 months later

    Can anyone confirm if this issue still exists? I turned off DCL via Memory and DCL via Storage for SimpleX, which previously always resulted in a crash, but it is not crashing anymore.

    Edit: nevermind, DCL via Storage crash occurred again.

    4 months later

    doesn't seem to be resolved yet. crashes in couple seconds.

    • de0u replied to this.

      Onlyfun doesn't seem to be resolved yet.

      That would be consistent with the issue that @other8026 provided the link to.

      I believe the situation could be summarized as:

      1. The app behaves in a fashion that regular Android is ok with at present, though regular Android might ban the behavior in the future,
      2. The app behaves in a fashion that GrapheneOS bans by default,
      3. GrapheneOS provides a toggle so that individual users can allow the behavior for that app if they wish.
      4. The GrapheneOS project isn't planning to make changes in response to the situation (SimpleX users on GrapheneOS have a workaround, and the SimpleX developers have a description of the issue).

      People using SimpleX on GrapheneOS might want to allow DCL via storage via the toggle, and might also want to check back on the linked SimpleX issue every few months to find out if it's safe to switch the toggle back.

          de0u It's worth noting blocking dynamic code loading is opt-in for user installed apps. People are choosing to enable it. When users enable blocking it by default, we also have automatic exceptions for apps using Google Play services until they move away from the old style dynamite modules requiring it. People can still opt-in to disabling it for those apps.

              GrapheneOS It's worth noting blocking dynamic code loading is opt-in for user installed apps. People are choosing to enable it.

              Thanks for the clarification! I just turned on blocking to see what it might turn up.

                  de0u You can also see that it doesn't turn on the DCL via Storage blocking for apps depending on Google Play services without manually doing it for each of those. It will work for some of those but not others, depending on if they use any dynamite modules not yet converted to split APKs. Our plan is to remove that automatic exception once Google phases out the older approach but that might take years.

                      de0u thank you for clarification.
                      I assume gos implemented DCL blocking for a good reason. for me having to use a 'pixel' device is a major price to pay for ability to use gos. and breaking gos safety with some messenger acting in a malicious manner is nonsense imo.
                      i'll rather keep it disabled and check if the issue is fixed from time to time per your advice.

                          Onlyfun breaking gos safety with some messenger acting in a malicious manner is nonsense imo.

                          Malicious? Based on what SimpleX's lead developer said in this comment, it sounds like they're doing it this way to keep the apk small. He said:

                          We might be able to stop using DCL at the cost of increasing the downloadable app size to ~200mb.

                          I'm not sure what they're loading, or how they're verifying the integrity of what the app is downloading. Regardless, I don't think the word "malicious" is warranted here.

                            GrapheneOS depending on if they use any dynamite modules not yet converted to split APKs. Our plan is to remove that automatic exception once Google phases out the older approach but that might take years

                            I know Chrome uses isolated splits (aab). I haven't been paying attention, but what's the new approach? And is Chrome/Chromium/Vanadium using those already?