* 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>
The check for official builds now only affects the case where a prebuilt
kernel was actually used, not the case where a device builds a kernel
from source as normal.
The check has also been turned around so that it only fails the build if
it's actually an official build, not an unofficial one.
Change-Id: I1280b16b90589742c2abe7f3f6f5975a3aaeea03
* TARGET_FORCE_PREBUILT_KERNEL should be useful when you don't have ready kernel sources (OEM releasing broken sources or releasing them lately)
* It lets you use kernel sources for userspace generated headers (generated_kernel_headers) while keeping using prebuilt kernel
* Keep in mind that generated kernel headers may not align with the ABI of kernel you're including
* This commit also partially revert commit a836d79, where TARGET_KERNEL_SOURCE would have been unset if TARGET_PREBUILT_KERNEL was defined (we already check in kernel.mk if kernel sources are present anyway)
Change-Id: I84acae890dabb5b9dbd48143ad58f6420c0cef75
* GCC was deprecated awhile ago, the large majority
of devices should now be using this. Clang should
be opt out as opposed to opt in.
Change-Id: Ie388aff8eca189663f2f615f7d059e47eaf2dce3
For prebuilt kernels, point TARGET_KERNEL_HEADERS_SOURCE to the dummy
kernel source used to generate headers for HALs.
Change-Id: I95a1050a7e0650faac112724b7bd6a300cdb6e4a
Col_or
Nebrassy
bigbiff
captainthrowback
steadfasterX
Mohd Faraz
Sushrut1101
sekaiacg
Tim Schumacher
Sebastiano Barezzi
Alessandro Astone
Alexander Koskovich
me-cafebabe
Alexander Winkowski
Nolen Johnson
XiNGRZ