> > 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/f444a408-82d6-4be2-8762-bd3de827bd0an%40googlegroups.com.
