Skip to content

Conversation

@tarrinneal
Copy link
Contributor

@tarrinneal tarrinneal commented Dec 20, 2024

Follow up to #8187

Updates Android List<String> encoding/decoding to use JSON to avoid potential future breakages from restricted list types.

@tarrinneal tarrinneal marked this pull request as ready for review January 3, 2025 12:25
@tarrinneal tarrinneal requested a review from reidbaker as a code owner January 3, 2025 12:25
@tarrinneal
Copy link
Contributor Author

@stuartmorgan ready for review here as well

for (String key : allPrefs.keySet()) {
if (key.startsWith(prefix) && (allowList == null || allowList.contains(key))) {
filteredPrefs.put(key, transformPref(key, allPrefs.get(key)));
filteredPrefs.put(key, transformPref(key, Objects.requireNonNull(allPrefs.get(key))));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was requireNonNull needed here? Also this code is getting a bit difficult to parse. (A loop with a conditional that sets some transformed filtered data) Consider breaking parts out into methods or adding comments.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a change suggested by a warning I was getting in Android Studio. Since the method being called requires nonnull arguments and getting a value from a map doesn't programmatically guarantee a value. In this context, there would always be a value though.

if (value instanceof String) {
String stringValue = (String) value;
if (stringValue.startsWith(LIST_IDENTIFIER)) {
if (stringValue.startsWith(JSON_LIST_IDENTIFIER)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is where having the keys be similar starts to be important. That said from reading the code the reader does not know the keys are overlapping and it would seem safe in code review to swap the order of these if statements.

Consider making the keys independent so that you are not relying on the contents of the keys. If that is too much code change then consider making a "LIST_PREFIX" that can be checked so that it is at least clear in code what the relationship is.

If you want further reading see
https://www.16elt.com/2024/09/25/first-book-of-byte-sized-tech/

I think the first example explains the principal I am applying.

Copy link
Collaborator

@stuartmorgan-g stuartmorgan-g Jan 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider making the keys independent so that you are not relying on the contents of the keys.

This is something Tarrin and I had discussed offline; making it a prefix avoids this being a potentially (very unlikely, but still possible) breaking change, by using our already-reserved space.

I would strongly prefer we keep that, and adjust the code to make it explicit to readers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I can understand that fear and why it might fail. Thank you for being open to structuring the code differently so that the overlap is easier to follow for future maintainers.

@@ -1,3 +1,9 @@
## 3.0.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the breaking changes required? if not consider fixing/mitigating the security issue independent of the breaking changes. It makes it more likely for them to be adopted.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Breaking changes to shared_preferences have the potential to be quite disruptive to the ecosystem; I would strongly prefer we keep the legacy type support around to making a breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. I originally expected this change was going to end up being "technically" breaking due to the new prefix (before we discussed the prefix extension plan) so I wanted to wrap these long awaited breaking changes in as well. I'll revert them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Breaking changes to shared_preferences have the potential to be quite disruptive to the ecosystem; I would strongly prefer we keep the legacy type support around to making a breaking change.

Should I revert the error handling changes as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I revert the error handling changes as well?

I did this.

case 'String':
return _api.setString(key, value as String);
value as String;
if (value.startsWith(listPrefix) ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this list grow? if so consider making a set of prefixes to check.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't generally add types to shared_preferences since anything that all platforms don't support ends up with unpleasant complexity like the List<String> mess we are currently dealing with.

@@ -1,3 +1,9 @@
## 3.0.0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Breaking changes to shared_preferences have the potential to be quite disruptive to the ecosystem; I would strongly prefer we keep the legacy type support around to making a breaking change.

case 'String':
return _api.setString(key, value as String);
value as String;
if (value.startsWith(listPrefix) ||
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't generally add types to shared_preferences since anything that all platforms don't support ends up with unpleasant complexity like the List<String> mess we are currently dealing with.

@tarrinneal tarrinneal changed the title [shared_preferences] update List<String> encode/decode and other simple breaking changes [shared_preferences] update List<String> encode/decode Jan 7, 2025
Copy link
Collaborator

@stuartmorgan-g stuartmorgan-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tarrinneal tarrinneal added the autosubmit Merge PR when tree becomes green via auto submit App label Jan 24, 2025
@auto-submit auto-submit bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Jan 24, 2025
@auto-submit
Copy link
Contributor

auto-submit bot commented Jan 24, 2025

autosubmit label was removed for flutter/packages/8335, because - The status or check suite Linux_android android_platform_tests_shard_1 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

@tarrinneal tarrinneal added the autosubmit Merge PR when tree becomes green via auto submit App label Jan 24, 2025
@auto-submit
Copy link
Contributor

auto-submit bot commented Jan 24, 2025

autosubmit label was removed for flutter/packages/8335, because - The status or check suite Linux_android android_platform_tests_shard_1 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

@auto-submit auto-submit bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Jan 24, 2025
@tarrinneal tarrinneal added the autosubmit Merge PR when tree becomes green via auto submit App label Jan 24, 2025
@auto-submit auto-submit bot merged commit f7efc2b into flutter:main Jan 24, 2025
77 checks passed
@stuartmorgan-g
Copy link
Collaborator

It looks like this may have caused OOB failure in shared_preferences tests when it was published.

engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Jan 27, 2025
github-merge-queue bot pushed a commit to flutter/flutter that referenced this pull request Jan 27, 2025
flutter/packages@3d3ab7b...258f6dc

2025-01-24 [email protected] [shared_preferences] Add shared
preferences devtool (flutter/packages#8494)
2025-01-24 [email protected] [shared_preferences] update List<String>
encode/decode (flutter/packages#8335)
2025-01-24 [email protected] Manual roll Flutter from
c1561a4 to c1ffaa9 (21 revisions) (flutter/packages#8498)
2025-01-24 [email protected] [ios_platform_images] Switch to
`loadImage` (flutter/packages#8216)
2025-01-24 [email protected] [camera] Remove OCMock from
CameraExposureTests and CameraFocusTests (flutter/packages#8351)
2025-01-24 [email protected] [shared_preferences] Tool for migrating
from legacy shared_preferences to shared_preferences_async
(flutter/packages#8229)
2025-01-23 [email protected] Revert "[shared_preferences] Add
shared preferences devtool" (flutter/packages#8493)
2025-01-23 [email protected] [go_router] Fix
return type of current state getter to be non-nullable
(flutter/packages#8173)
2025-01-23 [email protected] Manual roll Flutter from
b2f515f to c1561a4 (18 revisions) (flutter/packages#8491)
2025-01-23 [email protected] [pigeon] fixes event channel dart
instance name usage and adds test (flutter/packages#8483)
2025-01-23 [email protected] [go
_route] fragment parameter added (flutter/packages#8232)
2025-01-23 [email protected] [in_app_purchase] Update
in_app_purchase_android version in in_app_purchase
(flutter/packages#8463)
2025-01-23 [email protected] [image_picker] Reference alternate
macOS implementations (flutter/packages#8487)
2025-01-23 [email protected] [rfw]
Activate leak testing (flutter/packages#8370)
2025-01-23 [email protected]
[video_player] Activate leak testing (flutter/packages#8379)
2025-01-23 [email protected] Manual roll Flutter from
b9e86a5 to b2f515f (42 revisions) (flutter/packages#8482)
2025-01-23 [email protected] [camera] Add API support query for
image streaming (app-facing) (flutter/packages#8422)
2025-01-23 [email protected] Manual roll Flutter from
b9e86a5 to eb6af3d (13 revisions) (flutter/packages#8473)
2025-01-23 [email protected] [shared_preferences] Add shared
preferences devtool (flutter/packages#8322)

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-packages-flutter-autoroll
Please CC [email protected] on the revert to ensure that a
human
is aware of the problem.

To file a bug in Flutter:
https://github.com/flutter/flutter/issues/new/choose

To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
@camsim99
Copy link
Contributor

This is causing shared_preferences/shared_preferences/example/integration_test/shared_preferences_test.dart: shared_preferences_async Async throws TypeError when returned getStringList type is incorrect to fail with what looks like an OOB issue and is blocking the tree currently:

══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following TestFailure was thrown running a test (but after the test had completed):
Expected: throws <Instance of 'TypeError'>
  Actual: <Closure: () => Future<Null>>
   Which: returned a Future that emitted <null>

When the exception was thrown, this was the stack:
#0      fail (package:matcher/src/expect/expect.dart:149:31)
#1      _expect.<anonymous closure> (package:matcher/src/expect/expect.dart:125:9)
<asynchronous suspension>
<asynchronous suspension>
(elided 6 frames from dart:async and package:stack_trace)
════════════════════════════════════════════════════════════════════════════════════════════════════

The plan is to revert.

@camsim99 camsim99 added the revert Label used to revert changes in a closed and merged pull request. label Jan 27, 2025
@auto-submit
Copy link
Contributor

auto-submit bot commented Jan 27, 2025

Time to revert pull request flutter/packages/8335 has elapsed.
You need to open the revert manually and process as a regular pull request.

@auto-submit auto-submit bot removed the revert Label used to revert changes in a closed and merged pull request. label Jan 27, 2025
camsim99 added a commit to camsim99/packages that referenced this pull request Jan 27, 2025
camsim99 added a commit that referenced this pull request Jan 27, 2025
androidseb pushed a commit to androidseb/packages that referenced this pull request Jun 8, 2025
Follow up to flutter#8187

Updates Android `List<String>` encoding/decoding to use JSON to avoid potential future breakages from restricted list types.
FMorschel pushed a commit to FMorschel/packages that referenced this pull request Jun 9, 2025
Follow up to flutter#8187

Updates Android `List<String>` encoding/decoding to use JSON to avoid potential future breakages from restricted list types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

autosubmit Merge PR when tree becomes green via auto submit App p: shared_preferences platform-android

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants