Hi,
I wrote an app the scans your moles in real time using augmented reality technology. On a decent android device it can get process at about 5 frames per second. It works really well, using frames given to me by the PreviewCallback method from the camera.
When i take the picture on the camera, i get out of memory exceptions. Now i clean up all bitmaps i use using the .Recycle but unless I call System.gc();
before i take the photo, i get the exceptions. Secondly this error is deep inside the Google android stack, and actually results in the Camera being unavailable to any other app, even if i stopped my app from running completely.
I find i strange that the google API would allow my code (Perhaps not great code) to physically disable hardware on the device.
Any suggestions other than keep calling System.gc()?
The app can be found on the android store called "Doctor Mole"
I didn't find = (
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?
Hi guys,
I am sadly still not able to edit the persons that are tagged in my photos.
I read that Google rolled out this feature at the end of 2019 already, but I still did not get it.
Is there any way to force enable this feature? I am rooted and I have EdXposed installed, if there is any module.
Greetings
So I learned that there is something called Camera2 API, which as far as I understand, allows third party apps to take full advantage of camera on your android phone.
There are 4 levels, the higher the level, the more features and more support you have.
Sadly, Xperia Z2 has no support for Camera2 API, when I install Camera2 API Probe App, it tells me that Hardware support level is "Legacy" which means no support for Camera2 API.
I was wondering, is this set in stone or can it be changed ?
Maybe by rooting or something, not sure.
Hence why I am asking here, do you know ?
So seems like Xperia Z2 simply has no Camera2 Api support and that's the end of that.
That's OK, next time when I go out to buy a new phone I will look for one that has this
As well as unlocked bootloader and sim.
Cheers
Hello together,
does anyone know why the ToF sensor on the 1 III isnt supported by the ARCore Depth API (see [1]) and if there will be a fix in the near future?
Are there any 3D scanner apps that can utilize the ToF sensor without relying on ARCore or is there an alternative ROM with ToF support?
Best regards,
some XDA greenhorn
[1] https://github.com/google-ar/arcore-android-sdk/issues/1327
Your github link already has the answer. It isn't supported because Sony did not implement the Depth API to use their TOF sensor. Simple as they didn't do it. This is the drawback of an "open" operating system. It is up to the OEM/Vendor/Manufacturer to implement features that are not "mandatory" by the OS creator, Google.
Why they didnt do it we will never know. It might be a way to reduce development costs. Maybe Sony thinks that their target market will only use the TOF for photography and not for anything else.
So there are no other apps that can take advantage of something that to the apps knowledge does not exist. Only Sony apps can "see" the TOF sensor, it is not exposed outside of that. No other apps will be able to see it unless they know how to access whatever API Sony maybe using. Or maybe Sony just access the TOF sensor directly in the camera app only, there is no API involved.
Maybe a third party rom can expose it if they can figure out how to access it, either via drivers released by Sony, or by their own trial and error, reverse engineering, etc.