Android Automotive

doitright · July 20, 2018, 4:26pm

I did not say to try a different branch. I said to try a known good manifest.

AhmedX6 · July 20, 2018, 4:42pm

just need to modify the content of default.xml by the hikey960.xml in .repo/manifests/default.xml
and sync again

That’s it ?

doitright · July 20, 2018, 4:49pm

Yeah, I think that should work.

doitright · July 20, 2018, 4:51pm

Any manual changes you’ve made to any repo could freak out the sync, so just be aware of that and reset any trees that may need some adjustment.

AhmedX6 · July 20, 2018, 4:55pm

Oh yeah you’re right.
Need to remove patch in system/sepolicy/neverallow file (the +hal_gnss)

Do you know any way to reset hard everything with repo ?

doitright · July 20, 2018, 4:59pm

Try this;

repo forall -c "git am --abort"
repo forall -c "git reset --hard"

AhmedX6 · July 20, 2018, 5:00pm

Still have the changes… I see them with repo status.

doitright · July 20, 2018, 5:01pm

You could try reset --hard HEAD or --hard HEAD~5. That should eradicate anything.

AhmedX6 · July 20, 2018, 5:15pm

Perfect ! Also I need to repo forall -c "git clean -f -d" to remove extras files if need

Ok now I’m ready to sync and build with the new manifest.

Can I directly build the hikey960_car ? Or better to build the hikey960?

I started build with the car directly. Will see that later Thanks a lot for your help.

AhmedX6 · July 25, 2018, 1:25pm

Hello @doitright

I was able to build & run with the last manifest on github.
I will test automotive HAL etc to be sure that the remove of the BOARD SEPOLICY DIRS did not break anything.

Thanks!

#EDIT
I did some modifications and after that I rebuilt and I got this error :
device/linaro/hikey/gralloc960/mali_gralloc_formats.cpp:139:7: error: use of undeclared identifier ‘HAL_PIXEL_FORMAT_YCBCR_422_888’; did you mean ‘HAL_PIXEL_FORMAT_YCBCR_420_888’?
case HAL_PIXEL_FORMAT_YCbCr_422_888:
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HAL_PIXEL_FORMAT_YCBCR_420_888
system/core/libsystem/include/system/graphics.h:35:40: note: expanded from macro ‘HAL_PIXEL_FORMAT_YCbCr_422_888’
#define HAL_PIXEL_FORMAT_YCbCr_422_888 HAL_PIXEL_FORMAT_YCBCR_422_888
^
system/core/libsystem/include/system/graphics-base.h:25:5: note: ‘HAL_PIXEL_FORMAT_YCBCR_420_888’ declared here
HAL_PIXEL_FORMAT_YCBCR_420_888 = 35,
Do you know what can be the issue ? This error came after a second rebuild, that’s so weird. This part was not modified at all.

#EDIT 2
I found the issue. I executed the update_makefiles.sh in hardware/interfaces directory because I added a custom data on the vehicle HAL. And that’s updated some values in :
project system/core/ (*** NO BRANCH ***)
-m libsystem/include/system/graphics-base.h
So now, it’s dangerous to add custom data to types.hal and then generates the new .h Did I miss something ?

#EDIT 3
Everything have been fixed. Need to delete some files in the out directory. The system build does not regenerate anything if the previous are still there.

AhmedX6 · August 1, 2018, 12:32pm

Hello,

Got issue with Gnss HAL using the last Manifest.
The boot keeps stuck on bootanimation when my GPS USB is plugged on the hikey.
If I reboot without the GPS Usb it boots correctly.

I’m using CP210X Driver for the GNSS. It was working before I synced with the last manifest.

Do you know what can cause this issue ?

I’m checking the logs but it seems that there is nothing very different…

#EDIT
I removed the Settings application, when I put it again it boots … Wow

doitright · August 1, 2018, 12:35pm

I’ve actually noticed some unending boot animation problems even with the April build. Thing is, its intermittent and usually rebooting will clear it up. Presumably, you’ve noticed the same thing, but its moved from intermittent to consistent. I have not had a chance to debug it, and since I’ve only had it as intermittent, it hasn’t been an enormous priority, at least not with where I’m working at the moment.

I think also you’re using the generic serial GPS HAL, right? I actually haven’t touched that since I got the U-Blox HAL working. The U-Blox HAL is a lot less jumpy and locks on a lot faster thanks to working AGPS.

One thing I did notice, is that if the kernel is overbloated with drivers, the chances of being stuck on the boot animation increases. Possibly something related to boot time? Now of course, reducing the boot time isn’t the “fix”, but it may hint at the issue. I will point out that the USB drivers on this board have been somewhat glitchy.

Other strange things also happen during boot. I’ve seen the USB host mode initialize during boot, then be removed, and reinitialized. If this happens while it is trying to initialize the GPS, i.e., start initializing it and having the device disappear, that could cause the GPS HAL to lock up.

I suspect that your Settings application removal/replacement is a red herring. What you probably experienced, is the intermittent behavior I’ve noted above.

AhmedX6 · August 1, 2018, 2:58pm

When the bootanimation is stuck, it means that the Surfaceflinger did not receive the “BOOT_FINISHED” message from the ActivityManager
https://android.googlesource.com/platform/frameworks/native/+/master/libs/gui/ISurfaceComposer.cpp#566

Details : https://github.com/pfalcon/android-platform-headers/blob/master/android-4.1.1_r1/frameworks/native/include/gui/ISurfaceComposer.h#L150

I did many tests (one image without Settings, an other with Settings) with Settings it boots, without it does not boot. I don’t think it’s an intermittent behavior. Settings is certainly doing additional stuffs that CarSettings does not ? What do you think ?

doitright · August 1, 2018, 3:46pm

Oh, see I read that backwards. I thought you said that it booted withOUT settings. Obviously it makes sense that not having the settings application will cause some things to break.

Now CarSettings… that is very far from complete. I’m not sure if its even worth including it.

AhmedX6 · August 2, 2018, 1:01pm

Yes it seems that the Settings application has a impact on the system.
But how to explain why it boots with application Settings removed AND GPS USB unplugged ?

Yes I’m using the generic serial GPS Hal.

This Hal cannot work with my USB GPS, isn’t it ?

#EDIT
I wanted to share with you, after some investigation, I noticed that the Settings application has an activity named “FallbackHome” that inflate the famous view “Android is starting…”. CarSettings does not have this view. So, that’s why Settings application is mandatory

#EDIT 2
Problem “not booting” is fixed by adding the FallBackHomeActivity to CarSettings.

7atech · August 2, 2018, 10:07am

hi @rubberduck203 , do you know please what is exactly the difference between car-lib and car-support-lib ?
thanks

rubberduck203 · August 2, 2018, 12:58pm

The car-lib is lower level than the car-support-lib. The support library wraps the lower level lib in an easier to use interface.

doitright · August 2, 2018, 1:01pm

I don’t think that we really need to explain that behavior. When the GPS HAL initializes, it obviously needs a positive response from something that involves the settings application, i.e., to notify that there is a GPS present on the system, and then issues a success.

So if the GPS is present, it tries to make that call, but doesn’t get a response, so it ends up stuck there waiting forever. If the GPS is NOT present, it doesn’t need to make that call and therefore doesn’t get stuck on it.

The U-Blox HAL will only work with a U-Blox GPS. From what I understand, all U-Blox GPS’s will show up as a /dev/ttyACMx, and will also spit out U-Blox as manufacturer on the kmsg. U-Blox USB GPS’s usually run around $10-$15 on Amazon.

AhmedX6 · August 2, 2018, 1:02pm

Check my EDIT 2 on my previous post.

doitright · August 2, 2018, 1:03pm

I saw it, interesting observation, but it doesn’t change anything I said.