Support Library v25.2 Released
developer.android.com/topic/libraries/support...Posted Feb 21, 2017, 6:15 PM UTC
3636
developer.android.com
Still coordinator anchoring problem is not fixed. Stuck with 24.x :(
5
Yay! I didn't have any issues after updating to this version.
3
\o/ Good to hear
3
How difficult is it to just not touch Fragments' Lifecycle for once? I hope that this is not branched from version 27 :P
2
Is there a specific thing that broke for you?
6
Quite a few fragment lifecycle and backstack changes are not allowing our team to start using latest support library versions, for example:
6
3 of those are marked FutureRelease, so those fixes should come soon. The last one, I pinged the owner of the code to look at it.
10
Honest question: with all the bugs developers keep discovering in the Fragments API, which is more than 5 years old, how come Google hasn't just replaced them with something more reliable? They say you can't test quality into software, maybe its time to start over.
13
Shared element fragment transitions also crash now if you clear the stack and then replace a fragment unless setAllowOptimize(true) is used. Seems like you just need to always set that flag now unless commitNow() is used, which usually breaks animations. Been meaning to file a bug for this https://github.com/gravesisme/shared-transition-crash-example
1
Please file a bug and share link here. I will assign it to the right person.
4
Did these bugs get fixed in this update?
1
We have not tried yet, but as the Android team member mentioned above, they are scheduled for future release, not this one.
2
I am quite hesitant to try the new version, just because I am afraid that something else has been broken this time as well.
1
We understand and as I noted in another response in this thread we are hard at work to make it less of a fear. If there are specific areas that you see a lot of regressions in, feel free to PM me or file a bug and we can take a look at it (don't just say Fragments as that's not super actionable)
3
So you want to tell me that the only thing that was documented and you already responded to it, is the only thing that broke? What about the wrong order of lifecycle when restoring a Fragment with ChildFragments? I did not see a response for that one or a documented change. I also do not feel confident about filling a bug, cause guess what, most of those bugs that I follow, those that broke something crucial as well as those that have been unsolved for a long time, are just getting "Comments-Closed" from the moderators and no response or an ETA. A lot of Android Engineers are complaining about this, but it seems to me that the Dev Relations team or even the Google Devs themselves, do not want to deal with it anymore.
Sorry for the long post, but I had to say it on a social medium, where I do not risk getting blocked, just by stating the obvious, to a Google engineer. We can definitely take it over with PMs if you want.
2
Didn't they apologize for making a mistake last time? They used a Dev branch for fragments so they would fix it in this one, am I right?
2
Yeah, that was the mess of 25.1.0. Explanation here
6
[deleted]
1
It looks like FingerprintManagerCompat is still broken on many devices.
My Reprint library fixes that bug and a number of other bugs in the Imprint fingerprint implementation. (I've posted about the library before here)
1
It is not broken, it is disabled on a number of devices which do not return true for FEATURE_FINGERPRINT that means it was not certified and tested for that feature so you might hit crashes or unexpected behaviors. Continuing to use finger print feature you are at risk of undefined behavior. A check was added to support library exactly to prevent this kind of scenario. It would be nice of you to add that note to your libraries README if you choose to ignore this check.
7
That is not something that end users understand. Devs are put in an very hard position, either tell users "yes your device has a fingerprint scanner, and your device is certified to run Android, however the fingerprint scanner isn't officially considered a fingerprint scanner by Android so it might not work properly" or they have to hack around the support library because the support library is written for an ideal version of Android that essentially does not exist outside of lab conditions.
It reminds me of the appcompat issue on Samsung devices https://code.google.com/p/android/issues/detail?id=78377 with responses like "First off, this is not an appcompat issue". It 100% was (and I'm glad it was finally addressed). Yes Samsung make the screw up, but that is what Samsung does. The support library needs to work on Samsung devices, and that includes working around Samsung's mistakes.
As app developers, it's our responsibility to make our apps work well on actual real world android devices. As a support library developer, I plead with you to build a library to help us support actual android devices that exist in the wild. Presumably there is a team somewhere who is supposed to work with OEMs to get them to support Android APIs, but while that team, and OEMs, slack off, we still need to keep our apps working on those devices.
(But I agree that both the reprint library and the support library should warn developers about this situation)
8
We are not trying to be anti-user or anti-developer. I agree that there is a balance between sticking to existing behavior vs adding a whitelist of devices. There is a significant risk associated with a whitelist. I would like to see a list of device models (please add them to the bug) that are in this state, if it is in fact a large set we can consider a whitelist. Is it just OnePlus devices?
The issue is simply that one of these devices that returns FEATURE_FINGERPRINT false can receive an OTA on day and it would pass Android CTS tests as they do not advertise this feature (so it does not even get tested for fingerprint support), however that same OTA could cause crashes when your app calls fingerprint APIs. Users will very likely blame your app for crashing rather than the device manufacturer.
4
I understand that you want to be conservative in what you support. But when I get hundreds of users of my apps reporting that fingerprint support stopped working because of a minor release of the support library, I would consider it broken.
Did the Support Library team announce that they were disabling fingerprint support on those devices? I've never seen it documented anywhere.
I created Reprint specifically because many devices have buggy fingerprint support, and the Support Library doesn't try to fix any of those problems. And it's understandable that the Support Library wouldn't want to become a giant pile of device specific hacks. But I think developers would rather use a library that fixes the problems that they will encounter in the wild rather than one that forces them to discover and deal with the issues themselves.
3
It was really a bug that we did not use this check from the introduction of this API.
Do you have a list of unique device models that fail in this way? (please add them to the bug)
2
Whats the current status for this fragment's bug? https://code.google.com/p/android/issues/detail?id=42601 It's been on "Future release" for almost 3 years.
1
And still appcompat-v7 does not use support-v4 split dependencies... Ref: https://code.google.com/p/android/issues/detail?id=230352
1
Yup. Funny they touted that as a major "improvement" of modularizing the support library but yet using appcompat (which is probably the 2nd-most-used support module behind support-v4) completely negates that entire attempt at modularization, and makes all that touting pointless.
1
AppCompat depends on every library in v4. Commented on the bug.
1
Wow, very quick release after
25.1.1. Looks like some very good fixes. However I really hate to say this, but new support library releases always make me nervous, especially one released this fast... Hopefully there aren't any (bad) surprises.Yeah, this release happened due to mediarouter bug. We have fixed it and we added regression tests, so at least that specific bug should not come back.
Overall, I agree. Support library needs to be a much more stable project than what it used to be in the past. I am one of the people on the team working on just that. We have extended our automated test runners to run on more API levels (we cover pretty much every version between API 15 and API 25). Next, every regression like the one in mediarouter now comes with a regression test (we have been quite bad at these kind of follow ups in the past). Additionally, we have enabled coverage on our automated test runs and we are looking into areas that need more tests (e.g. CardView has no tests 😠). Finally, we are hoping to start an ongoing beta/preview channel for support library that will hopefully help us go from X.X.0 -> X.X.1 less quickly than we do now.
just wanted to say thank you for these insights and letting us now that you are aware and absolutely commited to fix these things :thumbsup:
is there any roadmap for targeting api 14?
We always target the latest API level 😉 ...but in all seriousness, we are looking into bumping up minSdk as fewer and fewer apps go with minSdk less than 14.
Yeah it's unfortunate with every list of bugs they fix in each release, they always seem to add just as many new bugs.
Guys, please don't give as update with 300+MB, upload support library to maven