[bugfix] Skip SPL downgrade check on the installing device's update_engine - #5
Open
varakumar01 wants to merge 24 commits into
Open
varakumar01 wants to merge 24 commits into
varakumar01 wants to merge 24 commits into
Conversation
Signed-off-by: minaripenguin <minaripenguin@users.noreply.github.com>
…w header lib This is a combination of 3 commits. This is the 1st commit message: build: add kernel header dependency if module uses kernel headers Many of the QCOM components use kernel headers, but don't declare the dependency on them. This is fine in CAF because of the way they build the boot.img before anything else. In CM, we don't build the boot.img the same, so we run into a race between the kernel build & these modules... and the modules lose. Warn about modules that have this missing dependency, and add it for them so we don't have to modify each Android.mk. Change-Id: I95f1e47b5ef440f6f5d8f64a0c3f38d9572e839e ============================================================================ This is the commit message AxionAOSP#2: build: Switch kernel header inclusion The build is switching to the target INSTALLED_KERNEL_HEADERS to declare dependencies on kernel headers. Change-Id: I913e74681b02dfcf1eaed3d1e47ff4ab2300b12d ============================================================================ This is the commit message AxionAOSP#3: build: Automatically replace old-style kernel header includes with new header lib Since we do this via soong and the result is a header library, just replace all legacy include paths that point to the old header location with calls to the new header library. Since we no longer have the legacy include, we can also remove the additional dependency. This reverts commit fa798218e5b7f96e12ab3acc9d47a3f26a140777. Change-Id: I716955534e50831e6568ca01e480aa8b90075d92
For backwards compatibility Change-Id: I6f90f1be5d57c94bb9ea3ebe4c192d728e88c024 Signed-off-by: Saikrishna1504 <saikrishna26918@gmail.com>
Allow building a76 with TARGET_2ND_ARCH_VARIANT set as armv8-2a Change-Id: I620aa16d6cc563687d35916fc0cd56fb08f9ca71 Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: Saikrishna1504 <saikrishna26918@gmail.com>
Change-Id: I7727f446c9886c033ec4ba7c7b963138ad02f652 Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Change-Id: I42c9ca64b6c4ca5b4e0de576070a699da03860f2
Change-Id: Ic1cd50db6a194193b844773d8972955010cd4894 Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Change-Id: I0ce1d40b28e9063d0fd0f031698853bac803c723
Change-Id: I580da4e6ddd4608209784f3f75cf477386008863 Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Change-Id: I0fe936091fb4b1b5e7e8c824c478fc36774f1f03 Signed-off-by: Alvin Francis <nivlafx@gmail.com> Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Change-Id: I707193a22fe2b4de71b124a51c3d7325108dd448
Change-Id: I68076712bc9e78fd235bf76d584cc10025da57e4
Change-Id: I568a8b83451ea3d20986b188f04c035844545fbd
Change-Id: I53bc7ea3125136c0242254f4f6243b4b9d115200
Change-Id: I5fb497a2470e1e1774ad812b6c9edf9c98342de3
on low ram machines, increasing the job counts to cpu core count can lead to ooms and ninja taking too long due to high swap usage. by reducing the soong and ninja jobs to 8 (helps in reducing swap usage for 16/32gb ram machines), ninja time can be reduce from 12 mins to 2 mins by avoiding swap usage. Change-Id: I44ca10c6bb8f675694915edd265dd631bea99cde Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Change-Id: I9f30e8494c84ce561c151687ae942b08e4064469
Change-Id: Ife832c53de551619d0fe6e2d7d300f7789a70a86
adding support for secondary disks ccache Change-Id: I162143acfdca1d1212ac0891060aaab72aab0ea4
Change-Id: I9dd1b90135e94727f01ff8712e3a346d703743b5
Change-Id: I78f70fb5f8f4d47f82ced72b0657469fb7ac40fd
…ngine Signed-off-by: Varakumar <varakumar7000@gmail.com>
varakumar01
changed the title
Saikrishna1504
force-pushed
the
lineage-23.2
branch
from
September 19, 2026 01:12
b1c882f to
be9d613
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes update_engine potentially rejecting or wiping data on an OTA install because of unreliable SPL/verified-boot props on devices running root/integrity-spoofing tools.
What was wrong:
update_engine compares the OTA's target security patch level against the device's current one, and if root/integrity-spoofing modules (TrickyStore, Play Integrity Fix) have made those props untrustworthy, a completely normal update can read back as a downgrade - getting hard-rejected when
new_spl < current_splandro.boot.verifiedbootstate=green, or forcing a full data wipe whennew_spl < current_splandro.boot.verifiedbootstate=!green, for no real reason. (system/update_engine/payload_consumer/delta_performer.cc:402-439, CheckSPLDowngrade())Fix:
SPL_DOWNGRADE=1 flag skips the check entirely when it's set (
delta_performer.cc:595, parsed into install_plan_.spl_downgrade ataosp/update_attempter_android.cc:321-322), so installs go through normally regardless of what the device's props claim.