Closed mrcsh closed 3 years ago
I edited formatting of your issue.
quick note: Please use code fences when posting logs, for large log files please use a gist.
Is it correct that you are on Linux and targeting Android?
Yes, I am on running tools on Linux (fedora32 if it matters) and building Android (and also web which is why I need to use the beta channel) The code runs fine on Android when built with stable channel tools. The code also ran fine on Android using the beta channel tools before the last flutter upgrade.
I've managed to reproduce :D
It seems the Dart SDK used in Flutter 1.24.0-10.2.pre
includes https://github.com/dart-lang/sdk/commit/52783837369de45d3372cb6c6b7cdd63e71cd829
which bumps the dynamic library linking versioning in the Dart SDK. Hence, my code will refuse to run..
In this case I just need to update the files I've copied from Dart SDK into package:webcrypto
, as these files include the version number allowed. Getting this to work doesn't seem to hard, but I'm having some orthogonal test issues I need to debug before I can publish a fix.
@dcharkes this an interesting case, because I was already using Dart_NewFinalizableHandle_DL
it looks as if my code is entirely unaffected by the breaking change in DL API version 2.0, however, I'm unable to expression anywhere that I support both 2.0 and 1.1.
Worse, I can't update my already published package to say that it only supports Dart SDK <2.12.0
-- I'm not sure there is a possible solution to that short of only publishing with an SDK constraint <2.x
, where 2.x
is then next minor release -- so that I never promise compatibility with future Dart SDK verisons.
@mrcsh this should be fixed with webcrypto
version 0.2.2 -- it might happen in the future again as the DL API is still early :D
But this package only uses a very small set of the surface and it's quick and easy to fix it.
@mrcsh, curious, what are you using this package for? (if I may inquire :smiley: )
Awesome, thanks for the quick resolution. We are using it for end-to-end message encryption. I was having a hard time finding any single crypto package that worked well on mobile and web and supported what we needed, anything that relied on the bouncy-castle stuff was so slow on the browser it was not usable. This package had everything we needed and is fast on the browser. (Fast enough to be only slightly annoying without web compute() actually being asynchronous)
(Fast enough to be only slightly annoying without web compute() actually being asynchronous)
This package should be fully asynchronous on the web... or well, I guess that depends on the web browser, but this package passes crypto off to the browser when running on the web, which is why it's fast and hopefully moved entirely off the main-thread.
So even if compute was off-the-mainthread on web I don't think it matters much for this package, it matters if you do other expensive operations yourself, but the actual crypto operations this package does is passed to the browser using an async API. I don't know any browser vendor that wouldn't move that off-the-mainthread.
On Android and iOS this package is async in API, but the actual computation isn't moved off-the-mainthread YET, so using compute will make a difference (for now). The reason the entire API is async is because I want to move all computation off-the-mainthread, so that wrapping calls with compute
won't be necessary.
I think it's mostly a matter of finding out how to create a thread-pool do some callbacks/ports and manage life-cycle of the thread-pool, or borrow the thread-pool Dart has if possible...
It does not appear to be async on the web as far as I can tell, as the UI freezes noticeably during longer crypto calls. (Using chrome). Good to know the truly async stuff is coming in the future, I was wondering why given the async interface it still appeared to behave like it was synchronous.
It does not appear to be async on the web as far as I can tell, as the UI freezes noticeably during longer crypto calls. (Using chrome).
@mrcsh, are you doing crypto on large streams? the interface on web will convert streams into byte buffers before doing crypto (on web, on Andorid/iOS streams are streaming), so that could add some main-thread overhead.
If you're interested you're most welcome to investigate it further, it could be things like buffer copying that adds overhead.
I am encrypting/decrypting Uint8List(s). It is most notable on images larger than a few hundred kilobytes, with over a couple of megabytes taking 10s of seconds.
With the latest flutter beta update my app started throwing the following exception:
I am not sure why it thinks AS is not installed, it is installed and is running.