Contributor: john_lee, jserv

Proposed Release Cycle in Practice

Based on prior discussions, I think it's time for me to propose this.

Definitions

Generic build
Android build with generic board support.
  1. Validated.
  2. Integrate WG output if it performs better. Report back if else.
  3. Android specific optimization.
LEB
based on Generic build, fully enabled.

Branches

  • linaro-{gingerbread,honeycomb,...} branch in git.linaro.org repo. It's for the Generic build.
  • {pandaboard,u8500-href,...}-for-[android release]-merge branch in git.linaro.org. It's temporary for phase 2 merge.

  • linaro-[android release]-[platform] branch in git.linaro.org repo. It's for LEB.

Based on Platform/Android/ReleaseCycle, there are 3 phases.

  1. Rebase:
    1. Android team rebases linaro modifications and create Branch 1.
    2. LT rebases BSP and create Branch 2.
    3. Output: validated Generic build and validated hardware support.
  2. Integration & Upstreaming

    1. Android team merge Branch 2 to create Branch 3, run validation, fix generic issues (fix in 1 then merge into 3), report back hardware issues back to LT.
    2. Android team pushes upstream where possible.
    3. Output: LEB Branch 3.
  3. Consolidation & Optimization: the same as in Platform/Android/ReleaseCycle.

Reasons

Hardware support can only be enabled during compile time, not runtime, so there must be separate branch. Need to fix the 2nd item of section "Binaries" on Platform/Android/EvaluationBuild/MemberDeliverables. Binaries can be put into Android source tree to build system images with hardware support, or can be downloaded outside Linaro by build script.

No drop-in binaries for a general build to utilize hardware acceleration/features. It's compile time difference so you have to use different 'branch' to generate different build.

I've mentioned this in another mail:

  • For example, check this file (in Gingerbread): frameworks/base/media/libstagefright/OMXCodec.cpp

    search "static const CodecInfo kDecoderInfo[]" You see it's hardcoded and specified during compile time. If we add something extra into this, say ST-Ericsson, for general source code release this is pointless -- any entitles other then STE will not have this OMX component, and this simply added a possible error that's very hard to debug.

So, we need both the patches and the binaries to 'enable' a hardware. We have already know what exactly to ask LT, and all we need is just some support/contact resource from the LT to work on the LEB. There's no need to try-and-error an outdated release with binaries inside that we have no hardware knowledge about. If we do this we won't have time to come out with a valid LEB on time. For now, what we need is already quite clear, and we should try to get it as soon as possible.

Take panda board for example, we need "Branch 2", i.e. pandaboard-for-gingerbread-merge, which should already have the bits to enable hardware. Then we take what we need from this branch and merge it into our general branch to create a new branch, linaro-gingerbread-pandaboard, which is the release branch for panda.

Prior Discussions

In practice, the key consideration Android HAL for SoC is likely about multimedia and graphics. In terms of multimedia, developers will have to replace low level multimedia framework (JNI + a bit Java). Before 2.3 people keep OpenCORE or replace it with GStreamer, or implement their own library to match with the JNI directly. In 2.3 it's mostly the same but OpenCORE is being replaced by StageFright. So, in this context, binaries for multimedia should be included in low level framework.

Things are similar in graphic. 2D acceleration should be done inside copybit', while 3D should be done inside libhgl'. The proprietary binaries should just include these libraries.

With this, we won't interfere with what SoC vendors already have internally, therefore to minimize the switching cost. Google Android team spent most of their energy to catch up with iOS, so they didn't spend much effort on the ease of hardware integration. In time, this will change, and Linaro should simply go with it.

In this context, the role of Android team (in terms of HAL) will become:

  • Work with LTs to extract the exact APIs required by HAL, and where to put it in the Android tree.
  • With each new Android release, survey the difference and inform/work with LTs on the HAL changes.
  • Validate the binaries provided by LTs in terms of benchmark, correctness, stablity, etc.

The biggest two hardware acceleration dependent grounds:

  • Graphic
  • Multimedia

For graphics, this is rather straight forward:

  • For 3D enabled hardware, we leave the OpenGL ES implementation to the LTs and focus on ARM specific tunings
  • Most of the Linaro hardwares belong to 1, but it might be interesting to see the possibility to maximize 2D acceleration usage in Android 2.x and 3.x because low end hardwares would need this. Android needs a lot of work regarding this because its basic assumption is 3D nowadays.

And, the multimedia is the tricky part. Like I suggested last time, the code here is a mess and everyone has their own implementation, and they conflict with each other. There's no value in resolving this, because you need:

  • stable upstream
  • stable Linaro HAL

Since for now we won't be able to have 1), there's no point to do 2).

SoC vendors tend to get source code at the same time, if not earlier, then Linaro. Multimedia is one of the first part they will definitely look at and start porting as soon as possible. Popular codec algorithm such as H.264 will be the first ones they shoot down, so we let them do their work -- there are much more issues then these we need to care about at the moment. The Android team can look at the structure change when new release arrived, and help the LTs do the porting.

For example, check this file (in Gingerbread): frameworks/base/media/libstagefright/OMXCodec.cpp search "static const CodecInfo kDecoderInfo[]"

static const CodecInfo kDecoderInfo[] = {
    { MEDIA_MIMETYPE_IMAGE_JPEG, "OMX.TI.JPEG.decode" },
//    { MEDIA_MIMETYPE_AUDIO_MPEG, "OMX.TI.MP3.decode" },
    { MEDIA_MIMETYPE_AUDIO_MPEG, "MP3Decoder" },
//    { MEDIA_MIMETYPE_AUDIO_MPEG, "OMX.PV.mp3dec" },
//    { MEDIA_MIMETYPE_AUDIO_AMR_NB, "OMX.TI.AMR.decode" },
    { MEDIA_MIMETYPE_AUDIO_AMR_NB, "AMRNBDecoder" },
//    { MEDIA_MIMETYPE_AUDIO_AMR_NB, "OMX.PV.amrdec" },
    { MEDIA_MIMETYPE_AUDIO_AMR_WB, "OMX.TI.WBAMR.decode" },
    { MEDIA_MIMETYPE_AUDIO_AMR_WB, "AMRWBDecoder" },
//    { MEDIA_MIMETYPE_AUDIO_AMR_WB, "OMX.PV.amrdec" },
    { MEDIA_MIMETYPE_AUDIO_AAC, "OMX.TI.AAC.decode" },
    { MEDIA_MIMETYPE_AUDIO_AAC, "AACDecoder" },
    ...
    { MEDIA_MIMETYPE_VIDEO_AVC, "AVCDecoder" },
//    { MEDIA_MIMETYPE_VIDEO_AVC, "OMX.PV.avcdec" },
    { MEDIA_MIMETYPE_AUDIO_VORBIS, "VorbisDecoder" },
    { MEDIA_MIMETYPE_VIDEO_VPX, "VPXDecoder" },
};

You see it's hardcoded and specified during compile time. If we add something extra into this, say ST-Ericsson, for general source code release this is pointless -- any entitles other then STE will not have this OMX component, and this simply added a possible error that's very hard to debug.

Another example, file frameworks/base/media/libstagefright/StagefrightMediaScanner.cpp search "FileHasAcceptableExtension"

static bool FileHasAcceptableExtension(const char *extension) {
    static const char *kValidExtensions[] = {
        ".mp3", ".mp4", ".m4a", ".3gp", ".3gpp", ".3g2", ".3gpp2",
        ".mpeg", ".ogg", ".mid", ".smf", ".imy", ".wma", ".aac",
        ".wav", ".amr", ".midi", ".xmf", ".rtttl", ".rtx", ".ota",
        ".mkv", ".mka", ".webm", ".ts"
    };
    ...

You see for extra media formats you have to add into this, but not everyone has support for this format. This is code level change and should simply be done by builds from different LTs.

For multimedia, it has some value to put in some formats which do not have popular hardware decoder support. For example, it might make sense to add stuffs like VP8, FLAC, etc. and try to optimize them for ARM, but it's another issue.

JimHuang/Sandbox/AndroidHALPitfall (last modified 2011-03-30 20:56:28)