Broadcastradio HAL on Hikey970

Products Support HiKey970
#1

Hi, I hope somebody on here can help me.

Im trying to build a broadcastradio 2.0 HAL for AOSP Automotive 9.0.0_r8 based on the rtlsdr library.
Currently I’m struggeling with telling aosp to use my implementation (copy of default for now) instead of the default on.

I copied the files into a seprate directory, renamed the service and .rc file to xxx@2.0-service.rtlsdr, and also renamed the .bp entries accordingly.
But AOSP doesn’t want to register it as a hal service.

Does anybody know what I’m missing?

#2

Probably a manifest entry for it.

Feel free to use my (working) hal as a pattern: automotive/broadcastradio · automotive-master · AOSP-Automotive / dragonboard · GitLab

#3

Thank you for your quick answer.
I will try your pattern and will come back to you hiw it worked

#4

make is telling me “vintf_fragments” is an unrecognized property, might be a AOSP 10.0 that I don’t have access to.
Then I will add the manifest fragment to the manifest.xml inside /automotive

#5

still doesn’t register it → it isn’t listed under lshal and the default radio app doesn’t use it.
The default HAL is working…

Do I need a special sepolicy entry or other config somewhere?

Or can it be, if I already build something I need to clear the out folder to build the new one correctly?
Just had the problem, that it didn’t rebuild the default one with edits from my side.

#6

I was definitely using vintf_fragments under 9, but it was master branch, so it could have been something that was added to master but not to release branches of 9.

You definitely need the sepolicy parts for a HAL to load. Even if you set selinux to permissive at the kernel level, Android’s init still uses the policy.

file_contexts: automotive/sepolicy/file_contexts · automotive-master · AOSP-Automotive / dragonboard · GitLab

hal policy: automotive/sepolicy/hal_broadcastradio.te · automotive-master · AOSP-Automotive / dragonboard · GitLab

Note that I don’t define the entire policy in those files, since I’m piggybacking on the existing sepolicy for broadcastradio.

#7

Ok, so in my case it would be something like:

/vendor/bin/hw/android\ .hardware\ .broadcastradio@2\ .0-service\ .rtlsdr u:object_r:hal_broadcastradio_default_exec:s0

and

allow platform_app broadcastradio_service:service_manager { find };

as I use broadcastradio version 2.0

#8

The main part is the first one, which will permit init to start the service. After that is in place, any additional issues will be obvious as they will result in avc denials visible on the kernel or android logs.

#9

Still doesn’t wants to start the service :thinking:
Maybe I’m still missing something…

#10

You do realize that the vendor sepolicy is stored on the vendor partition, right? Means that when you change and regenerate the vendor partition, you have to actually reinstall it.

Are the rc and service files actually located in your vendor partition?
What are the exact paths of these files?
What are the contents of the rc file?
Is there anything showing in the logs?

#11

I run “make” after each edit build the boot.img new and flash the boot, system, cache and userdata afterwards onto the hikey970, that should reinstall it, shouldn’t it?

In the build directories:
…/out/target/product/hikey970/system/vendor/bin/hw/
android.hardware.broadcastradio@2.0-service.rtlsdr

…/out/target/product/hikey970/system/vendor/etc/init/
android.hardware.broadcastradio@2.0-service.rtlsdr.rc

On the target:
system/vendor/bin/hw/
android.hardware.broadcastradio@2.0-service.rtlsdr

system/vendor/etc/init/
android.hardware.broadcastradio@2.0-service.rtlsdr.rc

android.hardware.broadcastradio@2.0-service.rtlsdr.rc

service broadcastradio-hal2 /vendor/bin/hw/android.hardware.broadcastradio@2.0-service.rtlsdr
class hal
user audioserver
group audio

I used logcat and nothing explicitly saying broadcastradio@2.0 in its line, only:
But I haven’t started the Radio App yet with this log.

…
07-30 14:07:08.306 2738 2738 I SystemServer: StartBroadcastRadioService
07-30 14:07:08.306 2738 2738 I SystemServiceManager: Starting com.android.server.broadcastradio.BroadcastRadioService
07-30 14:07:08.306 2738 2738 V BroadcastRadioService.jni: nativeInit
07-30 14:07:08.306 2738 2738 D SystemServerTiming: StartBroadcastRadioService took to complete: 1ms
…

sorry If I miss something obvious, but I’m new to all of this.

#12

No vendor partition on that device then?
If I remember correctly, until Android 10, the build system wouldn’t know to delete obsolete files between builds. So for giggles, you might want to rm -rf out and then rebuild the whole thing. Or if you feel like saving time, you can manually delete obsolete files from the build tree. You might be able to find the appropriate files to delete using ‘broadcastradio’ as a pattern.

And you really ought to consider updating your android tree. release-9 is ancient, especially when it comes to automotive.

#13

True, but Is Android 10 supported for the Hikey970? I only found Android 9 to be recommended by boards96 and there the release 8 version.

I also have to use this board as it is a requirement for my work/thesis.

#14

That’s rough. Android really isn’t supported AT ALL on the hikey970. How did you get coerced into that particular board?

#15

Like I said, it is a requirement for my thesis, was already bought and given to me to work with it :man_shrugging:. Havent released yet Android is not supported at all for it as there are images and a slightly buggy instruction on hiw to build it available from board96.

It’s more of a proof of concept and i got Android automotive to run on it, now only the broadcastradio hal and audio output from the tuner is missing. I can play radio with rtl_fm and aaudio but not over the default radio app so… yeah

#16

Wow.

Ok, so like I said, try to clear out obsolete files and rebuild.

Also, just to get ahead of your questions… Android is not responsible for routing the audio from your tuner to the speakers. When the broadcastradio service is told to begin playback, it will send a request to the audio HAL for a “patch”.

For this, you need a HAL that implements AUDIO_DEVICE_API_VERSION_3_0, which includes callbacks to set_audio_port_config (which will be used for volume controls in automotive), create_audio_patch (which you will use to begin routing audio from the broadcastradio to the speakers), and release_audio_patch (which you will use to STOP routing audio from the broadcastradio to the speakers.

Since it looks like your radio is a USB dongle instead of being wired into a DSP, it means that you’re going to have to do some fun stuff with threads to get it working. In particular, you will need to implement a software mixer thread that takes two+ digital audio streams (buffers), mixes them, and writes them to the speakers, and you will have to implement a radio-read thread that reads from the alsa device associated with your radio and writes it into one of the buffers.

And because Android only has tinyalsa, it means that you’re going to be doing this all manually.

Have fun.

#17

That will be fun…
Also i have only two months left, so double the fun… :sweat_smile:

Rtl_fm includes a thread scheme on how to get samples from the usb dongle, run the math for I/Q samples and “output” them as signed 16Bit (mono I think) samples into a “buffer” array or anywhere i tell the memcpy to do. For my commandline-thing its a aaudio_stream in write mode.

Do I implement the threads you meant inside the Audio HAL?
How do i associate a alsa device with my radio?
… havent really found something about that… :sweat_smile:
Only that I need a FM_Tuner_IN with address “tuner0” as this is what the app is requesting

Seems to be all generic devices inside the audio hal.
Sorry if I ask to much at once but I’m really lost atm. :sweat_smile:

Also thank you for your time and helping me.

#18

Yes, those threads go in the audio HAL.

You can probably learn a lot from my audio HAL;

Now, a few things to note:

  1. My broadcastradio is connected to an external DSP, so I don’t do any manual copying/mixing of audio samples, rather I just use the alsa mixer to tell the DSP to route the audio. You can see where I’m setting the routes, and those will be the places where you start or terminate your radio thread.
  2. I do perform manual copying of audio samples, but this is for bluetooth HFP. You can see my audio loop from line 1127. HOWEVER, I’m not doing any AUDIO MIXING. When its on an HFP call, all other audio is stopped. Also note that because its a phone call, I’m implementing 2-way audio, and audio processing like echo cancellation using webrtc. You obviously won’t need 2-way audio and you won’t need webrtc.
  3. I just recently stripped out some audio mixing components that were causing trouble, but generally worked. So if you stepped back to the previous commit, it might give you an idea how to proceed.

I was presuming that the driver for your radio would have some alsa driver associated with it such that it would present itself AS an ALSA device. If that isn’t the case, then you’ll have to use whatever mechanism the driver offers for obtaining the audio samples. It doesn’t really matter, as long as you can somehow get the samples into memory.

ALSA devices are identified by CARD and DEVICE number. Look at the link targets in /sys/class/sound/ to identify the different cards. Careful here, they don’t necessarily maintain constant ordering if you have multiple cards!

Two months to do this isn’t a great amount of time unless you’re working on it full time.

#19

Thank you this will help a lot.

Im working on it full time, so I might get there in time (hopefully). But I also have to write the thesis…

The “Radio” is a rtl-sdr usb dongle which is directly read by using the librtlsdr, so no real driver here (I think).

I will see how far I get, will take me so time to get back here

#20

Hi @doitright,

What you said above is exactly we have done but with HiKey960 board. Now we want to move to either HiKey970 or dragonboard845c as HiKey960 board is not available in market since we need another one. Which one we can choose?

Can you please let me know which one of the above two has less impact regarding driver adaptation, pin compatibility etc. Can we easily replace the android board to compatible with tuner board? I read it somewhere AOSP is not directly supported HiKey970 board. I also know that Dragonboard845c listed as Google reference board and AOSP provides kernel support as well as board support for this. Also, FYI we used Android 10 for our developement.

Expecting your reply.

Thanks.