You are right, but it helps to provide more detailed background information. Unlike Linux, which uses device drivers for GPS on serial ports, android uses a strange concept of “location provider”, which is a userspace reimplementation of a device driver for each specific GPS receiver (in your case u-blox). I think it also prevents using multiple GPS receivers on one machine.
@helg; the thing about GPS is that even Linux doesn’t implement drivers for GPS. At least not beyond the actual serial interface. Typically in Linux, you would use gpsd, which is in a lot of ways no different than a GPS HAL is in Android.
I’m not sure why you are under the impression that Android prevents the use of multiple GPS on one machine. It certainly does not have that limitation. While it is true that Android devices typically have only one GPS (because usually having more than one is superfluous), remember that they can obtain location using alternative methods involving network and cell tower lookups, and more. Usually there is a separate location provider for each method, and they are set up with varying priorities and accuracy.
If you’re looking to use multiple gps sources simultaneously on Android, there are a number of different ways to approach this, including the exact same way that every other Linux device does this; by using gpsd to multiplex them together into a single steaming pile of sawtooth tracks.
As far as the background goes in this topic, remember that he isn’t using generic AOSP. He’s using this, which I set up specifically for automotive use; https://github.com/HiKey960-Car
And believe me, I would not have added the ublox gps hal without provisioning it with everything needed to work. In fact, I added two separate GPS HALs to the code. One a simple serial GPS HAL (which also works with ublox gps units), and one specifically tailored to ublox devices and supporting AGPS.
I do not want to overload this topic with generic GPS and car sensor fusion discussion, but just consider the following: what is really innovative about GPS API in android7.0+ ?
It is “Raw GNSS Measurements” feature
Do you implement it for u-blox: no.
Using two distant separate GPS antennas on a car makes a lot of sense, for example, within the accurate lane positioning and even without dual-band receivers (which are also coming real soon).
Huh? Yeah, you’re way off topic now. Raw gnss and multiple sensors is way outside the scope of (a) this discussion, and (b) any conceivable automotive use.
I’m recompiling everything. It takes some times.
Is it possible to develop an application that will access to vehicle data (like speed, fuel level, etc…) or it’s exclusively for system apps ?
If libvehicle are only accessible through system apps. How can I develop and test without always recompiling the image and flash etc.
Do you know if there any SDK (Vehicle Data) available with an emulator ? So I could test my app and then after I’m sure the app is correct I put on the image.
It wasn’t worth pursuing those features for the general case, since every vehicle will have a completely unique interface. Means that there is no general case except when going at the OBD port, which you can do using a USB or bluetooth OBD dongle and userspace applications. Think along the lines of Torque https://play.google.com/store/apps/details?id=org.prowl.torque&hl=en – there are open source obd libraries that you can use for building things like that.
If you really want to pursue vehicle specific interfaces, you’ll need to look into platform/interfaces/automotive/ and write yourself an automotive HAL for your specific vehicle and whatever hardware you select to connect to it.
Regarding a starting point for actually using the HAL, take a look at platform/packages/services/Car/tests/EmbeddedKitchenSinkApp
Emulator won’t do you much good, since you would also have to compile for that.
I am under the impression that you are running a “make clean” after every change that you make. This is completely redundant and ignores the whole purpose of “make” to begin with, which is that it can find source code changes and automatically clear and recompile only the necessary parts. Further, if YOU know what files are being recompiled, you don’t need to push the entire system image to the device in one shot – you can take a shortcut of pushing only the changed files. Use something along the lines of;
adb root
adb remount
adb push somenewfile /system/locationofoldfile
You can find more details about it here;
https://source.android.com/devices/automotive/
No, i’m not, just only this time, because I have clean my out directory for some reason…
The standard of Google should be enough, isn’t it ? For standard data, I mean (speed, fuel level etc)…
How did you develop this app ? that could be interesting for me.
You use some permissions like : android.car.permission.CAR_SPEED or CAR_FUEL that we cannot use if we develop an Android Auto Application from Android Studio.
I see also some interestings imports like : CarHvacManager
What I’ve been trying to tell you is that there IS NO “standard of Google”. There is “car brand A model A”, there is “car brand A model B”, there is “car brand B model X”, and they are ALL COMPLETELY DIFFERENT.
The ONLY mandatory standardized interface on a car is its OBD port. That’s IT, NOTHING ELSE.
The purpose of a HAL (“Hardware Abstraction Layer”) is to convert between “car brand B model X” and Android. If there was a standard car interface, there would be no need for a HAL.
I had nothing to do with developing that application. That is part of AOSP. I’m just pointing it out to you as a starting point for Application <–> API interface.
I think we are misunderstanding.
I understand that there is currently no standard vehicle interface and each car manufacturer is having its own way to access vehicle data.
As far as I know, when an Android app needs to access vehicle data, this app will use the Android interface (which is standard whatever the car in which the Android system is running into) and I agree that the car manufacturer has to plug its vehicle data on the Android interfaces in order that they can be accessed by a system app.
My question is if I want to develop a system app that will access vehicle data, how can I do that as it seems automotive interfaces are not available into Android Studio (may be because SDK manager only allow to download standard Android SDK and not automotive ones).
May be there is something I didn’t catch in the android automotive app development.
Ok, then you have two things to think about;
- That you can write an application, and it won’t be useful since there is nothing you can run it on that provides the interface (not until car manufacturers or someone else build those HALs),
- If you do want to use the vehicle API, you won’t be able to use Android Studio, you’ll have to write it into the device tree like I did for this; https://github.com/HiKey960-Car/android_device_linaro_hikey/tree/master_mar2218/carconfig
1 Like
You need to know the CAN bus topology in your car, and the message encoding matrix on this specific bus (for example, vehicle speed or even single wheel speed/direction is available in different forms in multiple messages on multiple buses). This is a very vendor-specific information, and the vendor is highly unlikely to help you. The most well-known CAN bus message information is available for the Volkswagen cars (VW,Audi,Skoda,Seat).
Hikey970 board has a built-in MCP2515 (SPI <-> CAN) controller with the bus transceiver, but for hikey960 you need to solder your own external interface.
I don’t know how good are those CAN-USB adapters available on the market, and how well they are supported by arm-linux.
The most generic way will be connecting to an OBD2 BT/WIFI adapter, but OBD2 is also very vendor-specific and limited in hardware monitoring capabilities.
1 Like
helg: If you’re interested in playing around with CAN on the hikey960, seeed has a grove module; https://www.seeedstudio.com/Serial-CAN-BUS-Module-based-on-MCP2551-and-MCP2515-p-2924.html
You’re not the only one working on car. 
You don’t have to do it in tree.
You can use Android studio, you just have to copy the car-lib.jar or car-support-lib.jar out of the build’s intermediates output directory.
Right, well I was actually meaning “can’t” in the context of out-of-the-box.
I did notice that you “starred” the project, but I am curious… If you are working on car, why haven’t I heard any discussion or seen any pull requests from you? A bit of collaboration can really get things moving.
I only have source code car-lib and car-support-lib. I did not find jars files.
@doitright I have some issues with a screen that supports 1280x720 60 Hz . I compiled the boot with HDMI RES to 1280x720 but nothing appears on the screen. I tested the screen with my computer (in 1280x720) and the HDMI negociation pass and I have the display. I don’t find any logs in dmsg or in console that shows if there was any error.
Do you have any idea of what can happens ?
Fair question.
Mostly because we’ve not had anything we feel can be upstreamed yet.
We have submitted a fix for the driving state policy, but it conflicts with Google’s internal branch, so… who knows if it’ll be fixed in P or not.
We’ve been working on building a virtual car on the CAN to demonstrate the HVAC and KitchenSink apps working with data coming in from a physical bus. We’ve been working kind of tangential to the areas you’ve been working on.
I’m very interested in the work you’re doing, but I’ve not really yet had time to take a look for myself.
Does it work with a different screen or cable?
Did you remember to download the proprietary graphics drivers?
