IssueTracker

Not sure how desirable this is but it seems possible to serialize the resources themselves into the version string itself. (Which is passed through unmodified from onTileRequest to onResourceRequest.)

A version of more than 500000 characters does result in a binder transaction failure but that does give you a pretty reasonable amount of data to work with. (Is this amount guaranteed?) And certainly a lot of space for encoding a lot of information about resource state, if not the resource itself.

Re b/289799769#comment2 and very long version strings: as discussed with @tneda, this was never intended to work, and will be restricted.

10 would be too restrictive, I hope there is some flexibility to encode multiple resource ids, each maybe 10 characters long. So 200 at least?

I had a look for precedents for limiting Android APIs in this way but couldn't find anything. Do developers just know that if they pass 10x or 100x as much data as expected to an Android API, they might get a binder failure at runtime?

(Old bug complaining that large intent extras can fail in a similar way, which seems to be WAI: b/36912259.)

So, re the version string point, perhaps it's fine to leave as is.

Assumptions:

1. There's a low chance this limit will be significantly reduced in the future (due to architectural changes, etc.).
2. If/when the version size limit is reduced, only a very small number of apps are affected.

(If a lot of apps are making use of large version strings, it will be difficult to reduce the limit, because it will cause app compat problems.)

BTW I don't feel that strongly about this, but I think a limit in the ~200 chars range is less developer friendly than either ~10 chars or ~500k chars. Most apps will probably use less than 200 characters and so will test fine--but then could unexpectedly break in production due to manually created differences such as long usernames or domain names, etc.

If we add this, putting behind a targetSdk check would be nice for developers.