The mali drivers.
It used to be in the build instructions, but looks like this command is missing now…
wget https://dl.google.com/dl/android/aosp/arm-hikey960-OPR-cf4e0c80.tgz
tar xzf arm-hikey960-OPR-cf4e0c80.tgz
./extract-arm-hikey960.s
Probably not your problem if it’s working with a different screen though.
Ah yes, I already did this command. I saw that they removed it… Strange.
But the build is correct.
@rubberduck203 also do you know where to find exactly the .jar of car-lib and car-support-lib ?
It is very well established that the hikey960 cannot output accurate clocks for standard HDMI modes (I.e., 1280x720@60 will actually be more like 1280x720@58). If your monitor is especially sensitive to timing, it will not work on this board.
Ahh … In fact, I tried with 1600x600@60 and in the screen where it works it’s displayed like : 1602x600@59.7. Why 1602 ?
out/target/common/obj/JAVA_LIBRARIES/android.support.car_intermediates/classes.jar
Just name it car-support-lib.jar when you copy it into the lib directory of your Android studio project.
@doitright
Got a problem with the bootanimation. It’s not showing anymore and I did not change anything on it. It’s a black screen now and then system shows directly.
Do you know where can come the problem ? Do you have the same issue from the last commit or smething ?
Probably all the resolution stuff you’re playing around with.
Or your monitor might just not be fast enough turning on. The boot animation only runs for <5 seconds.
Let me better tell you what’s happening.
I have 2 screens, one (Screen 1) that works 1920x1080@60 and the other (Screen 2) which works with 1280x720@50.
When I flash an image that I compile with HDMI_RES=1280x720@50 and I have my HDMI cable into the Screen 1, the bootanimation is not showing but the system appears after 5 seconds and works correct. Then if I plug the HDMI cable into the Screen 2 I’m able to see the system also.
But if I reboot and I still let my HDMI cable into the Screen 2, I have some flashes on the screen and the system does not appear but I’m able to make commands.
After I did a “top” I see the “bootanimation” process still running. So I thought this process avoids the system to show so I killed it and I got a big crash from the SurfaceFlinger, and the system reboots on fastboot.
Here is the trace after the “kill pid_of_bootanimation” and this error appears sometimes when I boot normally. Maybe that needs a fix ?
https://gist.github.com/AhmedX6/4b374f5e4fa4f43bc1ddfb9a2fde163c
Crash bootanimation direct after reboot : https://gist.github.com/AhmedX6/f484e0e345262d4e7ac91e2663ccded6
If you set it for 1920x1080@60 and plug in screen 1, everything works normally?
Yes 1920x1080@60 works with Screen 1 (but not with Screen 2)
For me, when I plug the HDMI cable into Screen 2 after complete boot with Screen 1 the HDMI negociation is not called again, that’s why it works without any problem.
Problem comes when I keep the HDMI cable into Screen 2 and let the reboot complete with that screen. The negociation (maybe) makes that kernel panic happens
Then you probably should create a new thread to address this, since it isn’t associated with automotive work.
It’s not a hardware problem ?
Is it possible to update the BSP of the Hikey to support 1920x720 or 1600x600 resolution ?
If by “hardware problem”, you mean “hardware limitation”, it could be. But the point is that debugging every individual monitor and display configuration is way outside of this topic and not something I can address properly with you.
That could be a limitation, indeed.
I addressed to google the bug I’m facing, I’ll let you know if they respond. That could be interesting. Because automotive’s screen often are with those resolutions (1920x720 or 1600x600)
As I’ve mentioned before, those would be terrible aspect ratios for any purpose, especially automotive. You wouldn’t be able to fit the on-screen keyboard in there because its far too short relative to its width.
Hello,
I would like to validate the Vehicle HAL.
I have develop a little simulator that push some datas into sockets (speed, fuel level, positions latitude/longitude).
I know that I have to create my own HAL on this file hardware/libhardware/modules/vehicle/vehicle.c
I don’t understand very well the implementation of this file and where can I put a little C socket client that will get the datas and set them to notify applications that there are some new values.
Then, from the High Level (from an app) I would like to retrieve the new values from The CarSensorManager and display it (this part should work already)
A little help would be appreciate to better understand the architecture.
Thanks a lot.
That’s actually the old HAL.
The new implementation is in hardware/interfaces/automotive/vehicle.
Why Google does not update their documentation 
? I’ll check for it. Thanks
I just checked this implementation and it seems to be good.
I noticed that there is the class SocketComm which will open a Socket Server.
SocketComm opens a socket via adb’s TCP port forwarding to enable a Host PC to connect to the vehicleHAL The port is 33452
I would like to test that. But it seems that the service android.hardware.automotive.vehicle@2.0-service (located in /vendor/bin/hw) is not started so I cannot connect to it. When I execute : service check android.hardware.automotive.vehicle@2.0-service, it’s not recognized as a service … (not found)
How to start this complete implementation ? I see also that there is a FakeValueGenerator. Maybe I won’t need to use my custom one.
Thanks for help.
This is a bit of process.
It’s been a while since we were using the default vehicle impl, so these instructions might be a bit out of date.
Inherit from the car product in the device makefile (device/linaro/hikey/hikey960.mk):
$(call inherit-product, packages/services/Car/car_product/build/car.mk)
The vehicle HAL (android.hardware.automotive.vehicle@2.0) and other required services/apps are included through car.mk
In order to get the HAL to appear in the binderized section of the lshal command, we must:
device/linaro/hikey/hikey960/BoardConfig.mk):BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive
Do this in a terminal window you don’t mind losing.
Backgrounding like this while inside an adb connection will cause you to lose it.
Note that this will not work if you pass the command to adb shell.
It must be an interactive shell to work properly.
adb shell
/vendor/bin/hw/android.hardware.automotive.vehicle@2.0-service &
To prevent this warning in the logcat logs add the vehicle HAL to the manifest.xml (device/linaro/hikey/manifest.xml)
https://source.android.com/devices/architecture/vintf/objects#device-manifest-file
ERROR:
The following error occurred when manifest.xml defined ‘hikey.hardware.automotive.vehicle’
‘/system/bin/hwservicemanager: getTransport: Cannot find entry android.hardware.automotive.vehicle@2.0::IVehicle/default in either framework or device manifest’
<hal format="hidl">
<name>android.hardware.automotive.vehicle</name>
<transport>hwbinder</transport>
<version>2.0</version>
<interface>
<name>IVehicle</name>
<instance>default</instance>
</interface>
</hal>
Don’t forget to rebuild the device and re-install.
Finally, in order for init to automatically start the hardware service on boot, we need to add an SELinux domain and file context.
(Even though we’ve set SELinux to permissive, it is still enabled. Android does not allow disabling SELinux, only making it more permissive. So, there is still a minimal amount of configuration to be done.)
Create a *.te file for the hardware service that defines the domain.
device/linaro/hikey/sepolicy/hal_vehicle_hikey.te
# vehicle subsystem
type hal_vehicle_hikey, domain;
# may be started by init
type hal_vehicle_hikey_exec, exec_type, file_type;
init_daemon_domain(hal_vehicle_hikey)
Then add the domain to the executable to the domain.
device/linaro/hikey/sepolicy/file_contexts
/system/vendor/bin/hw/android\.hardware\.automotive\.vehicle@2\.0-service u:object_r:hal_vehicle_hikey_exec:s0
packages/services/Car/tests/vehiclehal_test/src/com/android/car/vehiclehal/test/) to PRODUCT_PACKAGES in the device makefile (device/linaro/hikey/hikey960.mk):PRODUCT_PACKAGES += VehicleHALTest
adb shell am instrument -w com.android.car.vehiclehal.test/android.support.test.runner.AndroidJUnitRunner
KitchenSinkApp
sensors menu itemsensors view should show the generated HAL values for Speed, RPM, and Odometer that the tests trigger