Status Update
Comments
ap...@google.com <ap...@google.com> #2
+cc Siyamed and Matvei
-
For the context, there've been this bug
that also proposed to have a String overload for the foundation text field. This bug is marked as fixed. So I'm wondering whether we did not provide this primitive override on purpose.b/155211005 -
Since we're considering merging the BaseTextField and CoreTextField, do we want to have the primitive override in a single 'core' text field?
cc...@google.com <cc...@google.com> #3
do we want to have the primitive override in a single 'core' text field
I don't think so. This whole bug is a side effect of the naming problem we've already fixed. I would suggest to close this bug as fixed because of renaming and original problem being infeasible anymore.
If someone is reimplementing their TextField for their design need, I expect them to be ok with TextFieldValue hoisting or them be able to wrap this API with their string overload.
It seems reasonable to separate selection range and value long term, but maybe I'm missing some cases there where this might not work. Over to Siyamed to give some input here
Description
drop_caches doesn't work without root, so starting in S we should use the new b/178647679 )
perf.drop_caches
system property (SeeFor older devices, we should consider workarounds - can try manually flushing the disk cache by reading/writing large amounts of data to disk.