Android AOSP 7.1 build for DragonBoard 410c - Successful build but failed to boot

Richard_Chambers · November 19, 2020, 6:21pm

Wanting an Android build later than the standard Android 5.1 build available, I’ve been looking to create a usable image from Android AOSP.

After deciding the technical challenges to use master of Android AOSP, which appears to have dropped support for DragonBoard 410c with the dropping of Android 11 source into master sometime Summer 2020, I was hoping to use an older Android version.

Meanwhile, I’ve opened this issue on the existing DragonBoard 410c Android build. https://github.com/96boards/documentation/issues/909

It appears that the Android 7.1 branch of Android AOSP contains provisions to build DragonBoard which looks to be the DragonBoard 410c.

I was able to complete a build successfully on Ubuntu 20.1 after doing the following:

pulled a copy of android-7.1.2_r39 using repo
. see Downloading the Source | Android Open Source Project
set python command to point to python2 which is needed for the build
installed openjdk-8.jre
installed javac after getting build errors
flex build errors for loadlocale.c required export LC_ALL=C
. see 18.04 - What is the correct way to fix an assertion in loadlocale.c? - Ask Ubuntu

The lunch menu shows aosp_dragon-userdebug and aosp_dragon-eng and I assume these are both for the DragonBoard 410c. How can I verify that?

I tried putting flashing the build onto my DragonBoard 410c with fastboot and ended up bricking it. I’m going to put Android 5.1 99 from Android Downloads for DragonBoard-410c - 96Boards back onto the board.

What do I need to do to use a later version of Android? Android 7.1 would be fine as it appears to use a later Linux kernel than Android 5.1. I’m looking to use the GPIO library support that was introduced with Linux kernel 4.1 or so.

doitright · November 19, 2020, 8:13pm

I’ve explained to you already that dragonboards are ONLY supported with the MASTER branch. 7.1 is NOT going to work. The adjustments needed to update the Linaro AOSP support for db410c from 10/master to 11/master are extremely small. Try it. Watch the errors thrown by the build, look them up, and make appropriate corrections. Very likely the corrections needed will be exactly the same as those that have been added to db845c since 11 was merged.

Richard_Chambers · November 20, 2020, 2:16am

@doitright as I’ve mentioned to you in a previous discussion, my knowledge of the Android build materials and process are practically nil.

I have tried master in Android AOSP and I’m trying it again. However i am see plenty of warnings from various steps and I have no idea as to how much the build results are affected.

I looked at the commit list from the link you provided. There are a number of commits over the past year by a couple of different people. I have no idea which of these commits you are referring to by:

Take a look at the most recent few commits I’ve added for my work on the db820c here; Commits · wip-automotive-11 · AOSP-Automotive / dragonboard · GitLab – maybe it will give you an idea what you need to do to get it working for 410c.

I see nothing by a user doitright so I assume you are one of those people however I have no idea as to what user name you used to do the commits you refer to in the above quote from Is the AOSP master supported? - #44 by doitright

Reviewing the list of commits, I have found nothing that would seem to apply to the DB410c materials of master of Android AOSP. They all seem to be specific to the Android Automotive project and source.

If there are specific commits you think are appropriate then please let me know what those may be.

Richard_Chambers · November 20, 2020, 4:57am

@doitright My last build attempt of Android AOSP failed with the following logs:

[ 74% 50897/68156] build out/target/product/db410c/obj/PACKAGING/check_vintf_all
FAILED: out/target/product/db410c/obj/PACKAGING/check_vintf_all_intermediates/check_vintf_vendor_log
/bin/bash -c "( out/host/linux-x86/bin/checkvintf --check-one --dirmap /vendor:out/target/product/db410c/vendor --property ro.boot.product.vendor.sku= > out/target/product/db410c/obj/PACKAGING/check_vintf_all_intermediates/check_vintf_vendor_log 2>&1 ) || ( cat out/target/product/db410c/obj/PACKAGING/check_vintf_all_intermediates/check_vintf_vendor_log && exit 1 )"
checkvintf I 11-19 21:57:18 294853 294853 check_vintf.cpp:461] Checking vendor manifest.
checkvintf I 11-19 21:57:18 294853 294853 VintfObject.cpp:57] getDeviceHalManifest: Reading VINTF information.
checkvintf I 11-19 21:57:18 294853 294853 check_vintf.cpp:76] Sysprop ro.boot.product.vendor.sku=
checkvintf I 11-19 21:57:18 294853 294853 HostFileSystem.cpp:43] Fetch 'out/target/product/db410c/vendor/etc/vintf/manifest.xml': OK
checkvintf I 11-19 21:57:18 294853 294853 HostFileSystem.cpp:54] List 'out/target/product/db410c/vendor/etc/vintf/manifest/': OK
checkvintf I 11-19 21:57:18 294853 294853 HostFileSystem.cpp:43] Fetch 'out/target/product/db410c/vendor/etc/vintf/manifest/android.hardware.cas@1.2-service.xml': OK
checkvintf I 11-19 21:57:18 294853 294853 HostFileSystem.cpp:43] Fetch 'out/target/product/db410c/vendor/etc/vintf/manifest/manifest.xml': OK
checkvintf E 11-19 21:57:18 294853 294853 VintfObject.cpp:67] getDeviceHalManifest: status from fetching VINTF information: -2147483648
checkvintf E 11-19 21:57:18 294853 294853 VintfObject.cpp:68] getDeviceHalManifest: -2147483648 VINTF parse error: Cannot add manifest fragment /vendor/etc/vintf/manifest/manifest.xml: HAL "android.hardware.wifi.supplicant" has a conflict: Conflicting major version: 1.2 (from /vendor/etc/vintf/manifest.xml) vs. 1.3 (from /vendor/etc/vintf/manifest/manifest.xml). Check whether or not multiple modules providing the same HAL are installed.
checkvintf E 11-19 21:57:18 294853 294853 check_vintf.cpp:464] Cannot fetch vendor manifest.
checkvintf I 11-19 21:57:18 294853 294853 check_vintf.cpp:467] Checking vendor matrix.
checkvintf I 11-19 21:57:18 294853 294853 VintfObject.cpp:57] getDeviceCompatibilityMatrix: Reading VINTF information.
checkvintf I 11-19 21:57:18 294853 294853 HostFileSystem.cpp:43] Fetch 'out/target/product/db410c/vendor/etc/vintf/compatibility_matrix.xml': OK
checkvintf I 11-19 21:57:18 294853 294853 VintfObject.cpp:63] getDeviceCompatibilityMatrix: Successfully processed VINTF information
21:57:20 ninja failed with: exit status 1

#### failed to build some targets (03:18:54 (hh:mm:ss)) ####

Looking in the file device/linaro/dragonboard/manifest.xml I find the following:

<hal format="hidl">
    <name>android.hardware.wifi.supplicant</name>
    <transport>hwbinder</transport>
    <version>1.2</version>
    <interface>
        <name>ISupplicant</name>
        <instance>default</instance>
    </interface>
</hal>

When I use grep to do a look for the string wifi.supplicant I get the following output:

rick@rick-MS-7B98:~/Documents/Android_aosp$ grep -FR --include=manifest.xml "wifi.supplicant"
out/target/product/db410c/obj/ETC/vendor_manifest.xml_intermediates/manifest.xml:        <name>android.hardware.wifi.supplicant</name>
out/target/product/db410c/gen/ETC/vendor_manifest.xml_intermediates/manifest.xml:        <name>android.hardware.wifi.supplicant</name>
out/target/product/db410c/vendor/etc/vintf/manifest.xml:        <name>android.hardware.wifi.supplicant</name>
out/target/product/db410c/vendor/etc/vintf/manifest/manifest.xml:        <name>android.hardware.wifi.supplicant</name>
grep: out/target/product/db410c/root/d: Permission denied
device/linaro/dragonboard/manifest.xml:        <name>android.hardware.wifi.supplicant</name>
grep: warning: external/autotest/venv/autotest_lib: recursive directory loop
external/wpa_supplicant_8/wpa_supplicant/hidl/1.3/manifest.xml:        <name>android.hardware.wifi.supplicant</name>

The file external/wap_supplicant_8/wpa_supplicant/hidl/1.3/manifest.xml is quite short and appears to have a hal entry that is similar to that in device/linaro/dragonboard/manifest.xml except that the version number is different.

<manifest version="1.0" type="device">
    <hal format="hidl">
        <name>android.hardware.wifi.supplicant</name>
        <transport>hwbinder</transport>
        <version>1.3</version>
        <interface>
            <name>ISupplicant</name>
            <instance>default</instance>
        </interface>
    </hal>
</manifest>

At this point it appears that I have an inconsistency between the linaro content and the Android AOSP content and I have no idea as to:

which version is appropriate
if I change one or the other what is the impact of that change

Do you have any advice?

molejnik · November 20, 2020, 9:53am

I had the same issue. I can’t answer your questions because I don’t know the right solution. What I did to overcome the build issue is I commented out the section from one of the xml file, so that there were no conflicts (same name of the hal component). I thing there might be another similar section in conflict - after commenting out both them the build succeeded.

doitright · November 20, 2020, 10:50am

Well, since you already know where my work is for the db820c, and you know where to find the upstream repository for the db845c, you can easily scan through recent commits on either and find a change that is relevant to what you have identified.

And to give you another hint, which way do version numbers count… Up or down? So between 1.2 and 1.3, the newer one would be…?

Richard_Chambers · November 20, 2020, 1:14pm

@doitright Since the version numbers come from two different files in different directories are they describing two different software components that are being included with one being compatible with the DragonBoard 410c and one that is not?

The idea of just going with the newer one because it is the newer one is not a rational, evidence based decision but just a wild assed guess.

I’ve scanned through the comments for the db820c and see nothing that appears relevant to the db410c and Android AOSP. It all appears to be for Android Automotive.

Richard_Chambers · November 20, 2020, 1:18pm

@molejnik Could you provide details about the changes you made to have a successful build?

Which section of which xml file did you comment out?

You mention another similar section with a conflict and I’d like to know what that was, if you can remember. I suppose once I have a work around for this build failure, I will run into the second one you mention however I would like to address both at the same time if possible.

Also you mentioned that the build succeeded however were you able to use the resulting image with your DragonBoard 410c and boot successfully? What testing did you do to determine if the resulting build was usable?

doitright · November 20, 2020, 2:12pm

Yeah, that is sure to get somebody to hand over the answer on a silver platter. Everybody else seems to have it working, its just you who is failing.

You’ve been pointed to the solution several times, but you now insist that the solution is just a “wild assed guess”. Question it, or try it. YOUR CALL.

If you insist on something that is “evidence informed”, then feel free to read the source code for the components you are having trouble with. Nobody is going to write a doctoral thesis on the matter for you.

Richard_Chambers · November 20, 2020, 4:59pm

@doitright My bad. Thought I was dealing with someone who may be able to help me however I should have realized from other posts of yours on this discussion site that you weren’t really into helping people. It’s ok, helping others isn’t everyone’s strong suit. Sorry to have disturbed you.

@molejnik I have done the following:

I modified the manifest.xml file with the version 1.3 to comment out that entry. That file is external/wpa_supplicant_8/wpa_supplicant/hidl/1.3/manifest.xml and it contains only a single hal directive for the wifi.supplicant

Restarted the build and it failed again with a similar error this time with wifi.hostapd again with a version difference, this time 1.1 versus 1.2.

checkvintf I 11-20 08:35:37    41    41 HostFileSystem.cpp:43] Fetch 'out/target/product/db410c/vendor/etc/vintf/manifest/android.hardware.wifi.hostapd.xml': OK
checkvintf E 11-20 08:35:37    41    41 VintfObject.cpp:67] getDeviceHalManifest: status from fetching VINTF information: -2147483648
checkvintf E 11-20 08:35:37    41    41 VintfObject.cpp:68] getDeviceHalManifest: -2147483648 VINTF parse error: Cannot add manifest fragment /vendor/etc/vintf/manifest/android.hardware.wifi.hostapd.xml: HAL "android.hardware.wifi.hostapd" has a conflict: Conflicting major version: 1.1 (from /vendor/etc/vintf/manifest.xml) vs. 1.2 (from /vendor/etc/vintf/manifest/android.hardware.wifi.hostapd.xml). Check whether or not multiple modules providing the same HAL are installed.
checkvintf E 11-20 08:35:37    41    41 check_vintf.cpp:464] Cannot fetch vendor manifest.
checkvintf I 11-20 08:35:37    41    41 check_vintf.cpp:467] Checking vendor matrix.
checkvintf I 11-20 08:35:37    41    41 VintfObject.cpp:57] getDeviceCompatibilityMatrix: Reading VINTF information.
checkvintf I 11-20 08:35:37    41    41 HostFileSystem.cpp:43] Fetch 'out/target/product/db410c/vendor/etc/vintf/compatibility_matrix.xml': OK
checkvintf I 11-20 08:35:37    41    41 VintfObject.cpp:63] getDeviceCompatibilityMatrix: Successfully processed VINTF information
08:35:39 ninja failed with: exit status 1

#### failed to build some targets (01:11 (mm:ss)) ####

So in the file external/wpa_supplicant_8/hostapd/android.hardware.wifi.hostapd.xml I made a similar change of commenting out the single hal directive for wifi.hostapd and once more restarted the build.

Now I have a failure which appears to be due to some missing content. There are a number of logs that show a status of OK and then there is this set of logs of HALs in device manifest not declared.

checkvintf I 11-20 11:29:01  3558  3558 HostFileSystem.cpp:43] Fetch 'out/target/product/db410c/system/system_ext/etc/vintf/manifest.xml': OK
checkvintf I 11-20 11:29:01  3558  3558 HostFileSystem.cpp:54] List 'out/target/product/db410c/system/product/etc/vintf/': NAME_NOT_FOUND
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:327] The following HALs in device manifest are not declared in FCM <= level 2:
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.audio.effect@4.0::IEffectsFactory/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.audio@4.0::IDevicesFactory/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.bluetooth@1.1::IBluetoothHci/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.cas@1.2::IMediaCasService/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.configstore@1.1::ISurfaceFlingerConfigs/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.drm@1.0::ICryptoFactory/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.drm@1.0::IDrmFactory/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.gatekeeper@1.0::IGatekeeper/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.graphics.allocator@2.0::IAllocator/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.graphics.composer@2.2::IComposer/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.graphics.mapper@2.1::IMapper/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.health@2.0::IHealth/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.keymaster@3.0::IKeymasterDevice/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.media.omx@1.0::IOmx/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.media.omx@1.0::IOmxStore/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.memtrack@1.0::IMemtrack/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.soundtrigger@2.0::ISoundTriggerHw/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.wifi.hostapd@1.1::IHostapd/default
checkvintf I 11-20 11:29:01  3558  3558 check_vintf.cpp:330]   android.hardware.wifi.supplicant@1.2::ISupplicant/default
checkvintf E 11-20 11:29:01  3558  3558 check_vintf.cpp:556] No such file or directory: Cannot find framework matrix at FCM version 2.: No such file or directory
[  3% 582/17259] target Dex: Browser2
Warning: An API level of 1000 is not supported by this compiler. Please use an API level of 30 or earlier
11:29:05 ninja failed with: exit status 1

#### failed to build some targets (02:03 (mm:ss)) ####

Interestingly enough the last two, android.hardware.wifi.hostapd and android.hardware.wifi.supplicant, involved the previous build failures where I commented out the later version of the hal directive.

I’m going to take a look at some of the documentation such as Manifests | Android Open Source Project as well as HAL Introduction which describes the Hardware Abstraction Layer mechanism.

doitright · November 20, 2020, 5:05pm

Oh look, maybe if you READ THE FILES YOU’VE BEEN POINTED TOWARDS, YOU’D SEE THE SOLUTION.

But nah, the only thing you’re willing to accept is something peer reviewed.

molejnik · November 20, 2020, 6:38pm

Which section of which xml file did you comment out?

In my case (android 10 and 11) it was:
out/target/product/db410c32_only/vendor/etc/vintf/manifest.xml

I commented out the whole 2 sections starting at:

<!--
<hal format="hidl" >
 <name>android.hardware.wifi.hostapd</name>
 ...
</hal>

and  
<hal format="hidl" >
 <name>android.hardware.wifi.supplicant</name>
 ...
</hal>

-->

I will run into the second one you mention however I would like to address both at the same time if possible.

Correct. The other one was wifi.hostapd, but you already bumped into that.

were you able to use the resulting image with your DragonBoard 410c and boot successfully?

Yes, I was able to build and run:

android 11: unusable after ~4 minutes of use, the UI locks up. I suspect lack of RAM memory on DB410c, as the console printed oom killer every time the UI froze
android 10: runs, but does not get into UI stage, there is some issue with a gatekeeper service preventing it to progress further in the boot
doitright’s android 10 auto: built from his/her public branch (thanks for sharing the source btw.). This works and boots on Dragonboard 410c, no UI lock-ups. The graphics on that build for DB410c has severe issues: missing semitransparent UI layer (broken graphics) and bugs related to 3D rendering (which are used to render UI) that produce flickering triangles on the screen every now and then, when an animation happens on the screen. I suspect is because of using the freedreno driver.
codeaurora’s android version 7: it does not support DB410c, but can build a ‘generic’ msm8916_64 target. Build finished and booted on DB410c, but I was not able to get to UI. It looks like the init.rc scripts need to be modified to run on a non-phone device.
codeaurora’s android version 6: patched and supported by Qcom to run on DB410c. Builds and generally works OK, but it is an ancient version with very old kernel and missing security patches.

Richard_Chambers · November 20, 2020, 7:15pm

@molejnik Thank you for all of the nice details of your experiments.

I think that I’ll just stick with the standard Android 5.1 99 build that is available and do some work with Android Studio and Kotlin for learning Android app development for now.

I can always do a JNI component and drop into C++ to handle operating services for GPIO work if necessary. I’ve already done that sort of thing as a prototype for GPIO events and should finish that up with Kotlin coroutines.

And every once in a while I’ll spend some time with the Android AOSP source tree. It looks like if I could pick up a supported device cheap, I could just do that rather than trying to move mountains.

Again, thank you for your notes.