With this update, Shizuku seems to crash too often. I mean, the service stops every now and then even after enabling exploit protection compatibility.

I know GrapheneOS would give an f about apps that gives users more control. But still, breaking apps like feels more of a sham.

    I don't know if it's because I'm on a P7 but when I enable "hardened memory allocator" or set "dynamic code loading via storage" to restricted, they both are resettled to disabled and allowed when I re-open their settings menu

    Edit: everything works great, only bitwarden doesn't seem to work with DCL via memory disabled
    Error:

    type: memory_DCL
    osVersion: google/panther/panther:14/AP2A.240805.005/2024083100:user/release-keys
    package: com.x8bit.bitwarden:11086
    
    DCL denial type: DENY_EXECMEM

    Is it safe to restrict DCL via memory for Vanadium and webview jit for PDF viewer? I assume some sites won't work / be slower, but is there any other reason to let them be enabled?

    shizukuuser

    I know GrapheneOS would give an f about apps that gives users more control. But still, breaking apps like feels more of a sham.

    That is simply not true. A new user, with that name, making that comment feels like a trolling attempt. You didn't provide details, you didn't provide logs, so how do you expect us to take a look at what you're reporting?

    The implication that this was done on purpose is ridiculous. If that's what your participation in the community is going to consist of, it won't be productive.

      matchboxbananasynergy nice.

      I created an account on the go to tell the issue that i faced multiple times assuming others who use shizuku "might" be facing this.

      So every time an app tries to access DCL, say WhatsApp, Shizuku service gets affected. I re-enabled it a few mins back. I forgot to get logs previously. Will catch the logs when it stops.

      Also, it is reproducible. Enable the service, wait for some time, it stops.

      The implication that this was done on purpose is ridiculous.

      People are free to make assumptions.

        shizukuuser People are free to make assumptions.

        You could have asked if an issue was intentional. You instead opted to say we're breaking apps on purpose, and that it's a "sham". That's bad faith.

        Regardless, I assume from your explanation that you're using the DCL toggles to restrict DCL for an app, i.e. Whatsapp, and then the issue with Shizuku occurs?

        It might have to do with how Shizuku interfaces with apps to do whatever it is you're doing with it.

        If the new features remain in their default state and aren't used, there should be no difference compared to previous updates, are you able to confirm that?

        Yes, I did block DCL to block by default. Some apps crashes and I selectively enabled DCL to them.
        But since I enabled the service yesterday after it stopped, couldn't see it stopping.

        using the DCL toggles to restrict DCL for an app, i.e. Whatsapp, and then the issue with Shizuku occurs?

        previously, yes. Shizuku would crash every time DCL notification occurred for any other app, say Firefox, WhatsApp, etc., These apps have no relation to Shizuku whatsoever.

        Monitoring the activity of when it crashes at present.

          shizukuuser Maybe it's an other app granted Shizuku permission that causes the crash. I suggest you to report the issue to GOS GitHub and clearly states steps to reproduce.

          One of the most exciting updates for a while.

          YES!

          I restricted DCL via Storage for all my apps except of Brave and have no problems so far. Really waiting on the global toggle. Is there a deprecation ETA?

            So, if I understand correctly, the basic default parameter should probably be

            • webview JIT restricted for all apps except pdf,
            • DCF via memory restricted except Google Play and the browser,
            • DCF via storage restricted except Google Play and the browser.

            Then see which apps encounter problems and decide per app.
            Is that the option you generally chose ?

              For your information, my banking app, BanquePostale, require Dynamic Code Loading via memory. Should I report that on the dedicated PrivSec page ?
              EDIT : the same for banking app BoursoBank.

                Eirikr70 webview JIT restricted for all apps except pdf,
                DCF via memory restricted except Google Play and the browser,
                DCF via storage restricted except Google Play and the browser.

                Then see which apps encounter problems and decide per app.
                Is that the option you generally chose ?

                That's what I'm doing, because I can't see what else to do in my case, its security enhancements seem experimental at this stage but it's cool to be able to use them anyway.

                DCL via storage is what causes the most problems in my case, the list of applications I've authorized is twice as long as with DLC via memory.

                Eirikr70 my banking app, BanquePostale, require Dynamic Code Loading via memory. Should I report that on the dedicated PrivSec page ?

                Yes you can. For my litte story I left them because I couldn't stand their totally crappy app that I was forced to use. I still have an account that I've totally emptied and that they've never closed after several insistent requests on my part but they've done nothing, I've given up and blocked the email address linked to the account so as not to receive any more notifications, it's now just a ghost account and they have no way of contacting me.

                Eirikr70 I've tried DCL via memory with BoursoBank and I haven't had any problems. I have the impression that other parameters come into play or that it's random.

                  doublefree Brave works fine without DCL via storage in my case. Doesn't work wjthout DCL via memory.

                  Eirikr70 Finally, I also have a problem with BoursoBank

                  Is it actually safe to play with various exploit protection settings (including memory tagging) with important to me third party apps that are unknown to be compatible with them? Let's say if an app crashes because of one or few default settings were changed, could that cause the app data corruption in an unfortunate circumstance? I was just looking for an assurance I am not going to do any harm in testing the toggles. Many thanks in advance, and apologies if this question is absolutely not relevant!

                    876fi Any question is relevant, and don't worry, if there's a problem with an application a notification will appear to warn you, and all you have to do is reactivate the DCL concerned just for the application.

                    6 days later

                    Is there any influence on the battery consumption after the DCL implementation? Any experience?

                    I mean after I set them to Disabled for both - via memory and via storage for most of my installed apps, despite the apps working and trying to use DCL (turned off the "Show notification about clocking DCL attempts").

                    Should this constant trying to use the DCL by specific app(s) can be a culprit or not likely?