What did you do for DCL via storage? Did you restrict DCL on all apps and authorize it when the notification requested activation?

    Stewart DCL via storage doesn't currently have a global toggle. DCL via memory does. DCL via storage will have a global toggle too, and in fact it's already been coded but is just hidden pending some changes from Google Play, as DCL via storage would currently break most apps depending on Google Play due to how it uses dynamite modules. They're moving from that to split APKs which will sort that out though.

        matchboxbananasynergy Okay, thanks for the quick reply, so I'll wait for the addition of global failover for DCL via storage, that will be easier. I'm looking forward to the next update.

          DeletedUser88 Browsers need DCL via memory to work from what I can see.

          Stewart How do these problems manifest themselves?

          Which problems? The ones regarding the apps you listed? If so,

          Stewart Bitwarden

          Legacy app requires DCL via memory to function. If you are using the new beta apps, then this is not needed.

          Stewart Google Play Store and Google Services Framework

          These apps require DCL via Storage if I understand correctly to load Dynamite Modules (something Google is planning on depreciating).

          Stewart Oops sorry, I misread what you were saying when I wrote my previous reply. Information still stands though.

          From your list of apps that require DCL via memory to work, I know that WhatsApp works fine without it granted (even though it says WhatsApp tried to use it) but only DCL via storage is required for it to function.

          Anyway, I see conflicting reports regarding Vanadium compatibility with DCL via memory. I wouldn't recommend turning it off though as Vanadium is granted an exception by default. Maybe @matchboxbananasynergy can give some more insight into this.

              DeletedUser88 I did my testing on user profiles because my owner profile is used only to install and push apps to other profiles. On the user profiles there is no universal toggle for DCL via memory, so I just went through and disabled/restricted each app one by one.

              I didn't even know that there was a universal toggle for DCL via memory on the owner profile. But yeah, I can see that there Vanadium is granted it automatically.

                9 days later

                Notesnook
                Appears to Work with everything disabled, although the background sync probably won't as the log seems to indicated that it relies on a third party module that is blocked when disabling DCL via memory.

                I've disabled the following

                • WEBView JIT

                • DCL via memory

                • DCL via Storage

                  8 days later

                  yellow-leaves
                  Okay, I now have some issues with it crashing while running in the background which is annoying.
                  The crashing Doesn't appear to affect the actual usage or functionality in any way though as it never crashes while I'm actively using it.
                  I suppose this probably has something to do with the background sync not able to run as excepted although my notes always sync as reliable as before.

                    13 days later

                    I don't have not many non-stock apps, under 60 I suppose, that are running with full on security settings, only Tor bowser can't work with out DCL via Memory. I'm wondering why a default value of DCL via Storage is different for at least one app than it is for others? Aren't default values system wide properties?

                    22 days later

                    YouTube revanced gives an error when DCL via storage is blocked, but the app seems to function fine.

                    type: storage_DCL
osVersion: google/cheetah/cheetah:15/AP3A.241005.015/2024102100:user/release-keys

package: app.revanced.android.youtube:1545731520

DCL denial type: DexFileOpen
process: app.revanced.android.youtube
thread: pool-4-thread-2

java.lang.SecurityException: DCL via storage, path: /data/user/0/app.revanced.android.youtube/cache/1708042440713.jar, canonicalPath: /data/data/app.revanced.android.youtube/cache/1708042440713.jar
	at android.ext.dcl.DynCodeLoading.checkDexFileOpen(DynCodeLoading.java:132)
	at dalvik.system.DexFile.openDexFileNative(Native Method)
	at dalvik.system.DexFile.openDexFile(DexFile.java:406)
	at dalvik.system.DexFile.<init>(DexFile.java:128)
	at dalvik.system.DexFile.<init>(DexFile.java:101)
	at dalvik.system.DexPathList.loadDexFile(DexPathList.java:438)
	at dalvik.system.DexPathList.makeDexElements(DexPathList.java:397)
	at dalvik.system.DexPathList.<init>(DexPathList.java:166)
	at dalvik.system.BaseDexClassLoader.<init>(BaseDexClassLoader.java:160)
	at dalvik.system.BaseDexClassLoader.<init>(BaseDexClassLoader.java:105)
	at dalvik.system.DexClassLoader.<init>(DexClassLoader.java:55)
	at frz.o(PG:273)
	at frz.q(PG:17)
	at fry.h(PG:15)
	at fry.run(PG:145)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
	at java.lang.Thread.run(Thread.java:1012)