Home > AMLogic, Android, Linux > Android 7.1 Nougat on Amlogic TV Boxes – A First Quick Look

Android 7.1 Nougat on Amlogic TV Boxes – A First Quick Look

Last year, we found out that Amlogic was working on Linux 4.4, possibly for their Android 7.0 Nougat SDK. As a developer who signed all relevant NDAs, Stane1983 has now been working on Amlogic Android 7.0 for a few day, and reported some of his findings.

First Amlogic source code is based on Android 7.1.1 R6 (NMF26Q), but still with Linux 3.14.29, possibly because Mali-T830 GPU drivers are still r11p0, and Linux 4.4 may come later. One good thing is that the Nougat SDK supports 64-bit Android OS instead of the 32-bit Android we are all currently using in our TV boxes. A not-so-good news is that internal storage partitions have changed, which means most current TV boxes are unlikely to get an update, becau it may not be possible to perform OTA updated, and instead would require an updated via Amlogic USB burning tool.

Click to Enlarge

But let’s look at the user interface and settings. The default launcher has not changed, but if you click on the Settings icon, the Settings will appear on the right of the screen. Note that this only work with the default launcher, other launchers will not be able to open Settings that way, at least in the current version of the SDK, and there are some inconsistency in the way settings are displayed with some shown “Android Marshmallow style”. Hopefully those issues will be addressed before reaching end-users.

Another new mysterious new feature is “Upgrade bluetoothremote”, which asks you to select a Bluetooth device, but it’s unclear whether it is for smartphones, or Bluetooth remote control will start selling with TV boxes.

The normal Android 7.0 Settings app will open from the app drawer, i.e. it will work with any launcher, but currently sub menus will crash, so it still needs some work.

The default browser is Browser2, basically WebView component tester. Not exactly ideal, but Nougat does not come with a browser by default, so you’ll need to install your preferred one, or maybe the manufacturers will add it themselves to their firmware.

Media playback still have some issues, but Stane did not test into details saying to “wait for CNX to get one of boxes with Nougat installed”. I guess that must be me, and I have some work to do once it is released :).

Developers will also need to be aware the way to handle remote control codes has changed. The /system/etc/remote.conf is gone, and instead Amlogic defines the codes in a specific DTSI (Device tree) file  for remote code that includes definition for 3 remotes and starts with:


It looks to be the standard way IR remote controls are handled in mainline Linux kernel, at least the top section, but it may not be so common to declare maps within a DTSI file…

Finally, Stane could also update Amlogic SDK to Android-7.1.1_r26 (NOF27C) instead of r6 (NMF26Q), so developers can always make sure the latest minor version and security patchsets are included. Based on his feedback, it may still take a few weeks or months before we see Amlogic S9xx devices sold with Android 7.0.

  1. March 14th, 2017 at 17:47 | #1

    Somewhat related. Khadas developers will meet with Amlogic about open source in the next few days.
    There are asking for your input first @ http://forum.khadas.com/t/voices-from-the-open-source-communities-will-be-passed-to-amlogic/376

  2. March 14th, 2017 at 19:38 | #3

    @Stane1983
    OK I see, the IR driver is defined in the DTS, but the key would be mapped somewhere else.

    I noticed a map name is defined in Allwinner tree:

    But I’m not sure how they load the key codes from there.

    Edit: That’s here: http://lxr.free-electrons.com/source/include/media/rc-map.h

    So rc-map-name just defines the protocol used, not key mappings.

  3. Miguel Mayol i Tur
    March 14th, 2017 at 19:56 | #4

    What does it mind : Internal Storage Partitions has changed …? and it will be not possible to upgrade Over The Air.

    I switched my ZUK Z2 phone from ZUI (Android 6) to Dirty Unicorns (Android 7) without changing partitions.

    I suppose there is always a way to upgrade via OTA, even if it is with a previous APK that changes the partition scheme if needed and then flash the downloaded zip file or some other kind of programming work.

  4. March 14th, 2017 at 20:03 | #5

    Hopefully the aml side of things is better than Rockchip, where with Nougat, just as before, public methods continue to be bypassed in favor of shoddy, gimped private methods and internal apis that lead to nowhere.

  5. Neil Stevenson
    March 14th, 2017 at 21:17 | #6

    It would be great to see nougat on Samsung s7 on EE as we are still waiting grrrrrrrrrrrr

  6. March 14th, 2017 at 23:15 | #7

    @Miguel Mayol i Tur
    It means that 99% of manufacturers/resellers will probably go with new product than modifying Nougat to match existing partitioning scheme to fit there at least 32bit OS. I did not checked (compiled), but I think 32bit OS would fit 1GB system partition.

    And you can’t really compare phones with these boxes. If there is no effort from manufacturer – you’re out of luck. Or if they release IMG file for that same device (to be used with USB Burning Tool) you’ll have to wipe everything and go from scratch.

  7. Scooter2014
    March 14th, 2017 at 23:26 | #8

    Nice that this coming to set boxes. I would have liked to more device manager access for different wifi/bluetooth in one firmware base. The fact that they are still using the 32 bit not 64 bit and not using the full chip potential.kinda like building farrai and installing 4 cylinder engine.

  8. Theguyuk
    March 15th, 2017 at 01:04 | #9

    Just how long is the retail life of these devices, at the lower end replacing is easier, as millions use the boxes, but are not into hardware and reinstalling the firmware.

  9. mdel
    March 15th, 2017 at 05:08 | #10

    out of curiosity does amlogic have anything to say about baylibre mainlining efforts ?
    do they care that a mainline kernel will run on their latest socs ?

    [ i know nothing about the relationship between linux kernels and android sdk, can you use a mainline kernel on an android system ? I know that there are android-centric kernel config options so android probably has its own kernel branch.. ]

  10. March 15th, 2017 at 09:07 | #11

    @mdel
    Based on a comment, Amlogic has contracted BayLibre to work on mainline, so – if true – they are very much involved.

    I’ve never seen mainline on Android, normally Google selects a LTS kernel for an Android version, and works from there. But based on some talks at ELC, this could possibly change in the future.

  11. Chris
    March 15th, 2017 at 10:17 | #12

    @cnxsoft

    While getting everything into mainline might not help for Android 7, since its already released, it should help going forward for the next Android version, etc. It will also help for other linux distribution releases.

  12. March 15th, 2017 at 11:32 | #13

    @Chris
    You’re partially right. I expect next SDK release or release after to have kernel 4.4. Similar thing happened to Lollipop, they bumped from 3.10 kernel to 3.14 after initial sdk was already released. First signs of 4.4 kernel were available on openlinux website some time ago when amlogic I guess by accident released buildroot for 4.4 kernel but without actual kernel. Another fact is that there are a lot of commits in SDK that indicates bump to 4.4 kernel (eg. wifi and gpu drivers do have commits like fix compile for 4.4 etc).

  13. Gonna
    March 16th, 2017 at 11:12 | #14

    Minix developper “ken” just confirmed to me on their forum that their U9 Will get android 7 update in 2017 probably..so great news

  14. NIPSZX
    April 12th, 2017 at 12:58 | #15

    Does anybody know what the max Android is on a cx-s806?

    Does anybody have a link to the newest Android images for Amlogic?

    Does anybody have a link to the newest OpenElec images for Amlogic?

    Does anybody know what the best Openelec build is for the Amlogic s812 that has wireless and not wired only?

    Thanks

  15. smith151
    August 24th, 2017 at 00:11 | #16

    How did you get key mappings in decoded remote DTS? I decode DTB by stripping 2048 bytes from meson1.dtb and got hex values only like this:

    dd if=meson1.dtb of=meson1-clean.dtb bs=1 skip=2048
    dtc -I dtb meson1-clean.dtb -O dts -o meson1-clean.dts

    cat meson1-clean.dts
    ….
    keymap = <0x47000b 0x130002 0x100003 0x110004 ….

    And how can I define fn_key_scancode to switch "mouse" mode?

  16. August 24th, 2017 at 09:38 | #17

    @smith151
    That’s because he did not need to decode the DTS, he got it from the SDK…
    The REMOTE_KEY macros converted those into actual values in the DTB, so that’s what you get when you decode it.
    You need to press the key on your remote control, and check the logcat to match the key code.

  17. smith151
    August 24th, 2017 at 09:56 | #18

    @cnxsoft
    I know scancode of “mouse mode” key. My question was about how can I define “define fn_key_scancode” analog of remote.conf in DTS file?

  1. No trackbacks yet.