* Result of patchelf v0.9:
E dlopen failed: "/vendor/lib64/libvendor.goodix.hardware.fingerprint@1.0-service.so" loaded phdr 0x70d4cd6000 not in loadable segment
* While searching up this issue, I found a LineageOS Gerrit change (Ibeb09b6ec37ef62b6a5abe40bae1e8bd8d92e7af) with the same error
* Hamsi2k mentioned in the change that patchelf v0.8 is needed to fix the issue
* Building patchelf v0.8 and trying to patch the blobs works
* Implement versioned patchelf logic, allowing the script to both select the default patchelf and a specific patchelf version only for some files
* Leave 0.9 as the default version to not change the default behaviour
Change-Id: I6c0cbe76baf241233fdd125f5ed1eccbd5855124
It doesn't make sense to place a copyright header in
automatically generated makefiles, plus this is a grey
area since we are extracting proprietary OEM files.
Let's be safe and replace the Apache 2.0 header with
a warning regarding manual modification of the makefiles.
Change-Id: I7cafd3f0def33efff96af60280646c44c1ba9a53
No need to force branding down everyone's throat,
most of the other android forks using these scripts are
rebranding the variables anyway.
Let's reduce fragmentation.
Change-Id: Ie9c223d1a42728076f45b40a11cd0820010db8b1
* Move $PATCHELF exporting from oat2dex to setup_vendor
* Since it requires $HOST to be set, let's make it global, so oat2dex can also use it
Change-Id: I4556a3c19cd01c9b3a68d358d19a361217d9c3c1
* This is indeed a nice feature, but it's absolutely a bad idea to
hardcode dependencies of prebuilt modules in proprietary-files.txt.
Change-Id: I8c2d75ff62c0c7862f40e777bcbad4d9cebc074c
* zip stores timestamp for all included files. The timestamps of dex
files are different across different runs, result in inconsistent
checksum of output apk/jar.
* Workaround the issue by using fixed timestamp for dex files.
Change-Id: I21f3a7e32cdfdb07c5f5c140df2e797efd4a8005
This fixes parsing when arguments contain colons, a typical usecase
would be:
-vendor/app/TimeService/TimeService.apk;:timeservice_app_cert
Change-Id: I7500ae09632632ddc10734d9b1df267e28286b67
* COMMON_JAVA_PACKAGE_SUFFIX for jar
* COMMON_ANDROID_PACKAGE_SUFFIX for apk
Change-Id: I812405dac12ef7183985c66a6e43b0ea5f85989c
Signed-off-by: Mohd Faraz <mohd.faraz.abc@gmail.com>
Switch to blueprint on:
- shared objects
- $partiton/etc/ files
- JARs
- executable binaries and scripts
- APKs
Only /sbin binaries are still in Android.mk because blueprint
doesn't handle sbin installation yet
Change-Id: I1dfd7e8bb575367b2a7fa9e333c4c6fa3aa68180
Some devices put stuff on /system, /system/vendor or even
/system/vendor/odm. Search for these paths too when generating
TARGET_COPY_OUT_$partition variables.
Change-Id: Ie2c087e57aaca02d5ea93f290d5fc50d1315a600
With support for 4 independent partitions now, we seriously
need to start putting /system blobs in their own directory.
Add support for file lists with system/ prefixes while
maintaining support for old file lists without it.
Also, TARGET_COPY_OUT_SYSTEM is a thing now, and all devices,
regardless of treble or not, set TARGET_COPY_OUT_$partition
so let's get rid of the treble compat option and default it
to true.
Change-Id: I5b798d293768d7c1e16db3ba01e2de3e083088d7
* ./../../xiaomi/sm6150-common/../../../vendor/lineage/build/tools/extract_utils.sh: line 1: /#!/bin/bash: No such file or directory.
Signed-off-by: PIPIPIG233666 <2212848813@qq.com>
Change-Id: I178f745d4ecb818c38706ff100611df19221065d
* 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>
* 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>
