Due to a bug described in:
https://issuetracker.google.com/issues/110237303
Ordering of resources can be non-deterministic.
A comment on the issue indicates that this may be resolved in
Android Gradle Plugin 3.4. We should revisit when we update.
The recent switch to Python3 (2ccdf0e396e82dd) introduced a regression
that led to file content no longer being compared:
In compareEntries(), two generators/iterators are created:
sourceInfoList = filter(lambda sourceInfo: …, sourceZip.infolist())
destinationInfoList = filter(lambda destinationInfo: …, destinationZip.infolist())
Few lines later, those are exhausted:
if len(sourceInfoList) != len(destinationInfoList):
Yet another few lines later, the exhausted generator is used again:
for sourceEntryInfo in sourceInfoList:
… # <-- unreachable
This is caused by behavioral differences between Python2 and Python3:
user@z_signal:~$ python2
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = filter(lambda i: i % 2 == 0, [0, 1, 2, 3, 4, 5, 6])
>>> list(f)
[0, 2, 4, 6]
>>> list(f)
[0, 2, 4, 6]
>>>
user@z_signal:~$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = filter(lambda i: i % 2 == 0, [0, 1, 2, 3, 4, 5, 6])
>>> list(f)
[0, 2, 4, 6]
>>> list(f)
[]
>>>
- Check for permissions.
- Fix Welsh positional format.
- Remove UIThread restriction.
- Asynchronous method does not need to be restricted to UIThread and there is no StaticFieldLeak to suppress.
- Fix or Ignore New API errors.
- Reduce severity of some errors from L10N.
We observed IOExceptions loading the Contact Discovery IAS KeyStore. We will now throw an AssertionError upon any error
creating the IAS KeyStore, matching the behaviour for creation of the TrustStore used for the main Signal Service. NB: If
this assertion is hit, the user will not even be able to refresh their contacts with the old directory service.
We never make requests to non-whitelisted domains, but there were
situations where some links would redirect to non-whitelisted domains,
which would hit a final failsafe that resulted in a crash.
To prevent this, we detect bad redirects earlier and fail more
gracefully.
Fixes#8796
