Thanks so much - this is very helpful On Thursday, July 29, 2021 at 10:36:35 AM UTC-5 [email protected] wrote:
> Then somehow we will ultimately need to walk through everything they are >> building in their aosp image that we don't need and prune that stuff out >> somehow. >> > > I'm not sure this is really supported by the build system, I only ever > saw additive build processes, where the inheriting devices only extended > the contents of the device inherited from. > Only in a single case I have worked with a device, that tried to remove > content inherited from their parent devices, and it was pretty painful > and looked like fighting against the build system. > Ideally, the <codename> image would only contain stuff that is *really* > needed, while the aosp_<codename> contains all the extra bits and pieces > to make a mobile device of it. At least that is how I believe walleye > did it. So if you can talk to your board vendor if it isn't the case > already, I think that would be much less painful than to try pruning an > image. > > >> The first thing we did is the manual version of the script you pointed us >> to. Then somehow reference the board manufacturers' /device and /vendor TOP >> directories. Then we thought we could simply use the overlay mechanism to >> add the libraries and application for our product to the board vendor's >> aosp image. But this is resulting in a bunch of errors. >> >> We also tried the brute force approach - basically copying over files >> from the /device/<company> directory into our device/<ourcompany> directory >> until we can build an image. We did manage to get that to work, but we >> don't know if that is what we're supposed to do or not. It works, but if >> the board vendor changes anything in their build environment, we would need >> to go through an iteration of figuring out which files changed and then >> change those things in our directory - because of this, it feels like this >> is not the right approach. >> > > That really is the not-so-quick and dirty approach, but unfortunately, some > board vendors don't care how the AOSP build system is supposed to work, and > don't bother to do proper integration. In these cases a process like that > is ne- > cessary. > But since you already mentioned that they provide two different build tar- > gets, I would have expected it to be in a state where it works reasonably > well. > > > >> What's missing is a good example of how a company is supposed to use the >> build environment for a board that has already created an Android AOSP >> image and simply add their modules to create the image for their product. >> IT seems like this should be very simple, but we haven't come across the >> magic formula yet. >> > > I don't know of any official documentation, but have you looked at the > devices > provided by Google in the AOSP source tree? The build system implements an > in- > heritance mechanism, where a child device can copy definitions from its > parent > devices. Look for lines containing $(call inherit-product,device/foo/bar/ > bar.mk), > these do exactly what you want to do. But a word of caution, device > inheritance > works only on select variables the build system knows how to extend. If > the ven- > dor didn't expect their device to be inherited from and e.g. set some > variables > not supported by the inheritance system, you may be out of luck. A hack > around > this could be to just include the respective Makefiles from the parent > device, > but then you have to be very careful about your own Makefile, because while > inheritance merges variables used by both devices, including another > Makefile > just overwrites any already present value. > -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/36decd08-e791-4fb7-9bc5-fee01738b0ffn%40googlegroups.com.
