| dcaliste | Hello, I'm very new to Android compilation, so I'm sorry if my question is stupid: my compilation is failing because file vendor/qti/hardware/fm/1.0/IFmHci.h is not found. So I guess, I'm missing some repo from vendor. Typically the one providing vendor.qti.hardware.fm@1.0. | 10:32 |
|---|---|---|
| dcaliste | Is it something that could be public ? Is Qualcomm providing headers for this ? | 10:33 |
| voidanix[m] | very likely, yes, is this AOSP or lineage? | 11:38 |
| dcaliste | It's AOSP. I've followed the HADK to get AOSP sources and added four repos to the manifest that I would like to investigate the compilation of, as suggested there : https://github.com/sonyxperiadev/vendor-qcom-opensource-bluetooth/issues/4#issuecomment-1142014562 | 11:39 |
| Thaodan | The header is part of blobs unfortunately | 11:43 |
| voidanix[m] | Oh | 11:43 |
| dcaliste | And these blobs are not public, I guess ? | 11:43 |
| Thaodan | yes that's why they blobs | 11:44 |
| Thaodan | Have to ask Sony | 11:44 |
| dcaliste | Sorry being blunt, all this is new to me. | 11:45 |
| Thaodan | np | 11:45 |
| Thaodan | Most of the QCOM stuff is partially oss but the real meat is closed | 11:46 |
| dcaliste | That's what I guess indeed. Well, in a perfect world, I would have changed manufacturer, but since it's not really an option, I'm trying to figure out what can be done. As far as I understand it, the OSS part allow us to mimick how to speak to the closed parts. | 11:47 |
| dcaliste | First step is to be able to get the OSS parts compile, so the FM receiver can be used on Sony devices with AOSP, right ? | 11:48 |
| dcaliste | Then second step would be to do the same from SailfishOS side instead of AOSP. | 11:49 |
| dcaliste | So, I need to see with Sony how to get these blobs. At least the headers, because I guess the .so are somewhere in the myriad of partitions on device ? | 11:50 |
| Thaodan | Alin said we can replace the odm version of bt with the oss parts you build but I have to wait for a replay. | 11:50 |
| Thaodan | *reply | 11:50 |
| Thaodan | Since the oss part needs blobs to compile we have to check. | 11:51 |
| dcaliste | Indeed. That's my concern : how to build the OSS parts if they rely on non distributed headers… I thought I was missing something because I've never compiled anything for Android before. But it seems the obvious closed parts were the reason. | 11:52 |
| dcaliste | By the way : a simple question about Android compilation : are there default targets ? Like the all: one in Makefiles ? I mean, how do you say to it "please compile all targets under that path" ? | 11:53 |
| dcaliste | Currently, I'm looking at targets in Android.bp files and call "m <target>" by hand for each. Which is suboptimal. | 11:54 |
| Thaodan | Alin is looking into it. | 12:00 |
| Thaodan | dcaliste: Yes if you want to build e.g. vendor.img you can build vendorimage | 12:01 |
| dcaliste | Thanks, as a first step, I was just thinking about a command just to build things under /vendor/qcom/opensource/commonsys/fm for instance. "m vendorimage" is building 62279 files… Well, if everything goes well, future call to make will skip all those I'm not interested in. | 12:05 |
| Thaodan | For android you always build complete images | 12:14 |
| Thaodan | You can't just replace a program | 12:14 |
| dcaliste | Ok, thanks. As I said, all this is really new to me. I'm more confident with softwares separated into pieces that you can make and or replace at will. This huge monolithic approach looks weird. Well I guess it has its own reasons. | 12:18 |
| Thaodan | Part of it is security architecture and ease of updates. | 12:20 |
| Thaodan | But the security part depends on your pov | 12:21 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!