I have a sneaking suspicion that the length of some device command lines is
causing boot issues.
eg. with the recent additions, klte boots fine, but recovery doesn't, maybe
bootloader is adding more flags, exceeding a limit?
Signed-off-by: Tad <tad@spotco.us>
- disable disablement of PROC_PAGE_MONITOR to fix memory stats calculation
- enable slub_nomerge, similar to slab_nomerge for pre 3.18 kernels
slub_nomerge was already default enabled on many 3.10 devices via:
0006-AndroidHardening-Kernel_Hardening/3.10/0010.patch
Signed-off-by: Tad <tad@spotco.us>
- Include TalkBack
- Fixup hosts inclusion, due to path mismatch
- 14.1: bump patch level to match the picked ASB
- 14.1: m7-common: deblobber fix
Signed-off-by: Tad <tad@spotco.us>
- Remove some changes that have been commented for a while
- Don't remove the QCOM VR repos
- Adjust the default quick tiles
- Don't force hardware layers for recents
- Only generate deltas for update_engine devices
- Cherrypick: Update WebView to 90.0.4430.66
- Adjust yylloc sed line
- Add comments to 17.1 devices explaining why they aren't removed for 18.1 yet
PRODUCT_OTA_PUBLIC_KEYS is meant to be set by a vendor tree, something
we don't use.
Override it at the source and set it explicitely as well.
This ensures that the compiled recovery.img and the one generated by
sign_target_files_apks.py includes the real public keys for verification.
11.0 signing is ignored.
This will need to be extensively tested as breakage can mean brick on locked
devices.
Although in failure cases it seems test-keys are accepted.
--
After much testing there appears to be a deeper issue with how keys
are inserted into the recovery and handled
- 18.1: disable m8, thermanager is not yet ready
- 17.1: drop cheeseburger/dumpling, it is absolutely broken
- deblobber: remove euicc + others
- deblobber: hack to remove vintf fragments
