Required for new commits on frameworks/native
* Fix lag during screen recording on some platforms
* Fix screen flickering after disconnecting from Android Auto on some platforms
Change-Id: Ia0ed0bbfda44fb5ccb184ace854ec1bf9a7d819a
* Note: msmnile is treated like msmnile because unlike other Qualcomm
codenames msmnile does not expand to 8150.
Change-Id: If246c0ec06de22097d369c17ce48aa1270bab19c
* This fixes dirty boot image rebuilding on devices
with CONFIG_LOCALVERSION_AUTO=y and any driver
set to =m.
* Basically appending `cat include/config/kernel.release`
to modules path makes sure that our find does not
return old modules which would make cp fail with
'cp: will not overwrite just-created' message.
Change-Id: Ifb79d33b95d7671d8b2d6633644c8b8290d1f442
* The macros used in the file formerly called "qcom_utils.mk" are
actually generic and not QCOM-specific. Move the QCOM_BOARD definitions
to a QCOM-specific location, and name the remaning macros something more
generic.
Change-Id: I6747bc9201e56b456caf251122057d7dbc233f1c
* There's actually not a whole lot QC-specific about these macros,
make them available at definition.mk inclusion time rather than
relying on BoardConfig to include them.
* Don't create a dependency on QCOM macros from a makefile
that is included very early in the build process.
Change-Id: I3dcaf0e068ca44732cfe58f69384621781ddda67
Currently we handle the DTBO images from start to finish, including
AVB footers, and just drop them in $(PRODUCT_OUT)/dtbo.img when done.
While this works for the most part, we are limited in what we can do
with the DTBO images. For example non-A/B device recovery images must
have a copy of the DTBO image appended to recovery (see AOSP docs:
https://source.android.com/devices/bootloader/recovery-image ). This
means that we need to pass the pre-AVB dtbo image into
BOARD_PREBUILT_DTBOIMAGE in order to let the AOSP build system handle it.
This commit reworks the way the DTBO images are built, placing them at
$(PRODUCT_OUT)/dtbo-pre.img instead and setting BOARD_PREBUILT_DTBOIMAGE
to that path so the AOSP build system can pick the images up and sign
them and append to recovery (for applicable devices).
Change-Id: I8819d7cd92ba298de67dbc7f6b321917ba8524f1
* Call the build system's build-image-kernel-modules function instead of
redefining all of it inline ourselves.
Change-Id: Ifc4bd3c452393389a14174f4cc29a8f7ef064b93
* Check for any actual kernel modules, rather than just the presence of
kernel modules being enabled as a kernel feature.
Change-Id: I6b7e82d5c59dd57621d9f9e2d1fd606997790d1c
* The directories used by the kernel module install rules are performed
as part of the rules in the kernel build itself. This is likely a
leftover from before kernel module install was separated.
Change-Id: Iee2f73a0f8e0f274b1c2931ba57277ff14d7f5cc
* Traditionally, the task of hex-editing blobs has been approached in 2 ways:
(1) Do it out-of-band, commit the modified blob, and record its edited
sha1sum in proprietary-files.txt (aka pin it).
(2) Do it in-band, by adding code to the device-level extract-files.sh
(usually this performs patchelf or sed). This code runs after the
extract_utils functions were invoked.
* Problems of approach (1):
- It relies on verbal (basically commit message) documentation of
the hex-editing that was done. Makes it more difficult to reproduce.
- Each time blobs are updated, pinning needs to be temporarily removed,
hex-editing done again manually and new hash put back.
* Problems of approach (2):
- It is incompatible with the concept of pinning, which is useful
for kanging blobs from another device. A pinned blob would either:
- Match the hash, get hex-edited, then it won't match the hash
next time around.
- Not match the hash (because of, say, hex-editing), then the
extraction script would use an unwanted blob version instead of the
pinned one (either that, or say "!! file not found in source").
* In summary, this patch adds system-wide support for approach (2) in order
to address the aforementioned shortcomings.
* At device level, users of extract_utils who wish to perform blob
fixups can override a blob_fixup() Bash function in their
extract-files.sh immediately after running "source ${HELPER}". The
blob_fixup() function will be called by the common extract() function
after extracting every individual blob, giving the user the
opportunity to hook custom code after this operation takes place.
* In proprietary-files.txt, the line corresponding to this blob which
needs fixups can look in one of 2 ways:
(a) vendor/lib64/vendor.qti.gnss@1.0_vendor.so
Do this if you are taking the blob from the stock ROM. The fixup
script will always run after the blob is extracted.
(b) vendor/lib64/vendor.qti.gnss@1.0_vendor.so|249c76153f8de014bf2dd2ab623ee3d87741fbc8|f7e9ee8e3804887a2f3939128e860767e6f27258
Do this if you are kanging the blob from somebody else. The pinning
logic now applies for both the pre- and the post-fixup hashes. The
fixup script will only run if the blob doesn't match the hex-edited blob,
although the fixup script should really be idempotent.
Change-Id: Ifdd73c885d995c645f6210597537693d1a2f903f
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* This makes sure that multi-word arguments are passed correctly from
extract-files.sh towards the common extract_utils helper. An example
would be extract-files --section "Hello World".
* IMPORTANT: device repositories that use a device/common split
typically do something like this to invoke the common script from the
device one:
${MY_DIR}/../common/extract-files.sh $@
This is incorrect because the quotation marks are missing, and will
lead to incorrect parameter parsing. The correct way is:
${MY_DIR}/../common/extract-files.sh "$@"
* The curly braces are only for cosmetic consistency.
Change-Id: Idf0885546379f47e675ec5e9dfb304706e512129
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* The use case is easier updating of pinned blobs. When --kang is set,
pinning is automatically ignored, and the script will print lines at
its output that can be directly copied back into the
proprietary-files.txt.
* Best served together with --section ${SECTION}, and proper grouping
of the proprietary-files.txt.
Change-Id: I648fbcbd4580a4a002b00828bcfee18d1e265d7b
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* This also makes the --section argument non-positional, since otherwise
it is not possible to easily support more than one optional positional
argument. This is in preparation of one more optional argument to come
in a follow-up patch: --kang.
Change-Id: Ieb142e0854319defb9a278ab68cd4aeefd0fbdd5
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* The use case is that if you have the following layout:
$TOP --- system.img
|
+-- vendor.img
you should be able (from $TOP) to:
mkdir system; mount -o ro,loop system.img system
mkdir vendor; mount -o ro,loop vendor.img vendor
and then (from device tree)
./extract-files.sh $TOP
But this doesn't work if system.img is SAR and contains another
"system" dir inside. This patch makes sure it searches for a "system"
dir in the provided path as well, if it couldn't find the blob
anywhere else.
Change-Id: Ib49cd5b587b3a57478a66ff69cf840270c2b1403
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* This makes the printed output closer to the proprietary-files.txt syntax
Change-Id: I81b844bb6bb1d1a2f91a39151a892fbfc0bed20b
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* If an apk/jar doesn't exist, the script would still try to deodex it.
* If an xml doesn't exist, the script would still try to "fix" it.
* Take it easier, man, it's not your fault.
Change-Id: I3061fb48b403da5121e3c17dd9ecdb6cd148bf97
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Google added support for LTO + CFI in the Pixel 3 kernel, which requires
not only Clang but a couple of additional binaries, namely llvm-ar and
llvm-dis for IR generation. Google expects these binaries to be in PATH
according to their definitions and the build.config.common file:
https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common
However, kernel.mk does not add the LLVM bin directory to PATH so the
build fails because the binaries can't be found. We could add LLVM_AR
and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however,
adding the bin directory to PATH is a more sustainable solution as
Google might require new binaries in the future.
Additionally, LTO needs access to the LLVMgold library so it needs to be
available in LD_LIBRARY_PATH.
Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH
with the bin and lib64 folders from the requested LLVM toolchain
respectively when building with Clang. This won't affect kernels that
don't use LTO like Wahoo.
Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
*) This has been deprecated by the bp mobule
generated_kernel_headers.
*) To build with kernel headers, do this:
LOCAL_HEADER_LIBRARIES += generated_kernel_headers
Or for soong targets:
header_libs: [ "generated_kernel_headers" ],
Change-Id: Idad445709f0ee0ec11b41b40123b14976a0052ad
*) Similar to genrule but can be used to generate content
when the output directory and file structure are not
known ahead of time.
*) An example use case is to build kernel headers.
Change-Id: I10deb7ba8825393b0b5fdbf2d96b12ad37257e12
jhenrique09
Rashed Abdel-Tawab
LuK1337
Isaac Chen
Ethan Chen
Erfan Abdi
Luca Weiss
Thor Lee
Vladimir Oltean
Alessandro Astone
Luca Stefani
Michael Bestas
AnilKumar Chimata
Bruno Martins
Tim Schumacher
Nathan Chancellor
Sam Mortimer