AOSP Automotive 9

I’d say that I now have AOSP9 up to equivalent or better state than I had AOSP8.1 in.

I have fewer (only 3) hacks, one of which is to correct an actual bug/oversight in AOSP, the other two are fairly non-invasive and I should eventually be able to get rid of them (2) altogether.

**NO SELINUX HACKS THIS TIME!!!

If anybody wants to play with it, use the September 11, 2018 known good manifest, along with patches, device, and kernel listed in this post: AOSP Automotive 9 - #5 by doitright (5th post of this thread).

1 Like

Could someone post a screenshot of what AOSP Automotive for Pie looks like? I’m curious what the changes are between Oreo and Pie for the layout.

Thanks!

Hi @doitright,

I’ve just read finished reading up on your project. Really impressive work!

I was looking at using this project as a working implementation for exploring Android Automotive. Google doesn’t provide a reference implementation for Automotive (other than the emulator), and this seems like the next best thing.

I’m not sure how much you’re willing to share about your future plans, but I would be interested in knowing if how your automotive mezzanine board is coming along. Is it better to start with the current setup you’ve documented, or wait for your mezzanine?

Speaking of the emulator, have you or anyone else managed to get the any value out of the aosp_car_* emulator targets? The current state in AOSP9 seems pretty broken (it builds and runs, but not much else works out of the box).

— James

Well, there are some complicated questions :slight_smile:

I suppose that the first thing I need to point out is that I’m working on this project in my spare time, as time permits, and I have 3 kids, the eldest of which will be 5 in a couple of weeks, so as you can imagine, there is very little sleep, and available time is quite unpredictable.

Which really means that I cannot make any kind of promises as far as time to completion goes.

I HOPE that I can get some kind of limited production for early testers by the end of the year or January.

The current hardware status is that I’ve just yesterday received another batch of unpopulated prototype boards, on which I believe that I’ve got everything actually working such that it won’t need any modifications for all board features to be functioning correctly. The previous batch was really good, except for a couple of very minor glitches.

Now everything working, of course, does not mean that I am completely satisfied with the board. I did cut a corner in this board that I have not entirely worked out yet. That corner I cut is that I used an aliexpress amfm radio module with an NXP TEF6686 tuner. While the module is “good and cheap”, there are a couple of serious drawbacks to it; its AM performance is barely above the level of “trash”, and there is an absolute lack of any kind of documentation available for programming the thing unless you feel like signing away your first born as collateral to their NDA.

So I’m implementing a 2-step way forward from that module;

  1. a “nearly” pin compatible custom module based on Si4743 (which has full public documentation), and
  2. integrating the Si4743 radio directly onto the mezzanine instead of appending it as a module.

When I say “nearly” pin compatible, I mean that the power supply is a bit different. The TEF6686 module requires a 5V supply and has an onboard 1117-3.3, but my mezzanine already has an L4931-3.3 onboard, with plenty of available capacity for the Si4743. So I’m powering it with 3.3v instead of 5, and delivering it through a pin which on the TEF module is NC, so despite the slight difference, it will ultimately be a drop-in replacement.

The second step is to eliminate the through-hole connector that is situated over the base board’s two USB ports, as well as reduce cost (not that this will make it cheap…). As I’m sure you are aware, there is not a ton of space above those USB ports, which means that the pins need to be clipped flush with the board before soldering in order to have enough clearance.

Now for the “current setup”… I’m sure you are referring to the sensors mezzanine + USB sound card + DMHD1000 configuration. I actually haven’t maintained that configuration into AOSP9, although some are reporting success with it still, after returning the audio HAL back to what it was when I was still working with that hardware. To be honest, I’d describe that design as a real pain in the ass, which is why I’ve moved onto the custom mezzanine – although I am still running that very setup in my car, and it does function extremely well. Before you ask if I have any real-world testing on the mezzaning, yes, I have that configuration installed in my wife’s car which she’s been using with very few complaints. Well 1 complaint, which directly tied to the TEF6686 radio.

As for the emulator, the value I’ve been able to get out of it is this; it gave me a real good picture of how they intend for it to look and operate. But when it comes down to it, I don’t think I had the AOSP-8 emulator running more than about 15 minutes, and the AOSP-9 for more than about 5 minutes. For me, it really all came down to taking in the visual intentions.

@doitright

Wow, please tell me you don’t have a full-time job on top of all that, or I’ll start to feel that I’m slacking off. :slight_smile:

Fortunately for me my oldest is 5, so we’re no longer “dans le jus” .

January is far away enough that I’ll probably still want to get going with the current setup with the DMHD1000 tuner and USB audio. Looking at the latest commits in your AOSP9 branches, it looks like I’ll have to mix and match commits a little bit to get AOSP9 working with the current setup. I’m happy to help if you want me to help test your board, in the meantime I’ll play around with the older setup / HAL.

Thanks!

I hate to say that you’re slacking off…
So I won’t say anything.

I think the DMHD1000 HAL should be pretty easy to fix up to bring back into 9. The only change I had to do to the TEF6686 HAL was a change to the Android.mk related to includes being renamed. Also in addition, probably some changes to the sepolicy.

Now the one thing about the DMHD1000 is that it is that they’re discontinued and starting to get somewhat scarce. $140 USD on Amazon.com. However, there really is nothing stopping you from going with a TEF6686 module, since they’re cheap and plentiful; https://www.aliexpress.com/item/Radio-module-with-TEF6686-TDQ-230V-86-TDQ-230V-86-R-2PCS-Lot/32809641460.html

Downside being, of course, what I’ve already mentioned. And note that it wants to interface at 3.3v, so obviously a level shifter is a must. If you’re going with the sensors mezzanine for SWI and power management, then you are all set to wire it straight in.

1 Like

I got build fail below:

FAILED: out/target/product/hikey960/verified_assembled_vendor_manifest.xml

/bin/bash -c "PRODUCT_ENFORCE_VINTF_MANIFEST=true

out/host/linux-x86/bin/assemble_vintf -c out/target/product/hikey960/obj/ETC/verified_assembled_system_matrix.xml_intermediates/verified_assembled_system_matrix.xml -i out/target/product/hikey960/obj/ETC/device_manifest.xml_intermediates/manifest.xml $([ -d out/target/product/hikey960/vendor/etc/vintf/manifest ] && find out/target/product/hikey960/vendor/etc/vintf/manifest -type f -name "*.xml" | sed "s/^/-i /" | tr ‘\n’ ’ ') -o out/target/product/hikey960/verified_assembled_vendor_manifest.xml"

File "out/target/product/hikey960/vendor/etc/vintf/manifest/android.hardware.cas@1.0-service.xml" cannot be added: conflict on HAL "HAL "android.hardware.cas" has a conflict." with an existing HAL. See <hal> with the same name in previously parsed files or previously declared in this file.

13:48:31 ninja failed with: exit status 1

I’m really not sure how you expect anyone to help you without providing a lot more details on it, such as, for example, what exactly you are trying to build, and how you put it together.

My step of building android automotive is listed below

  1. Init AOSP repo

repo init -u https://android.googlesource.com/platform/manifest -b master

  1. Sync with manifest from default

repo sync -j8

  1. Replace /device/linaro/hikey with

git clone https://gitlab.com/HiKey960-Car/android_device_linaro_hikey.git -b master_091118_car96

  1. Build

. build/envsetup.sh
lunch hikey960_car-userdebug
UBLOX_GPS_HAL=TRUE DMHD1000=TRUE HDMI_RES=“1920x1080@60” m -j4
===============================================
File “out/target/product/hikey960/vendor/etc/vintf/manifest/android.hardware.cas@1.0-service.xml” cannot be added: conflict on HAL “HAL “android.hardware.cas” has a conflict.” with an existing HAL. See with the same name in previously parsed files or previously declared in this file.
===============================================

Hi @doitright,

I’m sorry that did not mention it clearly,
I’m currently building android automotive from platform/manifest - Git at Google master for Hikey960 and I’m employing “https://gitlab.com/HiKey960-Car/android_device_linaro_hikey.git” to lunch device.
However, I just suffered from the following to problems:

  1. I cannot repo sync from 2018-09-11_15:49:35-pinned-manifest.xml, since I cannot find the file
    Question: Where can I find eh manifest? If I just sync default manifest, would it be okay for building android automotive?
  2. Is there anything wrong about my steps for building image leading below error:

File “out/target/product/hikey960/vendor/etc/vintf/manifest/android.hardware.cas@1.0-service.xml” cannot be added: conflict on HAL “HAL “android.hardware.cas” has a conflict.” with an existing HAL. See with the same name in previously parsed files or previously declared in this file.

AOSP master is a moving target. I don’t have the resources available to me to perpetually keep my changes in sync with AOSP master. As a result, it is absolutely critical to use an appropriately aged known good manifest in order to guarantee that all the different parts are compatible.

There have been a lot of changes since September. In the very least, it would definitely be necessary to merge my work with the device and kernel master in order for it to work.

Known good manifests are kept here: https://github.com/96boards/aosp-known-good-manifests/tree/master/known-good/hikey960

One other thing to be aware of is that the kernel source from back in September may not be able to boot certain newer hardware revisions.

Hi @doitright,

It is a little be confused about two things you mentioned below:

  • “it would definitely be necessary to merge my work with the device and kernel master in order for it to work.”
  • “the kernel source from back in September may not be able to boot certain newer hardware revisions.”

Should I just replace below(android_kernel_linaro_hikey ) to ./HiKey960/device/linaro/hikey-kernel for making it compatible or using the original master hikey-kernel?

Kernel from here: gitlab.com/HiKey960-Car/android_kernel_linaro_hikey

Thanks~

Hi,

Is there any one can share the img runs successfully for Hikey960 with android automotive, since I just suffered from the problem of Sync with manifest from 11.09.2018 .

Thanks~

update

I can repo sync the latest code successfully
However, I get hangs all the time for sync 2018-09-11_15_49_35-pinned-manifes without error log below:
repo sync -m 2018-09-11_15_49_35-pinned-manifest.xml

I’ve tried to fix Source Sync Issues mentioned below, but it does not work:
https://source.android.com/setup/build/known-issues

Why do you think it is hanging if there is no error?

I was watching the log for 24 hours and there is no response.
Can you sync successfully?

Is there any difference between non car and car branches:

  • master_apr2018_car96
  • master_apr2018
  • master

This project is used for building android automotive in hikey960, isn’t it?
Can we still build android automotive with master branch?

The sync works fine for me. If you’re having difficulty with it, you should probably create a new thread to address that specifically as it isn’t related to this project.

All of the branches I’ve added commits to are automotive. The ones labeled “car96” specifically support a custom mezzanine board I’ve designed, whereas the others support the proof of concept design (which uses a USB sound card). I am not maintaining the proof of concept design, and so there is no branch for that any newer than April.

Edit: the “master” branch on my repository is extremely out of date.

Hi @doitright ,

I’d like to confirm the things below:

  1. Is the command of “UBLOX_GPS_HAL=TRUE DMHD1000=TRUE HDMI_RES=“1920x1080@60” m -j4” buuilding img which as same as “make -j32” ( AOSP hikey960 instruction) below:

    out/target/product/hikey960/boot.img
    out/target/product/hikey960/dt.img
    out/target/product/hikey960/system.img
    out/target/product/hikey960/vendor.img
    out/target/product/hikey960/cache.img
    out/target/product/hikey960/userdata.img

  2. Should we build the kernel by HiKey960-Car / android_kernel_linaro_hikey_OLD · GitLab before question 1? For my understandingly, it is used for building bootimage but we have built bootimage in question 1, haven’t we?

  3. which kernel should be complied and run in hikey960 with for the target device of “HiKey960-Car / android_device_linaro_hikey · GitLab

The impact of setting those variables is explained in the document where you found them. Having said that, I have not updated the dmhd1000 hal to be compatible with aosp9 – it isn’t even present. There is a hal for a tef6686 radio present, you can get a tef6686 from AliExpress for about $5.

Yes, kernel has to be built before boot image if you are building it. My kernel has additional hardware enabled it, but you may get by with precomputed or upstream kernel until you figure out what hardware you will be using.