Related
Hi,
I am new to the android development and a bit confused from all this (root, no root etc).
Say I want to write a new kernel driver to handle keyboard input, and want it to run only on my phone. And my phone is not the developer phone, nor exploitable for root privilege escalation.
Can I download the source files and compile a new kernel with my driver? I guess I cannot use the Android sources, but need my phone specific branch. e.g if I own an HTC Hero I need to get the specific sources from HTC, and they don't publish kernel sources for all their models...
But if I found the source, add my sources and compiled it, It should be easy (and legit ) to load the new image to the consumer phone right ?
Thanks
Roee
More or less that is correct. The source code will contain the license terms, if it says GPL then you are golden. If you get the source from a questionable route and it's not necessarily "public" then it goes into a gray area. Generically speaking, if you get the Android source, and the source code for your keyboard, build an image with it, flash it to your phone, then you are perfectly fine. If you choose to redistribute that code that you mashed together, it's arguable you'd then also have to publish your mashed up code or at the very least the 2 sources you used to mash it together. Mash is the best word I can think of right now
-Chad
Thanks for the reply Chad.
If the software is GPL, and I don't intend to publish the code, I just want to play and check couple of things.
I wonder if i can only compile a new keyboard driver (for example), and just load the ko file somehow without flushing the whole kernel.
I don't have much experience in the linux world, but I would guess it will be something like :
get the branch from the android git
compile a new kernel object for the keyboard
use adb to load the ko file to the device
insmod the new device
somehow remove the current keyboard device and map a new device with the new kernel driver
is this the correct flow ? is there example of how to do it somewhere ?
Cheers
Roee
Ok, I think I have a little better understanding after I played with my G1 today...
So now I understand how to enumerate all the devices in the system, and find the proper devices (e.g using cat /proc/bus/input/devices , or in /devices/virtual/input/ ), but I fail to understand how to replace the proper lkm module. When I run lsmod, the only module loaded is the Wlan module.
How can I find which file is responsible for the keyboard and replace it with my driver? Or must I recompile the whole kernel in order to replace the driver with my modified driver?
I guess it became an easy linux questions.... (just not easy for me )
Hi All,
Could some of developers who managed to successfully build CM 5.02 (or any 5.x) kernel from the source help me out with this?
* I checked out the Android 2.x kernel with repo
* Set the proper environment variables
* Checked out Cyanogen's source from github
* Set buildspec.mk and extracted proprietary files
* Copied config.gz from phone to .config
* Executed /build/envsetup.sh
make runs for good 10+ minutes and compiles tons of files, but it stops with this error:
make: *** No rule to make target `vendor/htc/common-open/akmd/proprietary/akmd', needed by `out/target/product/passion/system/bin/akmd'. Stop.
Click to expand...
Click to collapse
What am I doing wrong?
Did I forget to fetch or configure something?
Many thx!
Also, maybe I am asking for too much - but it would be really great if someone who already did complete and sucessful build could write a small wiki (or forum?) tutorial how to build Nexus One Cyanogen ROM from scratch starting from empty Linux setup - it would really help lots of people as right now there are several documents with some of them outdated.
update - looks like something went wrong with fetching proprietary files. I re-done it and it is now compiling for more than 30 minutes...
I hope it will complete successfully this time
Ivan Dimkovic said:
update - looks like something went wrong with fetching proprietary files. I re-done it and it is now compiling for more than 30 minutes...
I hope it will complete successfully this time
Click to expand...
Click to collapse
i posted basic instructions on building cm5-source in cm-wiki.
i'm not sure what you plan to do, compile the whole rom (as thats what you do) or just a kernel (sounds like what you want) ?
It succeeded this time!
It looks like something was indeed wrong when I pulled the files from the phone first time. So the wiki info is good
I would like to compile everything actually and to play a bit with compiler options / configurations and also test the undervolting a bit more (lower voltages - for this kernel build is sufficient)
Well hello everyone.
I am an application development student from Belgium.
I am proficient in Java, VB.NET, some c/c++ and also PHP/JS/HTML/CSS
Anyways, my recent interest has been going out to creating custom roms for the galaxy S!
The problem now is though, I was able to find some guides and such, but most were incomplete, and for HTC(and other) devices.
I have no idea what is different between making a ROM for galaxy S or a ROM for an HTC device.
If anyone would like to link me to some good resources that can help me on my way, or would like to collaborate (and in the meanwhile teach me a bit) I would be more than happy! (I am open for collaboration as I am pretty proficient in Java and I'm always happy to code and learn more about coding!)
I think the question is really want you want to do!
Custom ROMs for Android are as simple as using recovery console to replace files on the system with your own versions.
ie. Replace the framework.apk which contains all theme images with your own modified one, which you can use to skin the device. Same for replacing other system apps.
Unfortunately, most of these apps are closed source, so modifying them is difficult. The stock android system has open source versions of most of them though, and you can modify those and build them, and then replace the ones on the device. I'm not entirely sure how to build them up though, but it probably isn't too hard.
Then there are custom kernels, which let you actually change the underlying linux system underneath android - Samsung has an open source version of the kernel available that you can compile, and then flash to your phone using Odin or other tools. Compiling the kernel is pretty tricky though.
Well i'm really talking about stuff like SamSet, MoDaCo, Doc's ROM and others.
I'm not saying I want to create a pro ROM in a day or anything, but i'd really love to learn more to get better (always looking for more stuff to put on the resume, I guess?!)
Thanks a lot,
Kenny
Bump for some help
(sorry for the double post but i'm really eager to learn)
I don't have time to give a detailed response right now. However you will want to read up on yaffs (file system) and odexing/deodexing ROMs.
Thank you I will definately do that,
I am following a guide now to start out creating custom ROMs for android, however it was written for Motorola Droid and I have no idea what you have to do different for a samsung galaxy s.
I am a good coder, even though I say so myself, with a lot of experience. I also have a lot of linux experience, you name it
Only the problem is the old, and much known "where do I get started?"
So if anyone can point me out in the right direction on that, tell me how/where you started out, I would appreciate it greatly!
Thanks!
Very sorry to bump again
I set up my environment in ubuntu today to get started (just gotta fix a few errors, didn't know android wouldn't compile on java 1.6, only on 1.5)
Anyways, still need some help here! thanks!
Again I am awefully sorry for the bump here but i'd really like some help.
Note that i'm not a newbie at coding whatsoever and i'm not unfamiliar with some hardcore java, c/c++ and other languages, I'm just having trouble getting started when it comes to modding an existing android release (there are tutorials on HTC and other devices but some methods do not apply to the galaxy S)
If you're trying to create a ROM from scratch then unfortunately you're out of luck at the moment. No one has really managed to do so yet. By "from scratch" I mean the Android Open Source Project (i.e. official Android git repository).
What you can do is grab an existing firmware. Extract the contents, de-odex the apks, modify them or add new apks, optionally you can also compile a custom SGS kernel using Samsung's kernel source. Then you can re-odex the ROM, pack it back up and distribute it.
There's no real "starting place" as such and you won't yet find any tutorials about how to create SGS ROMs. Just give it a go and see where you get.
Yes, I do mean creating a ROM from stock samsung firmware, of course.
So my next logical question would be now:
How do I go over extracting contents from the existing samsung firmware, de-odexing and so on?
Any links/guides/tips are greatly appreciated, as long as they are applicable to this cell phone and not totally crap, thanks!
Samsung uses rfs, I think you should know. There is a thread somewhere in this forum regarding extracting .rfs file. Understood you need Debian though.
For some readup, go search for a famous guy named JesusFreke. Tons of materials...
Hope that from here onwards, this can lead you on, and to find out more. Google is your friend too...
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Raykoid666 said:
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Click to expand...
Click to collapse
Agreed completely! Getting a full cross-compilation to Samsung's Android going is seriously difficult! There have been some promises for tutorials and guides for setting things up though, but none have appeared yet. Probably because it's hard!
Well thank you for agreeing with me on that.
I am really hoping for anyone that can help me out here, either on here or in private, and give some detailed instructions on how to get started.
Hell there is enough information on creating roms alread, deodexing, adding/removing apps etc etc etc... The real problem lies in setting everything up properly.
I think I have gotten to the point where I'm compiling the android source (without samsung specific files)
note i'm saying "i think i am compiling" because i'm hoping it won't error out on me again after an hour of compiling!
But once that is done... I have no idea where to go next, where to get the samsung specific files, or what to do with them whatsoever once i have them
thanks!
Android generic source won't actually help you much. Samsung has made a huge number of changes to it, and while it is all open source, backporting their changes to get your stock source running on the phone is a major undertaking. I believe cyanogenmod was actually working on this, but it seems without much success so far.
What the other rom makers you see are doing is taking a snapshot of a running rom, copying over all of the APKs and the files on a running device, and then tweaking those. ie. Opening up framework-res.apk and changing the image files inside.
The update.zip roms that are what most people are doing are really just using the Android recovery to replace files on the phone with their own versions. Since the underlying system is linux, and everything is a file, this actually works pretty well.
The kernel development effort is completely separate from the rest of the system though, and Samsung has provided the entire source tree that just has to be compiled. I'm a bit stumped myself on all the details of setting it up, but I have seen some threads on this forum about it, and it didn't seem too bad to set up. Apparently you shouldn't use the codesourcery toolchain though, or something. Not too clued up on it, sorry. Hopefully someone with the details can chime in, or give us a link to the old post on it (I'm failing to find it using the search function! )
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Raykoid666 said:
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Click to expand...
Click to collapse
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
RyanZA said:
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
Click to expand...
Click to collapse
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Tayutama said:
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Click to expand...
Click to collapse
Haha cool, didn't know you could pull whole folders!
Raykoid666 said:
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Click to expand...
Click to collapse
The apk files in Android are odexed - that means they have a special index applied for dalvik that speeds them up somehow! I don't know how, I haven't checked how it actually works.
The important point is though:
odexed is faster, but you can't edit it because of signatures or something technical
deodexed means you can change it however you want
More useful info can be found from google - lots of it!
update.zip is easy - it's a zip file in a special format that can be understood by Android's recovery console. The easiest way to do it is to grab an existing update.zip and modify it as needed. Tayutama has millions of em around, so use his!
Then you need to sign it once you're finished with it so that the SGS will accept it. Samsung made a boo-boo and didn't disable the test keys for the 2.1 SGS firmwares. That makes it easy!
http://www.londatiga.net/it/how-to-sign-apk-zip-files/
Just use the test keys to sign it, and then copy it to /sdcard/update.zip and reboot into recovery and it'll work.
Chainfire kindly created a small app that verified and displayed the firmware revision number - 0x19 being the fatal version. Almost all of our GN's have this firmware revision and basically this means that all of our Gn's can be bricked. For the moment we do not have the possibility of upgrading the firmware so we are stuck with this as a "feature".
However it be interesting to know if the currently installed kernel possesed MMC_CAP_ERASE functionality or not, since it is the Kernel that "intitiates" the bricking process.
Does anyone know if it would be possible to create such an app ?
I can imagine the scenario where one day a kernel is released which has MMC_CAP_ERASE functionality active but that the kernel is annonced as having it inactive or vice versa.
It would also allow us to know when the official kernels will have this functionality removed.
Unfortunately I do not have experience/knowledge necassary to write such an app.
Roy_W said:
Chainfire kindly created a small app that verified and displayed the firmware revision number - 0x19 being the fatal version. Almost all of our GN's have this firmware revision and basically this means that all of our Gn's can be bricked. For the moment we do not have the possibility of upgrading the firmware so we are stuck with this as a "feature".
However it be interesting to know if the currently installed kernel possesed MMC_CAP_ERASE functionality or not, since it is the Kernel that "intitiates" the bricking process.
Does anyone know if it would be possible to create such an app ?
I can imagine the scenario where one day a kernel is released which has MMC_CAP_ERASE functionality active but that the kernel is annonced as having it inactive or vice versa.
It would also allow us to know when the official kernels will have this functionality removed.
Unfortunately I do not have experience/knowledge necassary to write such an app.
Click to expand...
Click to collapse
Not an Android developer, but my educated guess is that it will be improbable, if not impossible, to build such an App. As I understand it, this property is embedded in some .c code of a Kernel, so not possible to read it via an App. If this property is stored in some config file which Kernel reads/uses then possibly an App can be written to read the same config file. As I said, not a dev in this field.
Good idea! Not an expert in the field either, but I believe some kernels have their settings available at /proc/config or /proc/config.gz, but that's not necessarily the case (depending on settings actually used at compilation). I'd also venture guessing that Samsung kernels don't do it , but can't check as I'm on a CM9-based ROM right now. We would need to check if any of the two locations above exist using a Samsung kernel.
Well that's one way to go around it anyway, there may be others
cooldoud said:
Good idea! Not an expert in the field either, but I believe some kernels have their settings available at /proc/config or /proc/config.gz, but that's not necessarily the case (depending on settings actually used at compilation). I'd also venture guessing that Samsung kernels don't do it , but can't check as I'm on a CM9-based ROM right now. We would need to check if any of the two locations above exist using a Samsung kernel.
Well that's one way to go around it anyway, there may be others
Click to expand...
Click to collapse
Samsung kernels do not enable /proc/config.gz
In addition, even if they did, MMC_CAP_ERASE is a flag within the source code of mshci.c - not a config item in the defconfig.
The only way to check if MMC_CAP_ERASE is present is to attempt to issue an erase command and see if it returns an error or not... The problem with this approach is pretty obvious...
There's no way to verify that a recovery or update-binary is safe without testing it against an instrumented kernel.
There's no way to verify that a kernel is safe without performing dangerous tests. It might be that a small erase is far less likely to cause damage than a large one - but this is too risky.
Entropy512 said:
In addition, even if they did, MMC_CAP_ERASE is a flag within the source code of mshci.c - not a config item in the defconfig.
Click to expand...
Click to collapse
Oh well, bad suggestion it seems, didn't think this was so deep the source. Thanks for the knowledge sharing though!
Byte code signature
From what I now understand MMC_CAP_ERASE is a flag that is either set or not.
If a kernel was compiled with the flag set and then the same kernel was compiled with the flag unset, would this not allow for a byte code signature to be detected.
This byte code signature could then be used in a binary search of an installed kernel.
This is guess work on my behalf and I could be completely wrong with my approach .
Roy_W said:
From what I now understand MMC_CAP_ERASE is a flag that is either set or not.
If a kernel was compiled with the flag set and then the same kernel was compiled with the flag unset, would this not allow for a byte code signature to be detected.
This byte code signature could then be used in a binary search of an installed kernel.
This is guess work on my behalf and I could be completely wrong with my approach .
Click to expand...
Click to collapse
Too much else changes from kernel to kernel. It's one bit set in a single variable, it's not like the MC1N2 initialization data which are huge fixed data structures.
Searching for a single bit set in a single integer variable when you don't know where that int is stored is impossible to reliably do.
Sent from my GT-P7510 using Tapatalk 2
mmc->caps
Entropy
I have googled copy of the mshci.c file and I see that the MMC_CAP_ERASE of used in order to initialise or not a struct named mmc->caps.
I can't find the declaration of mmc->caps but would it be possible to interogate
mmc->caps in order to read it's current state. This would allow us to see if the MMC_CAP_ERASE had or not been included in its initilisation ?
R
this is nearly impossible. yes there are ways to do it but i will take too much time and effort and will not worth it. my advice is look kernels which states it removed that flag like speedmod. if you want to be sure about the official kernels you need to wait until samsung releases source codes so you can look if that flag is set or not.
Having given a little bit more thought to the replies.
1 : The mmc-caps is a struct that is held at the kernel level.
2 : The Andoird SDK does not provide APIs that allow us to directly obtain information from the kernel level.
Therefore not an easy program to write.
Question : What method/language/technique would Chainfire have used in order to read the firmware level when he wrote his app?
Roy_W said:
Having given a little bit more thought to the replies.
1 : The mmc-caps is a struct that is held at the kernel level.
2 : The Andoird SDK does not provide APIs that allow us to directly obtain information from the kernel level.
Therefore not an easy program to write.
Question : What method/language/technique would Chainfire have used in order to read the firmware level when he wrote his app?
Click to expand...
Click to collapse
The chip cid/name are exported in the sysfs even on stock kernels. The fwrev is part of the cid string.
That capabilities variable, I am fairly certain, is not exported anywhere in sysfs. One could add exporting of it to the source, but that's kind of pointless - it's easy enough to verify open source kernels for safety, it's Samsung's binaries that are difficult.
Thanks for replying guys, you have made things clearer.
This bug is interesting even though it is potentially fatal.
I need a little bit of help portingh crDroid 6 to the sm-t350. Nubianprince started then got pulled away by work. I have initalized the crdroid repo, but i when i run repo sync i think it only downloaded like, 300 mb. i do have an android pie enviroment, does repo link resources? i dont know what is going on there. I will upload my roomservice.xml. I had to remove a couple lines from the original and manually clone them because it keeped giving me an error. the original is here https://github.com/Nubianprince/local_manifests/blob/master/crdroid-ten.xml .
Currently i am using this device tree: https://github.com/Nubianprince/android_vendor_samsung_gt58wifi most custom roms i see are using this: https://github.com/Valera1978/android_device_samsung_gtaxlwifi . I have not seen any non sm-5xx devices using it though, so i hesitate to switch. i worked out a a couple errors of things being defined twice, and then built. but i think i am missing something as the build fails with this: FAILED: ninja: 'out/target/product/gt58wifi/root/init.usb.configfs.rc', needed by 'out/target/product/gt58wifi/ramdisk-recovery.cpio', missing and no known rule to make it
Is there a "quick fix" to provide this file? I am not actually sure what i am missing, or what creates it.
Any help would be appreciated.
This file "init.usb.configfs.rc" is missing from your device tree, somewhere in one of your files you have the path pointing to "init.usb.configfs.rc" which does not exist. Let me know if that makes sense.
nubianprince said:
This file "init.usb.configfs.rc" is missing from your device tree, somewhere in one of your files you have the path pointing to "init.usb.configfs.rc" which does not exist. Let me know if that makes sense.
Click to expand...
Click to collapse
Yes, it does make sense. I just don't know enough about the android environment to know where the file, or what is pointing to it, would / should be.
Okay. I believe there is a missing, or many many missing makefiles. I found the file and manually copied it to out, and then the build fails with another missing file. Rinse and repeat, there are a ton of files not being put where they should be. Now what to do with that information, i am not sure ??. I tried including a couple of the make files from android 9, but they didn't make any difference.
oh yeah, and if i do lunch instead of brunch it fails with a different file missing: FAILED: ninja: 'out/target/product/gt58wifi/system/addon.d/50-lineage.sh', needed by 'out/target/product/gt58wifi/verified_assembled_framework_manifest.xml', missing and no known rule to make it
it makes no sense adding files to the "out" folder, fix the issues in your "device" folder check your device.mk file
Wow. That was really awful. I don't even know what i was thinking there. What i was trying to say, is that i was manual copying the files to see if it was just one or two not being copied. I have been comparing the Pie and Q makefiles to try to determine what file was supposed to be copying it to out, but i cant find it in Pie, all i know for now is that it is being copied in Pie but not Q. For now I'm gonna' keep looking for the correct file.
lividhen99 said:
Wow. That was really awful. I don't even know what i was thinking there. What i was trying to say, is that i was manual copying the files to see if it was just one or two not being copied. I have been comparing the Pie and Q makefiles to try to determine what file was supposed to be copying it to out, but i cant find it in Pie, all i know for now is that it is being copied in Pie but not Q. For now I'm gonna' keep looking for the correct file.
Click to expand...
Click to collapse
What device tree are you using, do you have it on Github?
nubianprince said:
What device tree are you using, do you have it on Github?
Click to expand...
Click to collapse
I am just using the device trees (ten branch) on your GitHub. I haven't made any changes that have gotten me anywhere so i haven't committed my local changes to my GitHub.
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
nubianprince said:
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
Click to expand...
Click to collapse
I have been away for a while and haven't followed along, but the last week I spent compiling ROMs. I also tried compiling Android 10 using "stock" lineageos gt58wifi and I got stuck at the logo as well. I also tried another device from the msm8916 repository and got stuck at the logo.
The "stock" gt58wifi build, as we all know, has problems with audio, bluetooth, smart cover, etc, etc in all versions 14.1, 15.0, 16.0 and won't even boot with 17.1.
When I first compiled it, it would fail due an error with a config.xml file. I submitted a patch, like others, but haven't seen anything yet.
https://github.com/Galaxy-MSM8916/android_device_samsung_gt58wifi/pulls
nubianprince said:
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
Click to expand...
Click to collapse
I'm working on SM-T560NU 17.1. It too was stuck at the boot logo. I built an eng build and found it was the hardware vibrator that was getting stuck in a loop. If you remove the vibrator hal from
/device/samsung/msm8916-common/manifest.xml
that should work on the SM-T350 because both platforms share the same msm8916 code?
I did build SM-T350 with 17.1 and was stuck at boot logo and gave up. However, I have not rebuilt it knowing this new information. I will try again with the above change in a few days?
So, as retiredtab has said, he got android 10 booting. But it has all the issues android 9 did: no camera, sound, Bluetooth, or Hal sensor (sort of, it can turn the device on but not off). The system ui is also a little funny on crdroid, not sure about lineage. I don't know how to fix these issues, or where the roots of the problems may lay. Do you have any suggestions for learning more about the android source code? I feel like the aosp docs are good, but you kind of have to know what you're looking for.
I think part of the problem with the SM-T350 is that there has never been a fully working build since day 1. Lineageos 14 had problems to begin with and they were never fixed and got carried over to 15, 16 and now 17. If stock Lineageos 16 was fully working, then getting it to work on 17 would be less of a challenge.
The most likely problem to no audio, camera, bluetooth etc is the Samsung proprietary blobs are not in the correct directories or the configuration blob files are pointing to the wrong directory.
When I face this problem, I find it helpful to look at a working roomservice.xml file and do comparisons.
If there is no working roomservice.xml like "stock" lineageos 14, 15, and 16 for the SM-T350, then I look at similar models. For example, the T550 is the bigger brother and it helps to look through it's roomservice.xml file for hints.
Remember that a compiler mainly checks for syntax errors, not semantic. If you make a typo, a compiler will flag that as an error, but if you write correct syntax, but put a file or files in directory ABC instead of XYZ, the compiler won't say anything.
Another thing that might help is doing a logcat of a working build and comparing it to a non working build. There might be a very obvious error message like "can't find audio.hw.msm8916 in directory /device/samsung/msm8916" or something like that.
Learning how to use tools like meld and diff help tremendously in finding file and directory differences in case you put the blobs in the wrong place. See
https://www.tecmint.com/compare-find-difference-between-two-directories-in-linux/
I used meld when troubleshooting the stuck at boot logo.
If you are a visual learner, I found the following youtube channel helping in learning the overall process of building ROMs.
https://www.youtube.com/c/AlaskaLinuxUserAKLU/videos
I think we have lineage 16 fully working. I think the part I'm having trouble with here is the difference between where the files are read from in Android Q vs P.
If I understood what you said incorrectly, please say so.