Android 10 does not have a "build/target/product/core.mk" file

646 views
Skip to first unread message

John W. Blue

unread,
Nov 11, 2019, 12:59:25 PM11/11/19
to android-...@googlegroups.com

First, wanted to say thanks for the help on my other questions to Dan and Colin.  I was able to get a working default ROM complied and my ccache pushed up against 20 GB.

 

Previously I would edit build/target/product/core.mk to remove basic items .. email for example.  As best as I can tell grep’ing around, it seems like these files took the place of core.mk:

 

handheld_product.mk

handheld_system.mk

handheld_vendor.mk

 

What I have not been able to find is a discussion about this change because I want to understand the intent and what drove the decision.  I read the release notes here:

 

https://source.android.com/setup/start/android-10-release

 

but it didn’t speak about it.

 

Am I correct in assuming that handheld et al is the new “core.mk”?

 

John

Dan Willemsen

unread,
Nov 11, 2019, 3:22:56 PM11/11/19
to Android Building, Anton Hansson
+Anton Hansson who did a lot of this work.

If you're building a phone-like product, then yes, I believe using handheld_* is appropriate (or maybe mainline_system.mk, which is the effort towards a unified system image for multiple devices), though if you're having to remove things, maybe using one of the ones it includes would be better. We tried to merge and split these apart so that they made more sense -- combining some layers while splitting them up into per-partition files.

- Dan

--
--
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 the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/fbead81a3f564acab84936a25d603dcc%40mail.rrcic.com.

Anton Hansson

unread,
Nov 12, 2019, 11:49:54 AM11/12/19
to Dan Willemsen, Android Building
The inheritance chain of these makefiles goes like this:

(these are the major .mks, there are many others inherited too). The *_system part here means "the /system partition", and there are parallel hierarchies for the other partitions. The "base" level is the lowest level of maintained shared product mk we have, but I don't know whether building that is sufficient to get a bootable device. In general, products branch off of this hierarchy somewhere and add their own stuff on top. The only one of these that's used directly without additional modifications is mainline_system.

re intent: the shared product makefile hierarchy was a complete mess (still is, but less). There are limitations in the build system that makes it difficult to remove things, so new levels kept getting added to customize other products without having to duplicate things. Those new levels didn't really have a "concept", or a firm idea of what set of devices should inherit them. So when adding a new package, it was difficult to know which level to add that package to. It's better now, but still needs work. I'd ideally like to get to a point where the only shared mks we have are things like "cars", "wearables", "phones" etc.
re discussion: it was discussed internally, not in this forum. If there are people here who have strong opinions about what a healthy product mk hierarchy looks like I'd like to hear about it :)

Anton
Reply all
Reply to author
Forward
0 new messages