More granular Google Camera keyword support #396
Comments
|
Interesting, I would also like to work on this. Why do you think that a build.prop value will help with this? Is a Nexus 5 running marshmallow limited to 3.2 Google Camera from the Play Store? I haven't tested it. |
|
No basis for that idea, just a hope, and thinking-out-loud/spitballing between @mfonville and myself when we chatted about the issue. Marshmallow hammerhead is definitely limited to 3.2.x, but I'm hopeful that Android version is not the only limiting factor and we can find a way to have it installed to system on Nougat and not have it try to update itself to 4.x via Play Store. |
|
If marshmallow is limited to 3.2.x, then we can test if it's the version. Can you modify the build prop and check if an update comes? I doubt it too that they only check the prop. The problem is finding out what else they check. I thought about permissions in frameworks/native and checked them, but it seems they are the same as in marshmallow branches. Do opengapps add such permissions? Maybe we add something we shouldn't, I didn't check that. |
|
Unfortunately swapping out the Marshmallow build.prop for that of Nougat results in a broken device (constant Google Play services, etc., crashes), so unfortunately it seems it's not as easy as that to test. For comparison I've added the stock values below. N5 Stock build.prop: and getprop values: |
|
Hmm just did a thorough comparison and there's nothing useful different between the two sets of build/get props. So we've got an option here.. which is what others have done: Basically, Open GApps has hammerhead on a blacklist to force Camera 3.2.x, installs the proper framework files to go with that version of Camera, and uses a special re-signed APK so that it won't update via Play Store. |
|
Did you try changing just the Android version and fingerprint props? (From 6.0.1 to 7.x) |
|
Check out my CM14 ones in the issue post, CM keeps the fingerprint the same as stock. Changing SDK version is what breaks Google Play services since it's trying to execute code that doesn't work on Marshmallow. I flashed the zip from the above link, but with a re-signed Camera 3.2 apk (from here: https://drive.google.com/file/d/0BzjPCTvT_zbxTnVMSW1fVi1wWm8/) and it works well. So perhaps nothing but the re-signed APK are necessary. |
|
Nice!
|
|
Open GApps currently does this for 2.7.x as the CameraLegacy keyword, but something new would need to be added for 3.2.x and ideally on hammerhead (maybe others?) it should happen automatically. Open GApps could re-sign it to resolve the upgrade issue itself, yeah. I did a bit more testing and the 3.2.x camera over top of the 4.2.x libs/framework still doesn't have working HDR+, so those will need to be installed with re re-signed APK as well. Edit: Hmm looks like there's only a keyword to forcenewcamera, not the other way around to get googlecameralegacy? |
|
Nice testing. So @mfonville could we modify the Camera/CameraLegacy keyword, such as that it checks an array of device names before copying the apk? That would nail it. What do you guys think? |
|
I got HDR+ fully working on CM14.1 with 3.2.x by extracting the libs from the 3.2.x APK into /system/lib, so we should be good with something along those lines, with no changes to the jars required. 👍 Edit: But maybe extracting the libs wouldn't even be necessary if the APK is simply repacked and re-signed in the Nougat way? Edit 2: Yup. Totally works. That re-signed APK must not have had the libs deflated, so I did so and now it all works, so a properly modded APK is the only necessary change to /system. |
|
sorry for my late response So probably we need some extra testing, in if you really don't get the upgrade if appropriate frameworks are (not) installed. @KreAch3R yes, probably we will have to split out to 3 different versions; but best would be if build.prop would hint us the device hardware+driver capabilities and which variant to install. We can at the moment do that with legacy vs non-legacy. Otherwise we probably would end-up "whitelisting" 4.x-camera for certain devices (I think most devices don't support it... right?) |
This is nice to know, can you re-try that testing @osm0sis ?
Unfortunately, I can't think of something that would work across the board. For example, I know that in hammerhead and using the CM legacy HALs to get Google Camera working (but not HDR), you need to use these build.prop values: They will probably be there for every device that CM uses the legacy HALs on, (most of them) but you can't really be sure. And I don't know about whitelisting either, I have no idea where it works or not, but:
I think a specific blacklist with known devices will be the more appropriate option. You don't need to cover everything on your own, just depend on users reporting if Google Camera works on their device + Android version combo. For even bigger amount of control, ForceLegacy2, ForceLegacy3 could be a solution too, but I don't know how much of a logistics nightmare it becomes. :/ |
|
Not sure what I'd need to change to test that. Something in the permissions xml? build.prop? @mfonville was mentioning there might be a way to automate it with DummyDroid (the way they crawl for different APKs) to see what the Play Store offers given different conditions, but I don't have the setup for that. Could be a lot easier. I think ForceCamera2 ForceCamera3 ForceCamera4 would be best to allow people to override the logic and test whichever version they want/need. |
@mfonville is saying that the Play Store doesn't understand lib changes after you're signed in, so any tests you tried (by removing 4.x camera libs and testing in 4.2 Google Camera still appears on Play as update) will need to be re-done and after each change, a full account removal should be necessary. |
|
@marcomarinho for reference and testing purposes, this is the version with deflated libraries that will work from within the /system partition: https://forum.xda-developers.com/showpost.php?p=70442654&postcount=37 @KreAch3R I still think DummyDroid sounds like the best way to figure out if there's any other limiter to the version the Play Store is serving. I just don't have time to tear down the device that is still my daily driver this many times to try and figure it out when there might be a better automated way already at Open GApps' disposal. |
|
@KreAch3R It was an adb kinda day, so I took a stab at those tests again. 😜 Clean flash LineageOS 14.1 NMF26V + Open GApps 7.1.1 Stock 20170131 + Stock 6.0.1 M4B30Z build.prop = hung at bootanim. Tried with only ro.build.version.* and ro.build.date.* changed and still no luck. Clean flash Google Stock Marshmallow 6.0.1 M4B30Z + LineageOS 14.1 NMF26V build.prop = booted! And before things started crashing from a Google Play services forced update I got into the Play Store to see it try to serve up Google Camera 4.2.x! I even managed to download Camera 4.2 and find that (of course) it doesn't run since the system libraries don't match. So it does appear the Play Store update for Google Camera is only limited by the OS version reported from the build.prop; there's no other magic for us to figure out, Open GApps will need to re-sign the 3.2.x APK to ensure it doesn't try to update. @mfonville as for recognizing when it's needed, if a device whitelist consisting of hammerhead isn't sufficient, maybe it's worth noting that of the 3 values KreAch3R mentioned are used in Nougat hammerhead ROMs (camera.disable_zsl_mode=1 media.stagefright.legacyencoder=true media.stagefright.less-secure=true) only zsl also exists on stock Marshmallow. So maybe if all 3 exist then 3.2.x would be the better choice? |
|
Great debugging @osm0sis and I agree with your point in the end. At this point, the legacy HALs for nougat are here to stay. We can make the estimated guess that the devices using them are not going to do well with the latest Google Camera, so we could push 3.2.x as default and let those devices ForceCameraLatest if they truly want it? |
|
Absolutely, and I think making it more granular (N7 2013 still needs Google Camera 2.7.x) with ForceCamera2, ForceCamera3 and ForceCamera4 would be best; leaves it future-proof against more devices requiring specific versions so they can specify in .gapps-config rather than waiting for months on us to figure out how to automate it, and easier to add Google Camera 5.x, 6.x and so on as needed down the road. 😃 |
|
Okay, so @mfonville, what are the next steps for this one? I think we need you to weigh in on how you would like things to be structured. |
|
Still a problem technically, but possibly irrelevant since these devices are ancient now. 😛 I still like the ForceCamera# idea, with just the known milestone APKs, but no idea how to make that happen infrastructure-wise here, and you'd have to worry about how that would bloat up the zips too, so I'll open it back up for debate/roadmap reasons. |
osm0sis
changed the title
osm0sis
changed the title
Noted here: http://forum.xda-developers.com/showpost.php?p=69991796&postcount=120
Camera 4.x is getting installed on hammerhead with Nougat but these don't have working HDR(+) on this device due to deprecated drivers.
Another issue is 3.2.x will attempt to update via Play Store to 4.2.x.
@mfonville wondered if downgrading the related framework jar(s) would limit that, and I wondered if perhaps custom ROMs might need to add something to the build.prop that was missing -perhaps a value from Marshmallow, to restrict that.
N5 CM14.1 build.prop:
and getprop values:
The text was updated successfully, but these errors were encountered: