Fixed
Status Update
Comments
vi...@google.com <vi...@google.com>
vi...@google.com <vi...@google.com> #2
Please provide following information which will help us to investigate this further,
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
[Deleted User] <[Deleted User]> #3
Certainly.
* What is the desired behavior of the feature?
For the onViewCreated function signature in Fragment.java to change from
public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
}
to
@MainThread
public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
}
* If relevant, why are current approaches or workarounds insufficient?
Thehttps://android.googlesource.com/platform/tools/base/+/studio-master-dev/lint/libs/lint-checks/src/main/java/com/android/tools/lint/checks/WrongThreadInterproceduralDetector.kt lint check and third-party tools such as infer ( https://fbinfer.com/ ) make use of these annotations to warn about clear violations of threading policy. When such a violation occurs in the onViewCreated() function, the tools do not warn me. My workaround is thus a mixture of StrictMode rules, integration tests, and crash reporting libraries, which can catch the violation at a later stage of development.
I'm attaching a contrived code example, with two images of how it can look in the IDE. In the first one the MainThread annotation is not present and the code seems to be free of errors. In the second, I've added that annotation to onViewCreated; Android Studio 3.5a5 is able to identify the coding error. I was able to reproduce with the 1.0.0 Androidx release of the Fragment class.
The document athttps://developer.android.com/guide/components/fragments#Transactions and the SDK docs linked from there at https://developer.android.com/reference/android/support/v4/app/FragmentManager.html#executePendingTransactions() are very clear that FragmentManager.executePendingTransactions() must be called "only from the main thread". Since such an advisory does not exist for Fragment.onViewCreated(), it seems possible that such a restriction does not apply.
* If relevant, what new use cases will this feature will enable?
It will allow more precise verification that functions invoked from Fragment.onViewCreated() (or an override thereof) do not violate threading guarantees. Moreover, it will allow that verification to occur during a standard lint check and thus provide warning well before code is committed or uploaded to a CI server.
* What is the desired behavior of the feature?
For the onViewCreated function signature in Fragment.java to change from
public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
}
to
@MainThread
public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
}
* If relevant, why are current approaches or workarounds insufficient?
The
I'm attaching a contrived code example, with two images of how it can look in the IDE. In the first one the MainThread annotation is not present and the code seems to be free of errors. In the second, I've added that annotation to onViewCreated; Android Studio 3.5a5 is able to identify the coding error. I was able to reproduce with the 1.0.0 Androidx release of the Fragment class.
The document at
* If relevant, what new use cases will this feature will enable?
It will allow more precise verification that functions invoked from Fragment.onViewCreated() (or an override thereof) do not violate threading guarantees. Moreover, it will allow that verification to occur during a standard lint check and thus provide warning well before code is committed or uploaded to a CI server.
vi...@google.com <vi...@google.com> #4
We have passed this defect onto the development team and will update this issue with more information as it becomes available.
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 5c26346135ab721b111109cffe4b2ef7f2ec3ce8
Author: Ian Lake <ilake@google.com>
Date: Wed Jul 03 10:44:25 2019
Add @MainThread to Fragment lifecycle callbacks
Ensure that Lint and other tooling is aware
that Fragment lifecycle callbacks are run on
the main thread.
Test: ./gradlew checkApi
BUG: 127272564
Change-Id: I499266565229ebd68c0511c374ca6794a8ce5d97
M fragment/fragment/api/1.2.0-alpha02.txt
M fragment/fragment/api/current.txt
M fragment/fragment/src/main/java/androidx/fragment/app/DialogFragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
https://android-review.googlesource.com/1011465
https://goto.google.com/android-sha1/5c26346135ab721b111109cffe4b2ef7f2ec3ce8
Branch: androidx-master-dev
commit 5c26346135ab721b111109cffe4b2ef7f2ec3ce8
Author: Ian Lake <ilake@google.com>
Date: Wed Jul 03 10:44:25 2019
Add @MainThread to Fragment lifecycle callbacks
Ensure that Lint and other tooling is aware
that Fragment lifecycle callbacks are run on
the main thread.
Test: ./gradlew checkApi
BUG: 127272564
Change-Id: I499266565229ebd68c0511c374ca6794a8ce5d97
M fragment/fragment/api/1.2.0-alpha02.txt
M fragment/fragment/api/current.txt
M fragment/fragment/src/main/java/androidx/fragment/app/DialogFragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
il...@google.com <il...@google.com> #6
We've added annotations to the lifecycle methods and they'll be available in Fragments 1.2.0-alpha02.
Description
I'm trying to confirm some threading assumptions in a codebase. It currently boils down to the following question:
Can I assume that Fragment.onViewCreated() and Fragment.onResume() are always called on the application's main thread?
As far as I can tell there is no reason for either to be called on a worker thread, but I'm worried my assumption might cause trouble in the future. I'd like to request the addition of "@MainThread" and/or "@AnyThread" to those methods to alleviate that uncertainty.