This is a definitely-for-development-purposes-only component that exposes
some functions to let you deliberately crash your application in interesting
Rust-code-related ways.
The idea is that application developers could add some developer-only UI that
deliberately triggers one of these functions, and then try out the crash or
error-handling behaviour of their app in a live setting. We hope to be able
to use this to debug symbolication issues on Firefox for iOS, ref #3907.
As a side benefit, the very process of adding this component has let me write
a couple of nice tests that our generated bindings are working as intend around
the edges of error and panic handling.
This is a substantial refactor of the fxa-client crate, intended to bring it
up to speed with our latest best-practices around developing cross-platform
Rust components, in order to ease ongoing maintenance.
THe core change here is that I've deleted the hand-written Kotlin and Swift
bindings, replacing them with autogenerated bindings thanks to UniFFI.
There is still a little bit of hand-written Kotlin, since we have a layer that
automatically manages persistence via a callback. There is still a nontrivial
amount of hand-written Swift, since we have a higher-level state machine built
atop the lower-level fxa-client functionality (such state-machine also exists
for Kotlin, but lives in the android-components repo). If UniFFI works out then
we should look into moving more of that logic into shared Rust code over time.
To support the introduction of UniFFI, I have restructured to Rust crate so
that its public interface deliberately parallels the interface offered to
Kotlin and Swift, and have moved the implementation details into a submodule
named `internal`. It's my opinionated belief that structuring the crate this
way will help us focus on producing a nice consumer API, which is not always
the same thing as producing a nice Rust crate.
On top of that, I've also revamped the documentation in the crate, leaning
in to the use of `cargo doc` as the source of truth for both developer-
and consumer-facing documentation. Let's consider that an experiment and
see how we like it in practice.
Unfortunately, this is a big PR, but I don't think I could have made it
too much smaller. Hopefully it will be easier to review than its size
suggests since it's mostly additions and deletions rather than complex
changes.
This is an attempt to simplify how we use `uniffi-bindgen`, by making
it easy to run the version used by the workspace rather than assuming
that the user has a correctly-matching version of it installed in their
system cargo.
The lockwise apps are on a very old version of appservices and I don't believe
we have a plan for updating them anytime soon. Continuing to build the lockbox
megazord does not seem like a good use of CI or local dev resources.
We understand how to bring this back if we need it, but also, if we do need
it again in future it's probably a good opportunity to revisit how we build
custom megazords in the first place.
This commit pulls in https://github.com/mozilla/nimbus-sdk as a
git submodule, and adds some build integration to publish it as
part of the application-services megazord. Instead of an all-in-one
nimbus package, we produce two separate packages:
* `org.mozilla.appservices:nimbus` with the Nimbus Kotlin code
* `org.mozilla.appservices:full-megazord` updated to include the
Nimbus Rust code.
Nimbus SDK and its dependencies are not currently compatible with
Rust v1.43.0, but application-services is pinned to that version
of rust for compatibility with mozilla-central.
This reverts commit 8388372259.
This commit pulls in https://github.com/mozilla/nimbus-sdk as a
git submodule, and adds some build integration to publish it as
part of the application-services megazord. Instead of an all-in-one
nimbus package, we produce two separate packages:
* `org.mozilla.appservices:nimbus` with the Nimbus Kotlin code
* `org.mozilla.appservices:full-megazord` updated to include the
Nimbus Rust code.
This commit reverts the protobuf schema, in favor of passing the
serialized ping directly. On iOS, we can pass this ping directly
through to the existing ping sender. On Android, we'll need to
unpack the ping into a Kotlin structure, and pass that to Fenix
via Android Components. Fenix can then assemble a Glean ping from
the Kotlin `SyncTelemetryPing`.
Sammy Khamis
Mark Hammond
Ryan Kelly
Dan Mosedale
Ryan Kelly
Edouard Oger
lougeniac64
Thom Chiovoloni
Thom Chiovoloni
Lina Cambridge
YLyu