Query regarding running Android on DM814X using DVR-RDK

DVR RDK is entirely user space code so there isn't much effort to port to Android if you already have EZSDK functional. Only posix phtread APIs are used by dvr rdk library code.

From getting a full DVR system functional the main challenges will be:

1. Stable Syslink support on Android.  If you already have syslink functional reliabily on Android you should be fine.

2.A huge number of device specific fixes have been done in SATA/USB/EMAC/Nand drivers and are part of the Linux psp used in DVR RDK . You will have to merge in these to the android kernel if they have not already been merged. I don't know enough to know if it is possible to merge these linux device drivers to Android kernel.

3. DVR app (not the dvr_rdk library) uses QT for all GUI . I assume you will use UI from Android and not use QT. If you are using the DVR app then the GUI portion will  have to be modified.

4. You will have to port the ti81xxhdmi.ko,vpss.ko and ti81xxfb.ko which are loadable kernel modules used in dvr rdk . Not sure how simple it is.

5. DVR RDK uses the sysfs entries to configure VPSS parameters like display resolution. You will have to enable sysfs support. Not sure if it is enabled by default.

All of above are not specific to DVR RDK but apply to ezSDK as well. If you already have video pipeline using OMX components functional on Android on 814x getting DVR RDK functional will not be a big effort.

Hi Badri,

I am working with Dharthi and have few questions on the same thread.

1) With reference to you point #2; can you please redirect us to latest kernel tree which has Android drivers + DM81xx drivers (PSP) merged? Rest porting we can do on our own. we would like to re-use the kernel if its already available with some level of integration.

2) If I understand correctly, DVR_RDK does not use OPENMax API but works on Link API and MCFW API. Whereas Android multimedia framework (libstagefright) uses OpenMAX architecture. Do you mean we should implemnet our own multimedia framework in Android based on MCFW or Link APIs?

Regards,

Krunal

Krunal,

Just to add that we have Android for AM38xx/TI81xx devices at this link:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_tii/TI_Android_DevKit/TI_Android_GingerBread_2_3_DevKit_2_0/index_FDS.html

BR
Pavel

Thanks Badri!

Hi Krunal, DHarati,

Please see more inputs from anohter team who works on Android (ARM only)

Major tasks I see here:

-          Android porting involves kernel porting to the right version, SGX porting on that kernel including the VPSS driver interfacing, and PM integration.  This is significant work

-          DVR application (MCFW) and its dependent componeents as discussed by Badri above - have to be ported , UI framework (Qt) to be ported to be ported with Android toolchain. This is significant work

I don’t think we should spend time on this given the returns. Help the customer understand what they really need, and the fact that Linux is a productized solution and porting to Android is a new platform development.

Hope this clarifies on the effort. And I think would be best if they stick to Linux/RDK. There is not much that they cannot do with Linux itself. Moreover given the multiple components involved, some w/o source code we may likely run into major road blocks ! Kindly let us know if we can go on a call with the end cusomter and help convince them here...

Thanks & Best Regards

Feroz

Hi Feroz and Badri,

Thanks a lot for information and inputs. I forwarded it to client. He is going to talk to some more companies and decide on what he wants to do. The main reason he wants Android is for Touch screen interface and good UI.

Regards,

Dharati

Hi Dharthi,

If it is only about Touchscreen and good UI. I think Embedded QT on Linux can serve the purpose.

Regards,

Krunal

Dear All,

Some insightful inputs from Manuel C :

Do you mean something like:

1. have to check Sandbox at kernel and how to enable HW to work with it.

2. create platform library or system library with the correct permission to get accessed by a apk. using platform library with permission file registering classes.

some of the related files with some information, it could change depending on what Android release you are using, platform libraries are not supported in all of them and not all of them newer have the same permission procedure, in JB seems it changes I haven't verify it.

using source code from http://omapedia.org/wiki/4AJ.2.2_OMAP4_Jelly_Bean_Release_Notes
/4AJ22/mydroid/device/sample/apps/client
/4AJ22/mydroid/device/sample/frameworks/PlatformLibrary/README.txt
/4AJ22/mydroid/frameworks/base/data/etc/platform.xml

next directory uses permission and platform library,
/4AJ22/mydroid/device/ti/common-open/s3d/
/4AJ22/mydroid/device/ti/common-open/s3d/frameworks/com.ti.s3d.xml

if you use SYSFS then you only need to set read property and you can access them from Apk.

see next link about security features in Android.
http://e2e.ti.com/support/omap/f/849/p/178679/648158.aspx#648158
or
http://e2e.ti.com/support/embedded/android/f/509/p/190609/683121.aspx


3. how to use Graphics surfaces to show many video in one apk, this instead of using HW overlays.
4. how to manage Android apk to start videoview or mediaplayer objects, have to check that received prepared() before calling start().

5.the implementation could change depending what Android uses, JB-ICs-GB,etc,
some ICS new features are the hability to use surfaces it is not available before this release,
https://e2e.ti.com/support/omap/int_omap/f/794/p/237793/833164.aspx#833164
http://developer.android.com/guide/topics/graphics/hardware-accel.html


other feature available only in JB is Media codecs
http://developer.android.com/about/versions/android-4.1.html
http://developer.android.com/reference/android/media/MediaCodec.html


6. some of the features to check are the signing apk procedures and signing keys,
http://developer.android.com/tools/publishing/app-signing.html
http://developer.android.com/tools/building/index.html

it is needed in order to get #2 working, without signing the permissions are not enabled, at least that were the results from my test time ago for first E2E mentioned post.

7. other thing to check is,there is a special security code that needs to be updated, I read about it some time ago but it would be better for you to check it, it is related to how Sandbox grants access to libraries,

8. the other is the structure of kernel-.c files - .c++ classes files a - .c++ interfases - and then .java files and in between these last 2 the permission and then the apk. if you integrate the code inside the build system then it would not require that strict enforcements.

Best Regards

Feroz