Hi,
First i'm new and maybe i didnt choose the correct subforum, so if i'm wrong i'm sorry. Second, i entered in 'similar' threads about my questions and nothing similar.
Well, i'm comp. engineer student and i have to make one project about encoding and decoding video using the Device Hardware, so i began to investigate and i could find that Google released one API with some classes that access to low-level codecs (eg. MediaCodec, MediaExtractor or MediaFormat), so that API solve my problem, so i should learn how to develop with it and no more but...
I have readed that before that API, released this year, there was some frameworks named OpenCore and StageFright, and people who wanted to use hw device codecs had to use that frameworks, but i really dont know how people did it, if i can find some examples, and which differences can i get using directly this frameworks instead of the Android 4.1 API.
As last question, does anybody knows if this API access to the stagefright or opencore frameworks when you creates an encoder or decoder?
I know that maybe are totally noob questions, but i have googled for it from time ago and i can't get nothing usefull exception about 4.1 API which i could find Google I/O videos and documentation and now i know a bit better how it works.
Thanks!
Related
maybe either through API level, or by querying market info
Reason: i want to check on GB before I upgrade to ICS, which apps will not work.
don't know if relevant but it is for SGS II
Thx in advance
repost from here as nobody could really answer my question
can't believe I'm the only one with that issue
maybe an idea for a dev? would be willing to pay for that ;-)
I don't see why this can't be done:
-http://stackoverflow.com/questions/2695746/how-to-get-a-list-of-installed-android-applications-and-pick-one-to-run
-http://developer.android.com/reference/android/content/pm/PackageManager.html
-http://developer.android.com/reference/android/content/Context.html#getApplicationInfo()
I haven't thought through the problem just yet, but its seems to be doable. If you don't find an app soon, I will start working on a script that does it and, if successful, a proper, free software app. I am hoping the available methods won't require something as stupid as launching each app fully. But again, I haven't thought it through. Thanks for the idea btw.
EDIT:
Made a little more effort
https://groups.google.com/forum/?hl=en&fromgroups#!topic/android-developers/dXLACRIizKc
I will work on something this weekend and get back with y'all.
EDIT 2:
So it looks like I would need maxSdkVersion which I don't find in the API. Furthermore, it is strongly suggested that one not use maxSdkVersion when building an app so that doesn't sound all that useful. I have received another, much more complicated suggestion that may do what I want, but I will have to look hard at it. Looks like I'm going nowhere in my effort. Always open to suggestions. More to come later this weekend.
I'm not the sharpest tool in the shed, but I thought this was mostly a straightforward task using the API's exposure to AndroidManifest.xml. As per my previously posted link to an Android Developers discussion on the topic, my approach is dead in the water as far as I can see. I did try to find an answer though to the best of my limited ability. If anyone has or ever solves this problem (I consider it a problem) I would hope they find the this thread.
Thanks for the learning experience. I give up.
Most older apps will work fine on ICS, its pretty backwards compatible. If the app uses legacy menus the button will appear in the old lower left hand corner location instead of the upper right hand corner like apps written for ICS.
i'm no dev so bear with me if i write stupid stuff
one likely but not very promising sounding way might be to use android:targetSdkVersion as "As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens)."
question though is how many apps actually use this?
However after having read this re android:maxSdkVersion "Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute." (taking from here) i now don't know how important my op is, but then why do all app devs release new versions "fixing things" for ICS?
One pretty significant example which actually currently will prevent my phone from getting ICS for now is that the subsonic app in the current version produces stuttering when playing audio while downloading (problem description here).
Isn't there any way to instead of searching the phone searching google play/android market instead?
Randi said:
maybe either through API level, or by querying market info
Reason: i want to check on GB before I upgrade to ICS, which apps will not work.
don't know if relevant but it is for SGS II
Thx in advance
repost from here as nobody could really answer my question
Click to expand...
Click to collapse
Here's a list of some working games/apps for ICS
Theoretically an Android app (or a combo of say App Engine and Android) could find your installed apps, seacrh Play for said apps and then scrape the page for relevant information. Doesn't sound to hard, but I didn't think about too hard either. Perhaps I will check out what useful info is on Play and how feasible scraping its markup will be. I will get back at y'all if I do.
I like many other have been experiencing Force closes on Google Play Music, Movies, and YouTube after the latest updates on ICS based roms. I have seen people report experiencing this problem on Stock, Liquid, AOKP, and CM9 on various devices. I myself have wiped data and even tried it on a completely fresh rom install from what I could tell there were no files on my SD card generated from previous versions of Google Play Music that would cause the problem. On my regular rom I uninstalled and wiped any existence of the old version multiple times. When I place the widget on my home screen it'll shuffle and play through my locally stored music on my sd card (not pinned music actually music I copied my self). It seems to be wanting to display an element but that it doesn't exist so it crashes.
I reported the crash inside the Stack trace it includes the error:
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.google.android.music.activitymanagement.TopLevelActivity}: android.view.InflateException: Binary XML file line #6: Error inflating class android.app.MediaRouteButton
Here is a logcat for the Google Play Music FC as well http://pastebin.com/VP2cSmN1 It seems to be the same exact bug that causes YouTube to crash although the Play Movies is a slightly different but similar bug from what I can tell.
I think more people are needed so that this bug is noticed and fixed. I created a thread on the Google Support forums here I encourage everyone that is having this problem to make a post so that it is noticed and fixed.
https://productforums.google.com/forum/#!msg/mobile/a6u2tK6a49g/-Juju-8C9vQJ
Please post in this thread if you are having this problem or if you have a solution to the problem. Now obviously the easiest solution would be for Google to update all the apps with a fix but possibly the problem could lie with the individual custom roms. Any information that anyone has on these issues would be welcome and needed to get this problem fixed.
EDIT: Here is the old Google Play Music APK to downgrade. http://forum.xda-developers.com/showthread.php?t=1533816
EDIT: After a little research I found this in the documentation for Android and apparently it's a class that is only found in Jelly Bean which brings me to the question why is it trying to use it on an ICS rom?
http://developer.android.com/reference/android/app/MediaRouteButton.html
EDIT: Raeled found out if you remove the res/layout-v16 folder from the apk file the apps no longer force close. The Movies app had an additional res/menu-v16 folder I had to remove. Keep in mind I don't know what side effects this will have on the apps but so far from what I have seen they work fine however I haven't rented any movies. Also because these are modified with an APKTool the signature was broken so you will have to uninstall your older versions to use them and I don't think you will be able to install any updates from the Google Play Store since the signature won't match. Anyways at least a solution until Google can fix the problem or our custom rom developers can find what causes the apps to want to use the Level 16 API.
EDIT: If you're a rom developer you can fix this problem in your rom by applying this change and recompiling from source. Explanations of why you need to do this can be found below.
https://github.com/aospX/platform_build/commit/a34ffcecc7c237ac9c9e263984f6a74d3a7c3831
I'm on AOKP and having the same issue. Would very much appreciate a fix :fingers-crossed:
Thanks for posting hopefully we get more attention to this issue!
I am using EOS ICS (4.0.4) on my Xoom 3G and aospx ICS on my Desire HD and was experiencing the FC's on both of them.
Have been doing some experimenting on altering the APK to get it to work on my device. I've been using APKTool to remove the "\res\layout-v16" folder from the APK. That seemed to do the trick and the modified app seemed to run fine on both the devices.
This raises the question for me why "layout-v16" would get used at all in the first place as my limited Android knowledge tells me it should not be used on API 15 (4.0.4).
I'm not completely sure what this all means but to me it looks like the devices are telling the apps that it is running on Jelly Bean while it is actually not.
Would you be able to post your modified apk files?
EDIT: I was able to do it however if you know how to do it without breaking signatures so that they can just update over the other apps that would be great.
Altering the APK without breaking the sign should not be possible. Even if it was we'd probably need to "fix" every new version anyways.
I have been looking in the android documentation and the resource should indeed not be used according to the specs on the Android development website.
To test further i have created a simple APK file (attached) that will print out the current API level. It also has to "res\layout" and a "res\layout-v16". When i run it on my device it will (just like music apk) select the v16 resource while the API level is 15. When i ask the API level using code it correctly reports 15.
Also changed folder to "res\layout-v17" quick just for a test but then the devices didn't pick this resource. So it will correctly skip API 17 content
So it seems the system does know it's API 15 but will still get API 16 resources.
If the case is that the problem is in the custom roms and the official ICS roms do not have this problem i think the change that Google is gonna fix this is pretty low.
Raeled said:
Altering the APK without breaking the sign should not be possible. Even if it was we'd probably need to "fix" every new version anyways.
I have been looking in the android documentation and the resource should indeed not be used according to the specs on the Android development website.
To test further i have created a simple APK file (attached) that will print out the current API level. It also has to "res\layout" and a "res\layout-v16". When i run it on my device it will (just like music apk) select the v16 resource while the API level is 15. When i ask the API level using code it correctly reports 15.
Also changed folder to "res\layout-v17" quick just for a test but then the devices didn't pick this resource. So it will correctly skip API 17 content
So it seems the system does know it's API 15 but will still get API 16 resources.
If the case is that the problem is in the custom roms and the official ICS roms do not have this problem i think the change that Google is gonna fix this is pretty low.
Click to expand...
Click to collapse
Yeah basically the Google Guy basically said our custom rom people need to fix it which is probably true however in my mind they could just as easily make a separate ICS APK like they have a separate APK for Gingerbread not a hard thing to do. But I hope that you're able to find the root of this problem I don't really have enough experience with this to know how to solve it in the rom. But you are saying that if there is API 16 material in the Apps it will pick it up and use it no matter what app it is?
I've used the android SDK to create 2 ICS Virtual devices. (4.0: API 14 and 4.0.3: API 15). These devices resolved the resources as they where supposed to do. After that i installed the Google Play Music app on them and also those worked perfectly fine.
The change that google is gonna fix this is next to none. The APK is not in error here. If they do this fix then they'd be saying that the specs are "more like guidelines"
And yes, this problem will spread to every app that will use API 16 only functionality in an API 16 only resource.
Yeah I've pretty much come to the conclusion that there is something wrong with the actual roms that need to be fixed by our developers! Just the root of the problem needs to be found.
The following are speculations as i messed up my Xoom by testing it. So use caution when trying to do what i did.
After some exploration in the Android source i found that the resource manager (the component that is responsible for loading the "res\layout", a.o.) is initialized not by using the "Build.Version.SDK_INT" (this has the correct value of 15), but by another property "Build.Version.RESOURCES_SDK_INT". This can be found in the source at: "\core\java\android\content\pm\PackageParser.java" (line 497 & 712).
Moving to source at "\core\java\android\os\Build.java" (line 120) we find out that "RESOURCES_SDK_INT" is based on "SDK_INT" but adds +1 if "CODENAME" is not equal to the value "RES". A few lines up we see that codename is read from the "ro.build.version.codename" key in the "build.prop" file. In the roms i use this value is "AOSP" so this means the resource sdk version gets +1 and will start to prefer Jelly Bean resources.
I tried to modify my "build.prop" file but this caused my xoom to not get past the boot animation. So once more: be carefull
doesn't this mean it should be 15 instead of aosp? This other rom theirs has the value of REL they claim not to have the same issue we are having but I can't confirm this.
Oh by changing this for whatever reason it thought apps weren't there and decided to wipe a bunch of the app data... I just backed up the system so that was awesome!
Sent from my ThunderBolt using Tapatalk 2
Link_of_Hyrule said:
doesn't this mean it should be 15 instead of aosp?
Sent from my ThunderBolt using Tapatalk 2
Click to expand...
Click to collapse
The "ro.build.platform.codename" is automatically set by the flag PLATFORM_VERSION_CODENAME in build/core/version_defaults.mk when compiling from source..Which =AOSP stands for development build and REL is release build. But by changing PLATFORM_VERSION_CODENAME := REL this does in fact fix this issue as Raeled suspected (tested by installing latest Google Play Music and latest YouTube, both work fine now.. )..
https://github.com/aospX/platform_build/commit/a34ffcecc7c237ac9c9e263984f6a74d3a7c3831
thanks Raeled
But it requires recompiling the entire rom from source?
existz said:
The "ro.build.platform.codename" is automatically set by the flag PLATFORM_VERSION_CODENAME in build/core/version_defaults.mk when compiling from source..Which =AOSP stands for development build and REL is release build. But by changing PLATFORM_VERSION_CODENAME := REL this does in fact fix this issue as Raeled suspected (tested by installing latest Google Play Music and latest YouTube, both work fine now.. )..
https://github.com/aospX/platform_build/commit/a34ffcecc7c237ac9c9e263984f6a74d3a7c3831
thanks Raeled
Click to expand...
Click to collapse
So this means that your next rom build is going to be possible to use the google music and youtube app from the market without any problems?!?!
Link_of_Hyrule said:
But it requires recompiling the entire rom from source?
Click to expand...
Click to collapse
Correct..it seems that once compiled with =AOSP, all the system packages check this and if it doesn't return as a development platform (=AOSP) it crashes..this is why just changing it in build prop does not work..So the whole rom needs recompiled with =REL.
onesolo said:
So this means that your next rom build is going to be possible to use the google music and youtube app from the market without any problems?!?!
Click to expand...
Click to collapse
Yes, changes are already pushed to git and will be in next release.
Sent from my Inspire 4G using xda app-developers app
Well your devices are lucky to have a dev actively working on fixing this it seems us Mecha users will have to wait for a dev to come along and release a new build or new ICS rom with the fix.
EDIT: Finally got it fixed in the up coming build
can u please update to the latest yt version?
Bump
Sent from my MZ601 using XDA Premium HD app
Youtube app (v4.1.23) & Google Play Music (v4.3.615.481147):
Thanks raeld can you put up the latest version 4.1.47 to please?
Hello!
I am in the R&D Phase of trying to build/port the Native Android SiriusXM App to Windows Phone. At best, I'd like to end up with a fully ported SiriusXM Android App. At worse, I'd like to get the source for an app like SatRadPlayer or SXMBuddy and update it to work with the new server. As a start, I am attaching the fully decompiled Android App.
My biggest challenge is that I haven't really developed a native WP App nor have I ever developed anything for Android...I do have some Java experience, though!
Help/Guidance/Feedback is greatly appreciated!
If anyone else wants to try giving this a shot as well, they are more than welcome to. My only request is that their App be free/donation ware so we can help build the platform.
If the app is originally in Java (not C/C++, and no, I haven't checked yet) you'll probably want to go with C# for your code; it's very similar to Java and the framework is largely self-documenting so it's easy to learn (there's also excellent docs on MSDN, of course). If part of the original app is unmanaged code, it's probably easier to just import that into a Windows Phone Component C++ project in Visual Studio and then patch it up to use Win32/WinRT instead of POSIX/Android.
Good idea. everything was written in Java. sounds like this will be quite a bit of work for one person. The app is developed and maintained by a company called QuickPlay in Canada. The audio streams are transferred over in DRMed "Chunks" that the app decodes. I don't even know if it is possible to decode them (I hope so).
At this point I am thinking it will be easier to manipulate the streams from the desktop app as the call generate xml and the audio is streamed in AAC. I guess the next question is can Windows Phone 8 handle AAC streams?
It supports AAC in general, so yes, I imagine so.
If the source code to the DRM decoder is available or easily decompiled, breaking/re-implementing it should be easy.
GoodDayToDie said:
It supports AAC in general, so yes, I imagine so.
If the source code to the DRM decoder is available or easily decompiled, breaking/re-implementing it should be easy.
Click to expand...
Click to collapse
I took a different approach, and now have a working proof-of-concept using the legacy WMA streams. One of the things I am struggling with is how to set up a timer to periodically send a response packet back to the server. the standard "background thread" won't cut it because it has to be more than around 30 mins. I tried to use a timer in the backgroundaudio agent, but that was throwing a whole bunch of "illegal cross-thread" calls on instantiation. I can use the timer successfully in the main app though. This only works if the app is active and the screen isn't locked.
Hi, did you manage to decode the chk streams? I would be interested in knowing how you did it.
I never did. I ended up creating a mysqueezebox.com account, installing the "Siriusxm" app there and used that to gain access to the legacy streams. It would be really nice if someone could write a nice squeezebox client for Windows phone as everything is open-source and written in LUA.
compu829 said:
I never did. I ended up creating a mysqueezebox.com account, installing the "Siriusxm" app there and used that to gain access to the legacy streams. It would be really nice if someone could write a nice squeezebox client for Windows phone as everything is open-source and written in LUA.
Click to expand...
Click to collapse
well it's done
search for it in the store
@clinton05 cool! thanks for the heads-up! how did you decide to connect to the back-end? I am just curious, and totally understand if you can't/won't share.
Hi!
Some guys and me are working on Android now for long time. Most times we had clear different parts we where working on, so two guys working on kernels, one on adaption of Android, one was testing and keeping contact to the community.
Now, cloning a kernel and merging some changes on drivers is a simple thing. And even changing a file on android, putting it into a git or simply on an ftp is easy too...
Well, now things have changed. Android is getting more complex and kernel work is mostly done.So we do more and more work in Android with more and more people.
Ok, one would say, take a plain android by using repo sync. Add your vendor parts for kernel and android and add them as a separate git. Ready you are...
Unfortunately that may work if you build your own device, based on plain naked android and a well supported mainlined kernel... But reality is different and chinese reality is even different^2. Hacking andoid devices where you do not have access to the OEM gits, kernels, not even datasheets or schematics is a hell of work... and all of these OEMs just checked out the complete android, put it in their own git and modified 1000 parts 'n pieces of it.
This isn't only a problem of bandwidth to upload such a monster, but all your friends supporting you have to clone that monster again. And after a while a new android version comes and you have great mess:
You cannot find differences from your old version to the new google version as many files have been changed by the OEM.
But you cant just "repo upload" cause google or CM might not be very eager to get dumb chinese deep down below android changes in their repos.
How do you team up with others and sync your android changes? Is there a good tutorial that handles not only the way it should be, but covers all these real-life issues?
I'd really appreciate your tips
Astralix
Hi everyone,
So the company that provides the TV channels in my country (like the cable companies in the US) has a streaming service that streams most of these channels online to phones, tablets, computers.
The problem is that their app is, according to them "not supported on hacked devices". Just so we're clear, we're talking about Android here, and hacked = root/custom rom, which this stupid company considers illegal. In some devices, they check both root and custom rom, in some only one of them, and in some the app will work even if you have both. For example, on my Nexus 4 the app worked with stock rom that was rooted. Now that I am running a custom rom, trying to hide root using various apps does not work. So obviously the problem, with my device at least, is running the custom rom.
I'm currently learning Java & Android development and have decided to use the little knowledge that I have to try to find the lines of code responsible for this idiotic check.
I looked up many tools for decompiling apps and have finally found a good one, called JadX.
http://androidcracking.blogspot.co.il/2014/03/jadx-dex-to-java-decompiler.html#links
This decompiler is excellent, but gives me a scary amount of code files to look. Even so, trying to search all of them (JadX has that functionality) for the code that checks for root/custom rom has turned up nothing. I have also tried to search for the message they give me when I open the app (about hacked devices not working) but I found nothing, again.
One more thing - a developer that also tried to solve this problem said he traced the problem back to DxDrmDlcCore. I searched it, found it a some class, but not sure what to do now (delete the entire class and recompile?)
Can someone here direct me towards what I need to be looking for?
OR
Is the solution really simple, such as editing my build.prop? Someone suggested it once, but did not know what lines to edit.
If someone is ready to step up to the challenge, I can upload the apk.
Thank you!