Is there a description on how to create a new device build based on an existing device build?

[Curt Schwaderer]

Hello,

We're planning to use an existing board build on the AOSP and we want to create a new product build based on this existing one plus the additional application software we add.

I can't seem to find an up-to-date description of how to do this - they best I found was a powerpoint from 2015 that is what I'm looking for except that it's out of date.

If anyone has any up-to-date descriptions or links to descriptions on how to do this, I'd really appreciate them!

[florian....@inovex.de]

Hi,

I'm not sure how current the information is, but in device/common is a
script called populate-new-device.sh, which creates some boilerplate as
a starting point.

I hope that helps.

[Curt Schwaderer]

Thanks - the pointer is much appreciated and helpful.

A board vendor has already created an aosp build for their board, so they have a device/<company> and vendor/<company> directory and they are building 2 things - an aosp_<codename> image and a <codename> image. So we think we just need to use the aosp_<codename> build to create the baseline image for our product which will run on this same board. Then we will add some libraries and an application which is our product derivative off of this board's AOSP image. 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.

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.

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.

Thanks!

Curt

--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
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 a topic in the Google Groups "Android Building" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-building/A2adhSfvC5c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/39ea1101-c1ed-4343-a9d0-6b589fba007cn%40googlegroups.com.

[xstefen]

Do an if statement to import the additional module repo build instructions

[florian....@inovex.de]

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.

[Curt Schwaderer]

Thanks so much - this is very helpful