Is there a way to disable/opt-out of app optimization?

The optimizations heat my phone up, consume resources and takes a long time.

It also makes my app installs very slow, for me this is a big issue since I can't bulk update apps without the phone heating and slowing to a crawl.

From what I understand, Graphene chooses not use JIT and instead compiles once due to privacy concerns, but it's not the best user experience for me and is my number one gripe with the OS.

Any chance this can be opt-in?

    fizzics

    Hm.

    I wonder if there is a problem happening under the hood.

    What model pixel are you using? How many apps do you have? And how do you install/update apps?

    I'm on a Pixel 8. I have uh... less than 100 apps. Most are downloaded and installed via Obtanium.

    My app optimization after each OS update takes only a few minutes and doesn't heat my phone up at all, even when Itcs optimizing and charging at the same time, and I've got the sucker in an Otterbox Defender.

        fizzics 9 Pro XL here. More than 90 apps that need to be optimized, I have barely any heating at all. Are you doing something intensive in the meantime? Your issue definitely doesn't sound normal.

          Pixel 7 pro. Zero issues here. Does take a while but I use my phone like normal during it so there's no issue. 80 apps installed

          There isn't seeing as "Optimizing apps" is part of the update process...

          Pixel 9 pro here, while i had a spigen liquid air the phone got a little hot while optimizing apps, while i now have a aramid fiber case and doesn't get hot at all.

          It seems aramid fiber is more thermal conductive than rubber (spigen liquid air).

          Maybe case has a little impact in this aswell? Rubber seems to have very very low thermal conductive properties and tends to 'trap' the heat.

          The biggest issue for me is that app installs are substantially slower which makes it impossible to batch update apps.

          When I update/install any apps, it takes substantially longer since the OS compiles everything.

          Just wish this could be opt-in instead.

          a month later

          +1 (in fact, +100) for making this opt-out. As much as I love graphene, this is the single one most annoying feature. I understand why it's there, and I'm fine with it being on by default, but PLEASE make this an opt-out feature.

          I have a Pixel 6a with some 150 apps, and on every OS update booting takes around 5 to 10 minutes, followed by another 2 to 3 hours(!) of optimizing apps in the background, heating up the phone and draining its battery. Only to be re-optimized 5 days later after the next OS update.

          • de0u replied to this.

            I'd reboot a lot quicker, if the optimization itself could be postponed. Instead, I'm postponing the whole upgrade for usually 1-3 days. Can't do it at night because I have a SIM PIN. Then I can't do it during work or outside of home, because it takes too much time and drains too much battery.

            To be honest, when I first started using GrapheneOS, I was a little annoyed by the app optimization process. Then I read about it, and I was convinced because it increased security. And from then on I just ignored it. After an update, my phone just does all the optimization and I can still use everything as normal. And at some point I just restart all the apps and it's done. Yes, it uses a little battery, but my P6a still has enough for a whole day. Does it get warm? Maybe, but using the phone as a hotspot is much worse.

            I am grateful that GrapheneOS makes no compromises when it comes to security. This way I can just trust the developers and know that they won't change security improvements just because someone was annoyed by them. This is great and I am grateful for the OS every day. Do I love every single thing about it? No, but I have never had a ROM where I liked everything. And overall I love GrapheneOS because it just works, the developers are doing a great job with all the updates, fixing bugs really fast and explaining things a lot (just look the awesome documentation - the best in the Android world!) And I'm grateful for that and I don't really care if sometimes some little things try to drive me crazy. We get the best phone for privacy and security and that's what matters, imho.

            johnnydoe2 I have a Pixel 6a with some 150 apps, and on every OS update booting takes around 5 to 10 minutes, followed by another 2 to 3 hours(!) of optimizing apps in the background, heating up the phone and draining its battery. Only to be re-optimized 5 days later after the next OS update.

            That's a lot of recompilation!

            In terms of possible amelioration, I'm curious... what fraction of those 150 apps are typically run between two updates?

                de0u Well that's the thing - I use about 5 apps intensively, and maybe two dozen regularly. The rest is mostly sporadically used (but not entirely useless, just used in varying circumstances e.g. holidays, navigation, banking, 2FA for various customers, a few casual games, etc., so I don't delete them). So a rough estimate is that maybe 10-15% of these apps are actually being used between the regular optimizations, the rest is just getting re-optimized on every single update without even having been actively used in between. :)

                    johnnydoe2 perhaps you should split your apps into profiles by regularity of usage, thus greatly improving your convenience in regular use. Also re: OP

                        DeletedUser69 I did give different profiles a try, and I actually find that to be very inconvenient, so I gave up on it. Switching profiles every time I want/need to do something in a different context is not an option for me. I simply have the apps organized in different tabs in the launcher, that's enough for me to keep the "complexity" in check without compromising on usability. Plus, I'm not sure if that'd really help with the issue at hand.

                        But anyway: is there a strong reason for NOT making the optimization an opt-out feature?

                            johnnydoe2 simplify your setup Mr Johnny Doe, life may be complicated but it doesn't have to be if you only try. Some apps have alternatives on the web (webapp) and that doesn't need precompiling. But if you rely on notifications for everything I suppose there is no hope for Johnny. Don't try to squeeze your whole life in a rectangular box that you can hold in your hand, seriously. Note: I don't mean to belittle you but you need to make an informed decision here.

                              johnnydoe2 Is there a strong reason for NOT making the optimization an opt-out feature?

                              In theory, like anything else, it's a simple matter of writing the code. But the code probably isn't all that simple, and then it must be tested. Should the AOT toggle default to off or on? If it's on and the user turns it off, should the already-compiled apps have the binaries deleted? What if the toggle is turned off while AOT compilation is in progress? Should the user be warned when the toggle is flipped off? Should the setting be global or per-profile? I suspect it needs to be global, but if it's deployed that way probably people will complain.

                              It would of course be possible to address those questions, and others, and to implement something, and test it. But how should that be prioritized compared to other things users have asked for, and things the developers know are issues that users haven't yet asked for?

                              So there may not be a strong reason to not implement the feature, but that's probably not enough. It's probably necessary for there to be a strong reason to implement it. It's not as if features implement themselves automatically and the only question is which ones to reject instead of deploying.

                              Please note that I don't speak for the GrapheneOS project.

                                Well, as far as I understand, AOT optimization is something that GrapheneOS deliberately added, so in fact disabling it (I mean flipping that hypothetical toggle that a few people, including me, would like to have, I'm not talking about completely removing the functionality) would simply revert back to the default Android behavior, in other words, disable a (then) optional feature.

                                The arguments for why this is desirable for some users have been put forward by multiple people here, I'm only one of those, and I still happen to find that "optimization" counterproductive.