The Pain of Live Streaming on Android

Streaming video on mobile devices remains one of the most challenging and frustrating experiences for viewers and broadcasters alike. When HTTP Live Streaming (HLS) was introduced, the goal was simple: easily stream live and on-demand video content to devices with a variety of bandwidth connections. Adaptive streaming is the marquee feature of HLS, and while Adobe’s RTMP can offer similar capabilities in Flash, desktop browsers like Chrome and Firefox can play HLS streams using a player like the JW Player. HLS is enhanced further by native implementations found within Safari and iOS, which makes streaming to mobile devices even easier.

So, what’s the problem?

Android and the lack of native HLS support.

All Hail Apple?

To be fair, it’s not all Android’s fault for lacking support for HLS in version 4.2 and beyond. Even the major desktop browsers have not yet implemented native HLS playback, and the only way to do so is through a Flash plugin. This doesn’t bode well for those of us who like to design sites for both the desktop and mobile devices, since the later generally can’t use Flash.

Android’s HLS implementation has a storied and turbulent past. Basic support was introduced in 3.0 (Honeycomb), but has never worked well enough for practical use. Below is an overview of the issues that have been found in each major Android version. We’ve also included a chart showing how widespread each version of Android is in the market:

Android distribution by version as of February 4, 2013

Android 2.3 (Gingerbread)

  • No Support, despite being the most popular version of Android

Android 3.0 (Honeycomb)

  • Streams cause tablet devices to crash

Android 4.0 (Ice Cream Sandwich)

  • VOD streams do not seek
  • Aspect ratios are not detected and cause image deformation
  • Fullscreen causes videos to restart from the beginning

Android 4.1+ (Jelly Bean)

  • Aspect ratio issue is fixed, but seek is still unavailable
  • Chrome does not understand HLS leading to broken mimetype detection
  • Taking video fullscreen causes devices to throw an error and stop.

You can see these HLS issues for yourself by viewing the sample stream we provide on our HTML5 report.

Android’s lack of native HLS support is one of the factors for why streaming to mobile devices remains a challenge. Since HLS is a proposed draft from Apple, and not yet an accepted standard by the IETF, companies like Google and Microsoft are both wary about ceding any control of their platform to Apple. With everyone gunning for a piece of the mobile market, it makes sense that a non-proprietary standard, like MPEG DASH, would help make adaptive streaming more prolific.

The Workarounds

With Android shipments and activations now outpacing iOS devices, broadcasters need to find a way to deliver HLS video to non-Apple devices. Since HLS streaming is supported on Android version 2.3-4.0 via Flash, you have to assume the user experience will be sub-par (see the aforementioned issues). Additionally, Flash support was discontinued in Android 4.1, meaning future versions of the OS cannot play back HLS streams natively.

A way around this limitation is to either build your own app’s implementation, or utilize an SDK from a third party vendor. However, this approach can be time consuming or impractical for some broadcasters. Additionally, it requires you to maintain and distribute an application to your users.

The easiest way to support HLS streams on Android or other non-iOS platforms is to offer a fallback RTSP stream. The main advantage to using an RTSP is that there is no need for Flash or any special client configuration. For example, if you use the JW Player for video playback, setting the player’s fallback to false will cause an RTSP stream to be loaded instead of an HLS M3U8 stream. This technique works great with the Wowza Media Server and is compatible with Android 2.3, 4.0 and 4.2 via the OS’ native player. You can learn more about this on our Apple HLS guide.

Until either a new non-proprietary standard is adopted, or each of the mobile platforms implement native HLS support, it looks like streaming to devices like Android will remain a challenge. Only time will tell…


  1. Thomas Vander Stichele May 7, 2013 - 10:16 EDT

    Rob, why is RTSP proprietary ? It’s an IETF standard AFAIK.

  2. Ethan LongTail May 28, 2013 - 07:54 EDT

    @Paul – I am not sure of any HLS support for 2.3

    @Charles – I don’t know of devices that do this.

  3. Deke May 7, 2013 - 12:00 EDT

    All delivery types are supported (RTSP, RTMP, HLS, HDS) with the Mirror Image CDN. We have changed over to them to cover all formats, it is working great.

  4. Ethan LongTail July 18, 2013 - 06:52 EDT

    Where are you running this stream?

  5. Ethan LongTail May 7, 2013 - 04:43 EDT

    RTSP can be delivered by many CDNs out there, and from our experience, it is the only format that actually works/plays properly from old to new Android devices.

  6. David Wong July 19, 2013 - 01:34 EDT

    Just use the default browser which will then trigger the native player to play the stream.
    Seemed worker properly in my S3. Would anyone share some test cases?

  7. Ethan LongTail July 19, 2013 - 03:56 EDT

    Sorry, I meant a link.

  8. Jeff Wenslow May 10, 2013 - 01:34 EDT

    Great article

  9. peter May 6, 2013 - 09:22 EDT

    hello, please need help in livestreaming using long-tail can any one help me with step and step on how to use it with flash media encoder.Thanks

  10. Paul Clark May 17, 2013 - 12:00 EDT

    RTSP is indeed an international standard and is widely used in the IPTV world within managed networks, usually delivering either RTP/UDP or MPEG-TS in raw UDP. Unfortunately in the Web world most people think of the Real Networks implementation which is deeply non-standard.

    You mention Flash-based solutions for HLS in the article. Can anyone recommend a commercially licensable solution which supports HLS on Gingerbread? I have looked at Onlinelib but they say they don’t support 2.3. We have a commercial opportunity for this.


    Paul Clark

  11. Rob May 8, 2013 - 11:47 EDT

    @Thomas Vander – Rather than going on what I was told I did a bit more research and it turns out….
    “The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery, however some vendors implement proprietary transport protocols. The RTSP server from RealNetworks, for example, also features RealNetworks’ proprietary RDT stream transport.”

    I may have been misled…

  12. Charles Linquist May 27, 2013 - 08:46 EDT

    But what about streaming FROM an Android device? I have some robots that can be controlled from up to 1/2 mile away. I would really like to be able to stream video from them (to act as ‘eyes’) over 4G.

    Apple’s FaceTime is a possible start, but it wastes bandwidth in that it streams video in both directions. My robot does not need to see what I’m doing.

    I just need a low-latency remote camera that would (theoretically at least) have an unlimited range.

  13. Ethan LongTail May 6, 2013 - 03:44 EDT

    Please email us –

  14. Ethan LongTail May 8, 2013 - 03:46 EDT

    Interesting, thanks for sharing this Rob.

  15. Ethan LongTail May 2, 2013 - 06:46 EDT

    You should use RTMP, then Fall back to HTML5 for devices. Like this –, but 1st source is RTMP, 2nd source is a file that HTML5 can play.

  16. David Wong July 18, 2013 - 09:51 EDT

    I used the same links (VOD, and Live) for iPhone and Samsung S3 (Android 4.1.2). Both work properly without the problem found.

    I also use the link mention reference in this site,, No problem found in the S3..

  17. Sachin Ahuja November 14, 2013 - 07:46 EDT


    I am also facing the same problem of stream (which gets played on Apple successfully) not getting played on few Android devices OS > 4.0 and above.

    Though few Samsung devices are successfully able to play ABR HTTP stream but on few devices such as XOLO A500S (Android 4.2.2) and Spice (Android 4.2.2) what happens is if 64 kbps audio only profile is defined in playlist in the end then the device is not able to play the stream whereas if 64 kbps Audio only profile is moved to the top in playlist or is removed from playlist then the streaming works fine in these Android devices in the device native player.

    Any idea, does Android devices have problems with 64 kbps audio only file in the playlist?

    Sachin Ahuja

    • Ethan Feldman November 15, 2013 - 10:39 EDT


      Do you have an example of where you have run this set up?


  18. Burhanuddin Jamalan December 4, 2013 - 06:04 EDT

    As per Ethan Longtail said :

    Ethan LongTail
    April 16, 2013 – 04:58 EST

    The JW Player still works fine on Android.

    Can you give the link that I can refer to since I’m facing the same problem.

  19. Dmitry Sherman December 18, 2013 - 03:24 EDT

    So how do we actually automatically fallback to RTSP without providing a link under or instead the player?

    • Ethan Feldman December 18, 2013 - 05:53 EDT

      You need to provide the link. RTSP is not supported in Flash or HTML5 natively, so adding it as a link in the player set up will do nothing.

  20. Paul March 4, 2014 - 02:30 EDT

    What’s disappointing about all this is that HLS video WILL play fine on your average Galaxy S4 Android phone in the default browser, or any browser including Chrome and Firefox. I’m guessing it’s the same deal with Android tablets running 4+.

    Yet, JW player detection wisdom forces a denial of the request to play the m3u8 stream and throws a useless error to the poor user. Why?

    Why isn’t there an override flag that developers can use to force JW player to attempt to play the m3u8 stream given such a common device such as a Galaxy S4 is asking to play the video, and is capable of playing it?

    Seems broken to me (JW that is).

    • Ethan Feldman March 4, 2014 - 10:36 EDT

      Once the newer versions of Android reach a higher adoption, we will add support natively. One work around you can use for the time being is detecting Android user the userAgent in JavaScript. Here is a small sample:

      <!DOCTYPE html>
      <script src=""></script>
      <center><div id='container'></div></center>
      if (navigator.userAgent.match(/android/i) != null){
      file: "",
      type: "mp4",
      primary: "html5"
      } else {
        playlist: [{
          image: "",
          sources: [{
            file: ""
            file: ""
        primary: "flash"

  21. kgpsss December 20, 2014 - 05:45 EDT

    Till recently I was able to plY the earlier episodes STAR PLUS soaps on my SAMSUNG GALAXY NOTE 10.1. Suddenly I started getting a message ” THIS VIDEO JS NOT ENCODED FOR YOUR DEVICE” . What can I do to restart viewing them. My OS is android version 4.1.2. Pl reply to my email.

  22. Dmitriy January 30, 2015 - 03:01 EDT

    Did things change as for now?
    What is the best approach to playback HLS on android 2.3+?
    I know JWPlayer has an SDK for Android, is it stable?

    • Ethan Feldman February 26, 2015 - 05:44 EDT

      The SDK is out. Please contact support [at] jwplayer [dot] com for more information.

  23. Mario March 12, 2015 - 01:35 EDT

    hola amigos
    el código de arriba me funciona perfecto para ver vídeos mp4 en desktop y en móviles, pero si quisiera ver mi streaming como lo modificaría?

    aqui el codigo

    if (navigator.userAgent.match(/android/i) != null){


    file: “″,

    type: “mp4″,

    primary: “html5″


    } else {


    playlist: [{

    image: “”,

    sources: [{

    file: “”


    file: “″



    primary: “flash”



    • Ethan Feldman March 12, 2015 - 06:36 EDT

      Please email support [at] jwplayer [dot] com directly about this.

  24. Rob April 2, 2013 - 12:06 EDT

    This then introduces a new pain, because RTSP is a propriety protocol many CDNs do not support it. I know Level3 definitely don’t!

  25. Ethan LongTail April 25, 2013 - 04:39 EDT

    Yeah. Very on point.

  26. Rob April 10, 2013 - 09:32 EDT

    Ha ha. Indeed! Maybe I should rephrase it? This reminds me of the pain…

  27. chinchpokli May 2, 2013 - 01:20 EDT

    could you please tell me? our site uses jwplayer with rtmp but many of our viewer complain that they are not able to watch the video…now there is my one query? what i need to add or make to change so that all users i.e ios,android,windows can watch video ?

    please suggest me what i need to do?

  28. mrjohnson April 16, 2013 - 08:11 EDT

    Does this mean videos in jwplayer will play on any android device?

    I am a member of an educational site that uses jwplayer to stream recorded video lectures. A lot of android users complain the videos do not work on their device even after they have installed flash player

    Is this an error by them? The site refuse to acknowledge that the issue is on there end and that it is a problem with google/android/flash etc

  29. Mattias April 9, 2013 - 09:09 EDT

    Rob: it’s not a new pain.. it’s an old pain – just spelled out.. :)

  30. Ethan LongTail April 16, 2013 - 04:58 EDT

    The JW Player still works fine on Android.

  31. AppDev April 25, 2013 - 07:01 EDT

    As Ed points out 3rd party SDK’s do offer a good alternative for those with commercial deployments – until such time Android OS catches up and includes a good HLS or MPEG-DASH implementation. From experience the Helix SDK for Android supports HLS and MPEG-DASH for Android 2.2 to 4.x. providing a viable interim App solution for now .

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>