[ROM][Android9.0][RockPI 4A/B] Android TV firmware released

#32

I’ve been able to get hardware accelerated KODI working on this build now!!!

Sort-of.
I actually used RKMC, but with the rockchip “special sauce” in it disabled.

Here is how to do it;
You download your official RKMC from here:
https://github.com/JamesLinEngineer/RKMC/blob/Jarvis/RKMC-Build/rkmcapp-armeabi-v7a-debug.apk

Now you launch it. It will complain about broken or missing libraries. That’s ok – just ignore it.
Go into System --> Settings --> Video --> RKMC and DISABLE EVERYTHING.

Now it will work. Including hardware acceleration.

ABOUT HARDWARE ACCELERATION, and why it now works without the RK hacks;
It seems that for the Android 9.0 release, RK has finally, CORRECTLY implemented MediaCodec/libstagefrighthw. So when you disable the RK acceleration hacks, it falls back to the now-working MediaCodec path.

I verified by playing a 1080p HEVC that neither my Nexus Player nor Razer Forge are capable of playing. It played PERFECTLY. Not the slightest hint of choppiness, and the playback CPU load is reasonable. Less than 50% of one core during playback of 1080p HEVC, which would be impossible without hardware acceleration.

I don’t know (yet) what RKMC does to avoid the EGL crash that the official kodi builds exhibit – I even tried the same version. I’ll compare the source against the real kodi and see what they changed in that regard. Hopefully, it will be something easy to reproduce in 18.x.

Ah, even better… SPMC works! No pirate crap and no need to muck around with settings.

http://download.semperpax.com/spmc/android-arm/SPMC-17.6a2-spmc-ed022ef-armeabi-v7a.apk

1 Like
#33

Regarding the HDMI LOW VOLUME issue:
This comes down to Android being configured to use a software volume controller. This kind of makes some sense, since the rockpi4 has a headphone jack. However, it really shouldn’t be done in software, it should be done using a hardware mixer.

Anyhow, this issue is REALLY easy to work around. Just plug in a USB keyboard that has volume buttons, and raise the volume to maximum.

#34

Regarding the volume issue (fixed with latest builds)
For the “tv box” builds, this property should be set in the overlay at frameworks/base/core/res/res/values/config.xml:
<bool name="config_useFixedVolume">true</bool>

That will force the volume stream to 100% and disable software volume controls, and is consistent with Asus Fugu (Nexus Player) : https://android.googlesource.com/device/asus/fugu/+/refs/heads/master/overlay/frameworks/base/core/res/res/values/config.xml#3

Added July 6:

@lili : Looks like we again have a problem with EGL and Kodi. The updated libGLES_mali.so libraries that another member obtained don’t seem to work this time – won’t boot with them. Still good with home baked Kodi with new package name.

And a very simple/easy request: The devicetree for rock960-c activates 4 very bright green LED lights. They default to ON and are extremely distracting. Could you please switch them off by default?

This file, lines 236, 242, 248, and 254 – just change them from “on” to “off”:

CEC is still not working…

#35

Hi lbdroidman
CEC not have test environment. We test as soon as we have a test environment.
I will adjust the led of Rock960, thank you.

#36

I can give you any logs you require, if it would help.

Just about any television made in the last 10 years should have CEC.

#37

I think I might know why CEC isn’t working.
I found this older thread;

And it looks like that patch, which implements a pin control for hdmi_cec, hasn’t been applied to the kernel for Android 9.

#38

@Lili : I duplicated that commit to my kernel, and I’m now seeing a lot of CEC traffic via logcat, so I will confirm that it is definitely needed and that it fixes CEC, at least at the kernel level. I haven’t had a chance to go further and actually test that SBC and TV behavior are as expected. I’ll try to do that this evening.

EDIT: I have now tested CEC function with two TV’s. It is working with PHILIPS TV, it is NOT working well with VISIO TV, HOWEVER, Nexus Player also doesn’t do CEC well with VISIO, so I think that is more to do with the TV than the CEC.

To the &hdmi { block:

	pinctrl-names = "default";
	pinctrl-0 = <&hdmi_i2c_xfer>, <&hdmi_cec>;

So that change will have to be added for all three supported devices;
RockPi-4
Rock960AB
Rock960C

I did get hung up for about an hour on an unexpected glitch; when Android is installed to the eMMC, it will not boot Android from the SDCARD. On the console, I see it load the kernel, and then jumping to rockusb mode. I had to pop off the eMMC for this testing. I suspect that it is because two block devices have partitions with the same names. These name collisions probably confuse it.

Hmm, so fstab is a bit complicated in this state of Android. Split between the kernel devicetree and the actual fstab files.

In the kernel devicetree, the vendor partition is hardcoded as /dev/block/by-name/vendor, which is probably bad. The paths are similarly coded in the fstab files. This means that it has the opportunity to get confused when there are multiple devices containing the same partition names.

Now the actual devices can be tracked separately using paths /dev/block/platform//by-name/, which would work fine for the fstab files, but not for the vendor partition specified in the devicetree. I think that would have to be moved from the devicetree to the ramdisk.

Regarding userdata forced encryption;

# Full disk encryption has less effect on rk3399, so default to enable this.
/dev/block/by-name/userdata                   /data                  f2fs      noatime,nodiratime,nosuid,nodev,discard,inline_xattr                   wait,check,notrim,forceencrypt=/cache/key_file,quota,reservedsize=128M

Even if the effect on the CPU is very small, encrypting the userdata partition is entirely pointless, at least on TV (-box) platform. The reason is because even if it is force encrypted, there is no login key prompt available to initialize decryption. That means that even encrypted, contents of that encrypted partition can be retrieved in a completely trivial manner; Developer options, enable adb-over-IP, adb connect, su, etc.

If anything, forced encryption is an inconvenience for the device owner, since it becomes more involved to access their own data on that partition, where without encryption, simply remove sdcard/emmc and insert to another computer and mount.

Use of “encryptable” in place of “forceencrypt” would be preferred.

#39

Thank you, We have found DTS problems with ece that will be fixed in the next release.

Thank you for your fstab Suggestions. We will optimize this problem (emmc/sd).

1 Like
#40

Hi

For the HDMI CEC problem:
This might also help, I saw it was missing in the SDK.

device.mk
PRODUCT_PROPERTY_OVERRIDES += ro.hdmi.device_type=4

It is needed for Android media players and devices connected to a tv.
For a tv that is also the CEC device like tv’s with built-in AndroidTV OS, they have it set as
ro.hdmi.device_type=0

Build.prop also needs to contain
persist.sys.hdmi.cec_enable=true
so that HDMI CEC is activated automatically at boot.

Then the RockPi 4 SDK is also missing the HDMI CEC permissions so any app can use it instead of just system apps.

Add to
device/rockchip/rk3399/init.rk3399.rc

  • chown root system /dev/cec0
  • chmod 0664 /dev/cec0

Hope it can help.

#41

I don’t think the device type override is necessary. It seems to pick up 4 automatically. I suspect that 4 is the default.

The other part (system property) may be why cec appears to be somewhat hit-or-miss.

I don’t think that the permissions are needed, since to be frank, cec does work. If the permissions were wrong, it wouldn’t EVER work.

#42

@Lili: I’m still seeing the gles crash with Kodi. Do you think you can look at getting the fixed libgles_mesa.so into the build?

Details in this thread;

Thanks

#43

We will communicate with rockchip first. If this is the final solution, we will add it into build.

#44

Hi, thank you for providing us such a good and stable android TV firmware. I have a problem in Vol+ and Vol- button in the remote controller. I also try to adjust volume using a multimedia keyboard, but still doesn’t work. How can I change the volume in android TV 9 ? Many thanks for your help.

#45

@chisteven : You use the remote that came with your television. HDMI outputs are not supposed to be volume adjusted. This behavior is set to be consistent with both HDMI and with Nexus Player (which is the best reference for an “as intended” Android TV box).

This would be different for an Android TV device that is actually built in to a TV or a sound bar, since with those platforms, the HAL will directly be able to signal the amplifier.

Now there is a way around this, which is to integrate the audio HAL with CEC. However, CEC volume control on TV’s is somewhat hit-or-miss, CEC support in RockPi4/Rock960 is not all there yet, and it would require a good amount of work in the audio HAL to implement.

According to documentation; https://source.android.com/devices/tv/hdmi-cec , the audio HAL is expected to hook into CEC for sending volume controls.

And here; https://android.googlesource.com/device/asus/fugu/+/refs/heads/master/libaudio/HDMIAudioOutput.cpp#68 , this is a stub for a function (which is never called from anywhere) that is supposed to actually implement this for Fugu (Nexus Player). Apparently, they never completed the code for it.

And it doesn’t appear that there is any provision at all in the rockchip audio HAL for volume controls. They straight up use the audioflinger soft volume controls.

… EDIT.
It looks like that Fugu code was misleading me. Its not the audio HAL that is supposed to send the command, its the audio SERVICE, which has a link to HdmiControlService. That being the case, nothing needs to be implemented in the audio HAL at all. It might just work, if (a) CEC is working, which seems to, at least partially, and (b) if the TV supports volume-via-CEC.

And HERE is the code that does just that: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/core/java/com/android/server/audio/AudioService.java#1792

And it looks like the only condition on activating that code is having the FEATURE_HDMI_CEC declared in the system (which it is): https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/core/java/com/android/server/audio/AudioService.java#953

Hmm.
Now here is the awkward part;
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/core/java/com/android/server/audio/AudioService.java#1607

Basically means that if we set the device for fixed volume (as Nexus Player does), then the volume-via-CEC code will never be executed. A few weeks ago, I suggested setting that because the volume was essentially not working at all. But now that CEC is enabled, I wonder if it will bypass the software volume control and go straight to CEC?

I’ll have to look into that and see what the right way to handle it is.

#46

Thank you for your reply. Because I use a PC monitor (which has built-it speakers) as a display, there is no remote to adjust the volume.T.T Also, we sometimes use a 2.4 GHz wireless remote controller (Air Mouse) to control the Android TV. Use the remote that came with the television to adjust volume is inconvenient. Therefore, I do hope that the Android TV 9 is allowed to control its volume like Android TV 7! Thank you!

#47

If your monitor can’t receive CEC commands, then there is no way to send it a command to change the volume anyway. Nothing can be done about this. You might want to look into buying an actual television, if you want it to behave like one.

#48

Hi, can it be installed on any TV?
I have a JVC android TV but the Google Services stopped working and the TV is barely usable.
Does any of you know what I can do to fix it?
I can’t even find the original firmware for it.
Thanks

#49

It can be installed on any TV… that has a working HDMI port.

#50

I have tested it on a “real” TV with CEC enabled on both TV and Rock Pi. However, still no response on the volume up, volume down, and the mute keys.

I installed a key mapping app and noticed that the key code of these keys can not be detected, so I mapped other keys to Vol+ and Vol- functions, but still no luck.

If the android system is allowed to send volume commands via HDMI when CEC is enabled, while it is allowed to adjust the system volume when CEC is disabled, that would be great.

This developement board and the firmware is perfect to me, except for the volume issue. :disappointed_relieved:

#51

Like I said, the CEC is hit or miss at this point. I have a TV that responds to CEC volume keys with a Nexus Player, but with this, all I see in the log are errors. I have another TV that doesn’t respond to CEC volume keys on ANYTHING, but all the other CEC is working as expected (i.e., press “HOME” and it powers the TV on and sets the proper input).

What you are suggesting regarding choosing to send CEC vs digitally adjusting the volume, is not possible. This would break volume for EVERY HDMI device that doesn’t support CEC.

Think about it like this; In order to have a digital volume control pre-HDMI, it would require you to set the receiver volume to 100%. Most receivers will hum loudly at 100%, and if you decided to switch inputs to a correctly behaving input, you would find it suddenly blasting sound at maximum volume. That would be HORRIBLE.

If your receiver has its own volume control, then YOU MUST USE THAT VOLUME CONTROL, whether it supports CEC or not. It is contrary to HDMI to digitally manipulate the volume before the wire. HDMI sound output should ALWAYS be full range with 0 dB adjustment.