Fixed
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Can you provide the below requested information to better understand the issue:
Can you please test with latest library and update result here.
https://developer.android.com/topic/libraries/support-library/revisions.html
If possible please provide a complete sample application.
Expected output
What do you expect to occur?
Current output
What do you see instead?
Can you please test with latest library and update result here.
If possible please provide a complete sample application.
Expected output
What do you expect to occur?
Current output
What do you see instead?
jo...@gmail.com
This seems to be intended according to https://issuetracker.google.com/74278849 , the suggestion is to remove the extra logic to deliverResult() in onStartLoading().
[Deleted User] <[Deleted User]>
@gg..@google.com
Sample project is attached.
Steps to test:
1. Import, build and install apk
2. Notice "Number of 'onLoadFinished' calls: 1"
3. Click "Click me!" button to start Second Activity
4. Notice "Number of 'onLoadFinished' calls: 2"
EXPECTED: At stap 4 "Number of 'onLoadFinished' calls" should be 1.
ACTUAL: It's 2.
@ha...@gmail.com
That's not the solution because developers are not in control of all Loaders. For example CursorLoader from support libaray should be then fixed by google, not by developers.
And this is behavior change which is not documented, so suggestion on issuetracker is not good enough.
Sample project is attached.
Steps to test:
1. Import, build and install apk
2. Notice "Number of 'onLoadFinished' calls: 1"
3. Click "Click me!" button to start Second Activity
4. Notice "Number of 'onLoadFinished' calls: 2"
EXPECTED: At stap 4 "Number of 'onLoadFinished' calls" should be 1.
ACTUAL: It's 2.
@ha...@gmail.com
That's not the solution because developers are not in control of all Loaders. For example CursorLoader from support libaray should be then fixed by google, not by developers.
And this is behavior change which is not documented, so suggestion on issuetracker is not good enough.
is...@google.com
We have shared this with our engineering team and will update this issue with more information as it becomes available.
Description
My view is that while this kind of cooperative application + compiler security bug is not particularly easy, it has the advantage of being supremely deniable.
Anyway, after Craig fixed this bug, it came back:
I have absolutely no basis for thinking this was malicious, but it's sort of failing the sniff test for me, and I would sleep easier if y'all at least gave this sequence of events some careful thought. I have no stake in this other than as one who is very interested in LLVM's correctness. Thanks.