Let me just answer this part > The only problem worries us though, is the Compatibility Test will be > affected with the last solution? Though a quick search, I see > compatibility tests are written in Java. Our solution won't change the > APIs, so to my guess, compatibility won't be compromised, though I > need confirmations.
Hi CTS (compatibility test suite) will be run at applicaiton level only and AwesomePlayer changes wont impact it (provided new player driver have all equivalent api's implemented) Other issue of your concern should be, the new changes breaking android API list to applications. make will throw below error, if its broken., you can either resolve it or update android api list by running "make update-api" Checking API: checkapi-last (unknown): error 17: Field android.media.AudioManager.ROUTE_ALL has changed value from 15 to -1 ****************************** You have tried to change the API from what has been previously released in an SDK. Please fix the errors listed above. ****************************** On Nov 8, 11:49 am, einmus <ein...@gmail.com> wrote: > My company is assessing various hardware video decoding and rendering > path on Android. We come up with below solutions: > 1. The perfect solution: comply to OpenMAX IL standards and write OMX > components including OMX core and other components. The only > modification made to Android would be placing component name > @OMXCodec.cpp. Our components would be loaded through vendor plugin > method. Unfortunately it's a rather heavy load. And we don't need OMX > rather than for android, so it's a little bit of waste. > 2. A slightly dirty modification: write decoders and renderer based on > mediasource and awesomerenderer just like Android software decoders > and render did. This requires a few modifications done to > Awesomeplayer. And it's a lighter work. > 3. Replace Awesomeplayer: not necessarily remove it, but add another > player. This will lead the path further away, but it would be much > easier consider we already have a full solution for linux. > The only problem worries us though, is the Compatibility Test will be > affected with the last solution? Though a quick search, I see > compatibility tests are written in Java. Our solution won't change the > APIs, so to my guess, compatibility won't be compromised, though I > need confirmations. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
