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

Pre-installed YouTube TV, You don’t need to install it form Google Play.

Please be clear - I’m talking about YouTube “TV” - NOT “YouTube” .

YouTube TV is a paid subscription Live TV service.

Please try this app for Youtube TV Live
https://github.com/yuliskov/SmartYouTubeTV/releases/download/6.16.89/SYTV_Vlive_v6.16.89_r.apk

It is for the Youtube TV service here.

For normal Youtube without ads try this version, it can be installed alongside the one from the Play Store.
https://github.com/yuliskov/SmartYouTubeTV/releases/download/6.16.95/SYTV_Orig_v6.16.95_r.apk

This seems to be resolved now as Apps came down ok, I did turn of AUTO-UPDATES on google play as advised online so we will have to see what happens when this is turned back on.

Pre installed apps respond well

Love the Power button, so I use DOWNLOAD which takes me to the ROCKCHIP LOGO and then I power off, assume this is the correct option??

Did notice :

Google Play Store - when you click on Search it crashes the app and it closes.

Might be my remote but this did not happen on other distros but pressing the RIGHT ARROW to move right seems to jump fast and scroll a little.

Is there anyway to upgrade from nougat to this ?

Hi, Currently does not support OTA upgrades, You can use other TF cards or emmc module.

Thank you, We will fix Google Play crashes when click on Search.
Are you using a Bluetooth remote?

Thank you about Google play … must admit the performance is amazing on the PI 4 with 4GB … Games like Asphalt 8 run very smoooth …

“Might be my remote but this did not happen on other distros but pressing the RIGHT ARROW to move right seems to jump fast and scroll a little.”

Yes I am using a bluetooth remote/keyboard but using their usb dongle.

I also have an issue using a Bluetooth Gamepad when once a button is pressed it loops and keeps perforaming that action over and over … wonder if there is a conflict with the on board Bluetooth maybe ??

AUTO-UPDATES Is now back on and all is still working well with those auto updates being done successfully and other apps installing around them.

Hi, tested lastest, hdmi audio not working properly, only in youtube at super low volume, playing videos with integrated player no sound, the other video player dont work, cant install apk"s (tried disabling verification), playstore search broken, one of the blue usb dont works (tried changin otg/host), downloaded kodi from playstore and dont work too, tried playing mp3 dont work integrated app.
Would be great android 9 (no tv) image with magisk in, and all working properly, for me is enough, or a crome os is avalaible for others rk 3399, would be great too, crome os can execute android and linux apps, cya.

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

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.

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…

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.

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.

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.

@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.

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

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.

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.