[JonSnow88]

So I'm always on the search for a cheap all in one solution for my media needs. The closest OS that has Netflixs, Songza etc is Android with XBMC loaded. But have yet to find an android device that meet my requirements and have held of for a while. The closet device for an all in one solution was probably the Ouya, but with its audio problems I held of and now its just old dated tech. I have the Asus Chromebox coming in next week to play around with and hoping dual booting openelec and chromeos will give me the all in one solution I'm looking for.

I have read many thread/post that say Android has limitations when it comes to XBMC but no one explains what those limitations are? I have read some are related to framerate or similar but can someone please point out what the limitations are? I know it will vary by hardware but just in general why should one use something like the ChromeBox vs an android stick/box? beside personal preference.

[noggin]

The main limitations with Android are - to me - the following :

1. No automatic frame rate switching. If you watch content with a mix of frame rates (in Europe we watch 24p movies, 25p or 50i DVD, TV etc. and in some cases some 60i Blu-ray/DVD content) and want XBMC to output this at the best frame rate for viewing, it will need to switch between 24Hz, 50Hz and 60Hz refresh rates on-the-fly. (i.e. if you watch a 50Hz DVD it will switch to 50Hz output, if you watch a 24p movie it will switch either to 24Hz output - or 60Hz if your display doesn't support 24Hz input). Unfortunately Android doesn't let Apps control the display refresh rate, it is a system-wide setting (and some Android boxes won't allow you to switch from 60Hz - which makes 25/50Hz stuff quite nasty to watch). This means either you have to manually alter the refresh rate in Android settings depending on what you want to watch, or put up with a fixed refresh rate, which may not be ideal. If you are in North America or another 60Hz territory (aka "NTSC-land") and don't watch 25/50Hz content this may not be an issue for you, particularly if you don't have a 24p compatible TV. If you are in Europe and care about picture quality - this is a big issue.

2. No HD Audio bitstreaming. So far none (that I'm aware of) of the Android platforms support HDMI HD Audio (DTS HD, Dolby True HD) bit streaming (and I'm not sure HDMI multichannel PCM is supported either), and in some cases even getting Dolby Digital or DTS lossy streams is challenging. Android was really geared up for PCM stereo output only (and at one point even had to resample to 44.1kHz I believe - though I think this is no longer the case)

3. Variable Hardware acceleration. AIUI you can only really expect H264 content to be hardware accelerated. Some platforms don't support MPEG2 or VC-1 hardware acceleration.

(Also not sure about the quality of deinterlacing offered on Android)

The Chromebox with OpenElec will offer frame rate switching, HD Audio bitstreamed over HDMI, VAAPI hardware acceleration of MPEG2, H264 and VC-1 (with some limitations) and a YADIF 2x software deinterlace of 1080i content. (There are experimental drivers with VAAPI Motion Compensated or Adaptive deinterlacing which can be run under Ubuntu as well)

The Raspberry Pi offers frame rate switching, Dolby/DTS lossy bit streaming (and multichannel PCM - so if you have multichannel FLAC stuff that will play), hardware acceleration of H264 (and VC-1/MPEG2 with a low cost licence purchase) and acceptable de-interlacing. For my money an over clocked Pi is a better solution in Europe than a pure OpenElec box than Android. No Netflix though.

[JonSnow88]

thanks regarding point 2 as far as I'm aware android can decode DTS etc it maybe software but it still does the job. I use MX player daily and and tried DTS audio and it works, so XBMC should be no exception. But even if it didn't all I need is passthrough.

I'm in Canada so 24Hz makes no difference to me.

[noggin]

I'm in Canada so 24Hz makes no difference to me.

24Hz is an issue globally if you have a 24Hz compatible TV. It's 25/50Hz content that is less common in North America.

However if you don't see 3:2 pulldown judder you're very lucky. Those of us in Europe who are used to 2:2 pulldown on movies and seldom see 3:2 content often find it very hard to watch. Our first HDTV didn't do 24p properly and we had to sell it as soon as we got a PS3 and started buying Blu-rays, as we suddenly started having to watch material with 3:2 judder, whereas we'd previously seen the same stuff at 2:2 on 50Hz DVDs and on broadcast SD/HDTV. We bought an HDTV with 24p compatibility (it's an LCD that I think displays 24p at 48Hz. No flicker as the backlight is constant)

[Hedda]

Worth noting is that most of these limitations are issues with current Android 4.4 KitKat and older releases.

Many of these issues are said to be addressed in the next major Android release, L Developer Preview, which is rumoured to become Android 5.0 Lollipop.

http://developer.android.com/tv/index.html
http://developer.android.com/preview/tv/...index.html

Google is moving along full steam ahead with the official "Android TV" to replace the failed Google TV platform so key issues like these needs to be fixed.

http://techcrunch.com/2014/07/09/connect...ndroid-tv/

Go Google!

[JonSnow88]

well I know about android TV and been holding off until they where released before my hardware purchase. I pulled the trigger on the chromebox coz I got a good deal, and just wondering if I should wait it out until android tv boxes come to market.

This is why I wanted to know about limitations, but your right it's too early to tell.

[dkaneva]

Worth noting is that most of these limitations are issues with current Android 4.4 KitKat and older releases.

Many of these issues are said to be addressed in the next major Android release, L Developer Preview, which is rumoured to become Android 5.0 Lollipop.

No where in any press snippet have I seen any of these issues addressed with lollipop. Wishful thinking I guess!

[RockerC]

Worth noting is that most of these limitations are issues with current Android 4.4 KitKat and older releases.

Many of these issues are said to be addressed in the next major Android release, L Developer Preview, which is rumoured to become Android 5.0 Lollipop.

No where in any press snippet have I seen any of these issues addressed with lollipop. Wishful thinking I guess!

I actually believe that it is now more than just wishful thinking based on rumors, most if these are now confirmed facts.

However questions remains if XBMC can actually take advantage of all those new features available in Android 5.0 (Lollipop) and to apps running on it.


Anyway, for starters see the full official changelog for Android 5.0 (Lollipop) on Google's official android.com website

http://www.android.com/versions/lollipop-5-0/

Media
Lower latency audio input ensuring that music and communication applications that have strict delay requirements provide an amazing realtime experience
Multi-channel audio stream mixing means professional audio applications can now mix up to eight channels including 5.1 and 7.1 channels
USB Audio support means you can plug USB microphones, speakers, and a myriad of other USB audio devices like amplifiers and mixers into your Android device
Capture full resolution frames around 30 fps
Support raw formats like YUV and Bayer RAW
State of the art video technology with support for HEVC main profile to allow for UHD 4K 10-bit video playback, tunneled hardware video decoding to save power and improved HLS support for streaming

Android TV
Support for living room devices
User interface adapted for the living room
Less browsing, more watching with personalized recommendations for content like movies and TV shows
Voice search for Google Play, YouTube and supported apps so you can just say what you want to see
Console-style Android gaming on your TV with a gamepad
Cast your favorite entertainment apps to your big screen with Google Cast support for Android TV devices

Runtime and Performance
A faster, smoother and more powerful computing experience
ART, an entirely new Android runtime, improves application performance and responsiveness
Up to 4x performance improvements
Compacting backgrounded apps and services so you can do more at once
Support for 64 bit devices, like the Nexus 9, brings desktop class CPUs to Android
Support for 64-bit SoCs using ARM, x86, and MIPS-based cores
Shipping 64-bit native apps like Chrome, Gmail, Calendar, Google Play Music, and more



Also checkout this other thread: http://forum.xbmc.org/showthread.php?tid=204551


Android SDK Tools Revision 23.0.5 and NDK Revision 10c have also now been released with Google's announcement of Android 5.0 (Lollipop)
https://developer.android.com/tools/sdk/...notes.html
https://developer.android.com/tools/sdk/ndk/index.html

This is the first SDK and NDK revisions to officially have support for making apps for Android TV, as such they include many new APIs just as Android 5.0 contain new features
http://developer.android.com/training/tv...index.html
http://developer.android.com/training/tv/index.html

Because Kodi is a native C++ application that uses the NDK, the most interesting stuff in Android 5.0 (Lollipop) for Kodi developers is probably the new APIs in API Level: 21

http://developer.android.com/about/versi...d-5.0.html

Android 5.0 APIs

API Level: 21


If you haven't tested your app against the new Android Runtime (ART)...

The 4.4 release introduced a new, experimental Android runtime, ART. Under 4.4, ART was optional, and the default runtime remained Dalvik. With Android 5.0, ART is now the default runtime.

For an overview of ART's new features, see Introducing ART. Some of the major new features are:

• Ahead-of-time (AOT) compilation
  
• Improved garbage collection (GC)
  
• Improved debugging support

Most Android apps should just work without any changes under ART. However, some techniques that work on Dalvik do not work on ART. For information about the most important issues, see Verifying App Behavior on the Android Runtime (ART). Pay particular attention if:

• Your app uses Java Native Interface (JNI) to run C/C++ code.
  
• You use development tools that generate non-standard code (such as some obfuscators).
  
• You use techniques that are incompatible with compacting garbage collection. (ART does not currently implement compacting GC, but compacting GC is under development in the Android Open Source Project.)

If your app uses RemoteControlClient...

The RemoteControlClient class is now deprecated. Switch to the new MediaSession API as soon as possible.

To display media playback controls if your app is running on the Android TV or Wear platform, implement the MediaSession class. You should also implement MediaSession if your app needs to receive media button events on Android devices.


If you are using the Android Native Development Kit (NDK)...

Android 5.0 introduces support for 64-bit systems. The 64-bit enhancement increases address space and improves performance, while still supporting existing 32-bit apps fully. The 64-bit support also improves the performance of OpenSSL for cryptography. In addition, this release introduces new native media NDK APIs, as well as native OpenGL ES (GLES) 3.1 support.

To use the 64-bit support provided in Android 5.0, download and install NDK Revision 10c from the Android NDK page. Refer to the Revision 10c release notes for more information about important changes and bug fixes to the NDK.
If your app binds to a Service...

The Context.bindService() method now requires an explicit Intent, and throws an exception if given an implicit intent. To ensure your app is secure, use an explicit intent when starting or binding your Service, and do not declare intent filters for the service.


If your app binds to a Service...

The Context.bindService() method now requires an explicit Intent, and throws an exception if given an implicit intent. To ensure your app is secure, use an explicit intent when starting or binding your Service, and do not declare intent filters for the service.


Audio playback

This release includes the following changes to AudioTrack:

• Your app can now supply audio data in floating-point format (ENCODING_PCM_FLOAT). This permits greater dynamic range, more consistent precision, and greater headroom. Floating-point arithmetic is especially useful during intermediate calculations. Playback endpoints use integer format for audio data, and with lower bit depth. (In Android 5.0, portions of the internal pipeline are not yet floating point.)
  
• Your app can now supply audio data as a ByteBuffer, in the same format as provided by MediaCodec.
  
• The WRITE_NON_BLOCKING option can simplify buffering and multithreading for some apps.

Media playback control

Use the new notification and media APIs to ensure that the system UI knows about your media playback and can extract and show album art. Controlling media playback across a UI and a service is now easier with the new MediaSession and MediaController classes.

The new MediaSession class replaces the deprecated RemoteControlClient class and provides a single set of callback methods for handling transport controls and media buttons. If your app provides media playback and runs on the Android TV or Wear platform, use the MediaSession class to handle your transport controls using the same callback methods.

You can now build your own media controller app with the new MediaController class. This class provides a thread-safe way to monitor and control media playback from your app's UI process. When creating a controller, specify a MediaSession.Token object so that your app can interact with the given MediaSession. By using the MediaController.TransportControls methods, you can send commands such as play(), stop(), skipToNext(), and setRating() to control media playback on that session. With the controller, you can also register a MediaController.Callback object to listen for metadata and state changes on the session.

In addition, you can create rich notifications that allow playback control tied to a media session with the new Notification.MediaStyle class.


Media browsing

Android 5.0 introduces the ability for apps to browse the media content library of another app, through the new android.media.browse API. To expose the media content in your app, extend the MediaBrowserService class. Your implementation of MediaBrowserService should provide access to a MediaSession.Token so that apps can play media content provided through your service.

To interact with a media browser service, use the MediaBrowser class. Specify the component name for a MediaSession when you create an MediaBrowser instance. Using that browser instance, your app can then connect to the associated service and obtain a MediaSession.Token object to play content exposed through that service.


Storage - Directory selection

Android 5.0 extends the Storage Access Framework to let users select an entire directory subtree, giving apps read/write access to all contained documents without requiring user confirmation for each item.

To select a directory subtree, build and send an OPEN_DOCUMENT_TREE intent. The system displays all DocumentsProvider instances that support subtree selection, letting the user browse and select a directory. The returned URI represents access to the selected subtree. You can then use buildChildDocumentsUriUsingTree() and buildDocumentUriUsingTree() along with query() to explore the subtree.

The new createDocument() method lets you create new documents or directories anywhere under the subtree. To manage existing documents, use renameDocument() and deleteDocument(). Check COLUMN_FLAGS to verify provider support for these calls before issuing them.

If you're implementing a DocumentsProvider and want to support subtree selection, implement isChildDocument() and include FLAG_SUPPORTS_IS_CHILD in your COLUMN_FLAGS.

Android 5.0 also introduces new package-specific directories on shared storage where your app can place media files for inclusion in MediaStore. The new getExternalMediaDirs() returns paths to these directories on all shared storage devices. Similarly to getExternalFilesDir(), no additional permissions are needed by your app to access the returned paths. The platform periodically scans for new media in these directories, but you can also use MediaScannerConnection to explicitly scan for new content.


Wireless & Connectivity - Multiple network connections

Android 5.0 provides new multi-networking APIs that let your app dynamically scan for available networks with specific capabilities, and establish a connection to them. This functionality is useful when your app requires a specialized network, such as an SUPL, MMS, or carrier-billing network, or if you want to send data using a particular type of transport protocol.

To select and connect to a network dynamically from your app, follow these steps:

Create a ConnectivityManager.
Use the NetworkRequest.Builder class to create an NetworkRequest object and specify the network features and transport type your app is interested in.
To scan for suitable networks, call requestNetwork() or registerNetworkCallback(), and pass in the NetworkRequest object and an implementation of ConnectivityManager.NetworkCallback. Use the requestNetwork() method if you want to actively switch to a suitable network once it’s detected; to receive only notifications for scanned networks without actively switching, use the registerNetworkCallback() method instead.

When the system detects a suitable network, it connects to the network and invokes the onAvailable() callback. You can use the Network object from the callback to get additional information about the network, or to direct traffic to use the selected network.


Scheduling jobs

Android 5.0 provides a new JobScheduler API that lets you optimize battery life by defining jobs for the system to run asynchronously at a later time or under specified conditions (such as when the device is charging). Job scheduling is useful in such situations as:

• The app has non-user-facing work that you can defer.
  
• The app has work you'd prefer to do when the unit is plugged in.
  
• The app has a task that requires network access or a Wi-Fi connection.
  
• The app has a number of tasks that you want to run as a batch on a regular schedule.

A unit of work is encapsulated by a JobInfo object. This object specifies the scheduling criteria.

Use the JobInfo.Builder class to configure how the scheduled task should run. You can schedule the task to run under specific conditions, such as:

• Start when the device is charging
  
• Start when the device is connected to an unmetered network
  
• Start when the device is idle
  
• Finish before a certain deadline or with a minimum delay

Testing and accessibility improvements - Android 5.0 adds the following support for testing and accessibility:

The new getWindowAnimationFrameStats() and getWindowContentFrameStats() methods capture frame statistics for window animations and content. These methods let you write instrumentation tests to evaluate whether an app is rendering frames at a sufficient refresh frequency to provide a smooth user experience.

The new executeShellCommand() method lets you execute shell commands from your instrumentation test. The command execution is similar to running adb shell from a host connected to the device, allowing you to use shell-based tools such as dumpsys, am, content, and pm.

Accessibility services and test tools that use the accessibility APIs (such as UiAutomator) can now retrieve detailed information about the properties of windows on the screen that sighted users can interact with. To retrieve a list of AccessibilityWindowInfo objects, call the new getWindows() method.

The new AccessibilityNodeInfo.AccessibilityAction class lets you define standard or customized actions to perform on an AccessibilityNodeInfo. The new AccessibilityNodeInfo.AccessibilityAction class replaces the actions-related APIs previously found in AccessibilityNodeInfo.

Android 5.0 provides finer-grain control over text-to-speech synthesis in your app. The new Voice class allows your app to use voice profiles associated with specific locales, quality and latency rating, and text-to-speech engine-specific parameters.


Manifest Declarations - Declarable required features

The following values are now supported in the <uses-feature> element, so you can ensure that your app is installed only on devices that provide the features your app needs.

• FEATURE_AUDIO_OUTPUT
  
• FEATURE_CAMERA_CAPABILITY_MANUAL_POST_PROCESSING
  
• FEATURE_CAMERA_CAPABILITY_MANUAL_SENSOR
  
• FEATURE_CAMERA_CAPABILITY_RAW
  
• FEATURE_CAMERA_LEVEL_FULL
  
• FEATURE_GAMEPAD
  
• FEATURE_LIVE_TV
  
• FEATURE_MANAGED_USERS
  
• FEATURE_LEANBACK
  
• FEATURE_OPENGLES_EXTENSION_PACK
  
• FEATURE_SECURELY_REMOVES_USERS
  
• FEATURE_SENSOR_AMBIENT_TEMPERATURE
  
• FEATURE_SENSOR_RELATIVE_HUMIDITY
  
• FEATURE_VERIFIED_BOOT
  
• FEATURE_WEBVIEW

[dkaneva]

Well shame on me. So according to this press snippet, bitstreaming lossless audio like dtshd is now possible with 5.0? Automatic frame rate switching is now technically possible? Full mpeg2 decoding, etc?

[User 231261]

Great post RockerC Thanks

@dkaneva naturally it will do these things especially the etc... duh
please understand the the difference between a roadmap and a guaranteed fact.

[dkaneva]

I wasn't being sarcastic my question was legitimate.

[User 231261]

yeah I read that press snippet about you IED encounter..etc.
Always be prepared to get what you give..

[RockerC]

Well shame on me. So according to this press snippet, bitstreaming lossless audio like dtshd is now possible with 5.0? Automatic frame rate switching is now technically possible? Full mpeg2 decoding, etc?

This news only means it can work, not that it will work from now on. It will not automagically just work in XBMC, support for it in XBMC will not be automatically added by magic even if the underlying Android kernel and Android APIs now have support for this in Android 5.0 (Lollipop).

This news only means that Google have removed some of the hardcoded limits and restrictions in a Android kernel and API levels.

Android media player SoC and hardware box manufacturers will still have to add support for these in their firmware. And XBMC/Kodi developers will then still have to add support for it at the application level.

Anyway, I did not find any official news about automatic frame rate switching so that is still only assumptions and speculations, but it looks like multi-channel audio can supported from Android 5.0 (Lollipop)

Full MPEG-2 decoding not working is not a kernel or API limitation or restriction Android 4.x, it is only lack of existing support from Android media player SoC and hardware box manufacturers at the firmware and driver levels.

[jjd-uk]

multi-channel audio can supported from Android 5.0 (Lollipop)

Multichannel PCM yes, nothing to suggest there's any official support for encoded formats yet, and Lollipop as it comes from Goggle is still restricted to a Max Sample Rate of 96khz so no HD audio which requires 192khz, so manufacturer modification to the kernel will still be required.

[Hedda]

Nvidia is claiming that their newly announced Shield Console (Android TV set-top box) based on Lollipop will support 192kHz HD audio output

http://forum.kodi.tv/showthread.php?tid=220297

Processor NVIDIA Tegra X1 processor
256-core Maxwell GPU with 3GB RAM
Video Features 4K Ultra-HD ready with 4K playback and capture up to 60 fps (VP9, H265, H264)
Audio 7.1 and 5.1 surround sound pass through over HDMI
High-resolution audio playback up to 24-bit/192 kHz over HDMI and USB
High-resolution audio up-sample to 24-bit/192 kHz over USB

Wondering if they have also made other manufacturer modification to the kernel to workaround any other limitation of the Android OS?