On some devices we might want to build just the *.dtb files
that we actually need instead of the every dtb that exists.
Change-Id: Id7a152499d4ee1dd08f79d34cc34bfe959313515
gs101 uses DTBO_OBJ/arch/arm64/boot/dts/google/dtbo.img
vs DTBO_OBJ/arch/arm/boot/dtbo.img on previous devices.
Change-Id: I945d31cb093fae97385cf84c273088ee7a4edf0b
Avoids:
$ lunch lineage_sdk_phone_x86
grep: build/make/target/board/emulator_x86/Makefile: No such file or directory (x4)
Change-Id: Ie803d5ca93e6e7ae94625e7ee3ab0bf337e0515d
* Currently, because DTC_EXT make flag is in the
kernel task the only way to override it is to
have TARGET_KERNEL_ADDITIONAL_FLAGS come after.
Change-Id: If62ed979581dc07eafd4628ce2b2d799388d3704
This reverts commit caa3bddf00129c06f35923e43d5e770645da6b99.
Reason for revert: Breaks pixel dtbo.img build, since kernel depends on
mkdtimg. Add it back so it gets compiled and kernel can pick it up.
Change-Id: I2b9fd0b2b35e0cf2f908516b10f65399780d5c30
* AOSP build system is not aware of dtb(o) source update, and thus
won't rebuild the images, results in outdated artifact.
* Convert DTB(O)_OUT to make targets and make the images depend on them
to address the issue. This makes AOSP build system be aware of
their timestamp changes and re-execute recipes depending on them.
Finally, it's up to kernel's build system to decide actions to take.
Test: m dtb(o)image and observe dtb(o).img get rebuilt
Change-Id: I197e7d2d3e013ded0e555fc22bb6a1200d40df9c
Commit 8ac7d31 introduced this issue.
Test: run `m recoveryimage` and verify that recovery
image is now built.
Change-Id: Iffdd8112db2ba1baff28db7ee4c340dbb5ebd917
Commit 8ac7d31 introduced this issue.
Test: run `m installclean && m bootimage` and observe that
kernel image is built.
Change-Id: I41eb7cd2e5108bae8f4c40c0f9a300a8a3cc95a7
* Since some time you can specify multiple configs when you prepare .config and they'll get merged to main one
* To use it inline:
TARGET_KERNEL_CONFIG := main_defconfig fragment1.config fragment2.config ...
* TARGET_KERNEL_ADDITIONAL_CONFIG has been nuked since it's superseed by this new logic
* kernelsavedefconfig will only use the base defconfig
Change-Id: I479c762a9235ed0ef6fcdc79b53e084d5e2d78a6
After the "Avoid multiple definitions of sigaction." change in bionic,
we ought to modify our kernel headers to make sure that sigaction struct
is not present in uapi headers.
Change-Id: I15645480e013e79cbcafaac99253368b646b6b11
* If the cflags doesn't have value, it may lead to an incomplete display.
Test:
Before fixed: I:Scaling theme width 0.981481x and height 1.169271x, offsets x: 0 y: 107 w: 0 h: -107
After fixed: I:Scaling theme width 1.000000x and height 1.194271x, offsets x: 0 y: 107 w: 0 h: -107
Change-Id: I267290748f2896662696c781a83e141b771e3e2e
Signed-off-by: Col_or <color597@outlook.com>
In build systems where OUT_DIR_COMMON_BASE is used,
TOP cannot be identified if the directory is changed.
Exporting TOP when envsetup is run ensures that it
will always be set and croot will work as expected.
Change-Id: I6944ac7d3513ba9504e03baa5f9910bddb126d7c
my (loooong) debugging sessions reg my decryption issues on FBEv2 revealed the following:
the issue occurs in [fscrypt.cpp](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=334-353) - actually by this condition: [here](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=337)
so what happens?
1. `ioctl(fd, FS_IOC_GET_ENCRYPTION_POLICY, &policy);` actually gives: `-1` with `errno=17` (i.e. "Invalid argument")!
2. Due to that it will return `EINVAL` which is WRONG as this is the expected errno when a FBE v2 policy has been found! Which is **NOT** the case as the ioctl fails with "invalid argument" instead. This alone is (at least) a design bug as it should be catched and handled differently.
3. anyways due to 2. we now assume it is encrypted (with FBE v2) - see: [fscrypt.cpp](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=130)
4. the next design (ihmo) bug is that **REGARDLESS** of the fact if the directory is encrypted (or not) it checks if it can set a policy on it. IMHO this should be done ONLY when an encryption has been found.
5. setting the (constructed) policy on a *non-empty* AND *encrypted directory* [will fail](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=340) because the dir is non-empty AND encrypted AND the ioctl to **SET** the policy fails (likely due to the same issue as in 1.)
6. as a result TWRP decryption fails (due to the `break` [here](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=340-342))
so what is the bug here actually?
- Is it that the policy TWRP is trying to set (bc of maybe wrong options by me somewhere) is simply different then what Android is setting? I tested and tried a lot to compare the contents of `kern_policy` and `policy` without meaningful success (I am NOT a cpp pro!)
- Is the code in fscrypt.cpp simply useless (for TWRP)? I mean from my point it makes zero sense to add a policy on a directory which is encrypted already (for TWRP). imho it should be even **avoided (!)** as if it would not abort there it means the policy might be changed(!) and that can break Android. imho TWRP should not even try to do that but instead skip the whole part - but that means forking the fscrypt code (dunno if that is smth the devs want to do)
I mean even the comment in fscrypt.cpp states:
> FS_IOC_SET_ENCRYPTION_POLICY will set the policy if the directory is
> unencrypted; otherwise it will verify that the existing policy matches.
which is NOT the (full) truth. it will NOT "otherwise" verify but fail instead - in that specific scenario I encounter here (failing ioctl with invalid argument).
so [this condition](https://cs.android.com/android/platform/superproject/+/android-12.1.0_r27:system/extras/libfscrypt/fscrypt.cpp;l=355) now simply checks for the encryption state, too and all problems (I had) are solved.
I had added debug outputs everywhere (including the kernel) and all leads to the prob "Invalid argument" when the kernel is doin the mentioned ioctl on `FS_IOC_GET_ENCRYPTION_POLICY`.
The reason behind **why** that fails is still nothing I can tell. likely I miss smth in the kernel or kernel config.
ofc the secondary issue with `FS_IOC_SET_ENCRYPTION_POLICY` still could happen due to misconfigured policy options - but that does not explain why the `FS_IOC_GET_ENCRYPTION_POLICY` fails as that one should at least give the current policy (bc it **IS** encrypted). IMHO both GET and SET are related and a general issue within (likely) the kernel.
[FS_IOC_GET_ENCRYPTION_POLICY source/info](https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#fs-ioc-get-encryption-policy).
so as I do not have any further ideas I patch fscrypt.cpp with vendorsetup.sh on-the-fly (yea dirty as.. ) and get at least a working result.
Change-Id: I59eca3413e75712af3e23b195cd32b96704c0a93
Signed-off-by: Mohd Faraz <androiabledroid@gmail.com>
* Some Devices that do not support hotbooting an image using fastboot
boot (eg: mtk devices) face issues like battery level detection,
unable to reboot to system, etc.
When twrpfastboot is set to 1 in the kernel cmdline. Setting this flag
to true will not add twrpfastboot=1 in the cmdline and therefore will
fix those issues.
* Tested on evergo, fixed battery level detection, reboot to system and
slot changing.
Change-Id: I3f2d0fb3ef71f42904f756b4c7dec1cc51905f40
Signed-off-by: Sushrut1101 <guptasushrut@gmail.com>
Michael Bestas
Jason Wojcik
Chirayu Desai
Alexander Koskovich
dianlujitao
Bruno Martins
Sebastiano Barezzi
marcost2
LuK1337
bigbiff
Arian
Nebrassy
Col_or
captainthrowback
steadfasterX
Mohd Faraz
Sushrut1101
sekaiacg