This required adding some duplicate entries in dependency-licences.xml.
Is this correct, or should we update tools/dependency_summary.py to
de-dupe them?
Switch from a crud-like API to an observation-like API for history metadata,
similar to what we have in places.
TitleObservation present in iOS bindings is temporary, necessary because
Firefox iOS doesn't currently use places history which provides an API for
noting page titles.
Directly executing `cargo` from inside of an XCode build doesn't
seem to work quite right, e.g. on Big Sur it isn't able to properly
build any `build.rs` due to problems with library paths in the linker
This copies the same technique that we already use for running `cargo`
to build a universal binary, but as a re-useable cargo wrapper rather
than a specific command.
* Add drawable and translatable strings to android
* Add image and translatable string to ios
* Add multi-bundle search for resources
* Add documentation and cleanup for swift
* Rename recordExposureEvent argument to sendExposureEvent to match docs
* Swiftlint/swiftformat
* Expose variables (as string) to foreign language
* Add comments about testing tooling
* Change Value to Map<String, Value>
* Ship strings over the FFI from Rust
* Receive strings from the Rust: Swift
* Receive strings from the Rust: Kotlin
* Address review comments
* Fixup dependency ordering check tool
* Dependency checker
* OMG clippy
The rust-ece crate has had its interface simplified to remove footguns,
let's update to that release and get a few cleanups of our own while
we're at it.
* Add Nimbus wrapper and test
* Reorganize and document Nimbus object code
* Swiftformat
* changelog
* Address reviewer comments
* Swift format II
* Add ADR0004 appName and channel
This brings a breaking change (but it's a bugfix) for iOS consumers:
Event timestamps are now correctly recorded in milliseconds.
Since the first release event timestamps were erroneously recorded with nanosecond precision.
This is now fixed and event timestamps are in milliseconds. This is equivalent to how it works in all other language bindings.
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.
Because:
* We recently switched from building a static library on iOS to
building dynamic library (ref #3822).
* Several places in our docs explicitly mention that iOS builds
are static libraries.
This commit:
* Updates the documentation to note that iOS builds are dynamic
libraries.
* Deliberately doesn't try to say anything clever about custom megazords
on iOS, since that's very much still to do.
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.
Glean changelog:
* General
* Allow using quantity metric type outside of Gecko ([#1198](https://github.com/mozilla/glean/pull/1198))
* Update `glean_parser` to 1.28.5
* The `SUPERFLUOUS_NO_LINT` warning has been removed from the glinter. It likely did more harm than good, and makes it hard to make metrics.yaml files that pass across different versions of `glean_parser`.
* Expired metrics will now produce a linter warning, `EXPIRED_METRIC`.
* Expiry dates that are more than 730 days (~2 years) in the future will produce a linter warning, `EXPIRATION_DATE_TOO_FAR`.
* Allow using the Quantity metric type outside of Gecko.
* New parser configs `custom_is_expired` and `custom_validate_expires` added. These are both functions that take the expires value of the metric and return a bool. (See `Metric.is_expired` and `Metric.validate_expires`). These will allow FOG to provide custom validation for its version-based `expires` values.
* Add a limit of 250 pending ping files. ([#1217](https://github.com/mozilla/glean/pull/1217)).
Note: This also gets rid of the 2 workarounds (removed code) in
AppService thanks to upstream changes.
This fixes the "Cannot inline bytecode built with JVM target 1.8 into
bytecode that is being built with JVM target 1.6. Please specify proper
'-jvm-target' option" problem.
- Updates components/support/error/src/lib.rs to have
its own backtrace rather than using failure::backtrace
- Changes all occurences of #[derive(failure::Fail)] with
#[derive(thiserror::Error)]
- Changes all occurences of failure::Error with anyhow::Error
- Replaces Result<T, failure::Error> with anyhow::Result<T>
- Bumps ece, find_places_db and hawk so that they don't use
failure either
- Modifies rc_crypto/ece_crypto to work with ece v1.2
Fixes#2334.
Adds an optional `ttl` parameter to kotlin and swift interfaces, to limit the time that tokens are cached.
The FFI uses a `zero` as a default parameter, but this is not exposed to either side of the boundary.
This is not expected to be a breaking change for the iOS and Android.
There where two issues. The most obvious is that the task name that
merges JNI libraries has evolved; it's now `merge{...}JniLibFolders`.
The second, which really caught me out, is that when both
`main.jniLibs.srcDirs` and `debug.jniLibs.srcDirs` contain the same
path, then the Android source set merger silently fails. I don't
really understand what's happening here, I just know that using only
`main.jniLibs.srcDirs` solves the issue.
Fixes#2659.
Some of our consumers use this handy plugin [1] to automagically
include dependency license info in their app. By including our
own dependency license info in our .pom file we can make it
easy for those consumers to include correct license info for
all the transitive dependencies they pick up through us.
[1] https://github.com/google/play-services-plugins/tree/master/oss-licenses-plugin
Nishant Bhasin
Mathieu Leplatre
Tarik Eshaq
Ben Dean-Kawamura
Sammy Khamis
Michael Cooper
Grisha Kruglov
Ryan Kelly
Mark Hammond
jhugman
Travis Long
Jan-Erik Rediger
Dan Mosedale
Dan Mosedale
Ryan Kelly
Edouard Oger
dependabot-preview[bot]
Thom Chiovoloni
Alessio Placitelli
lougeniac64
Thom Chiovoloni
James Hugman
Nick Alexander
YLyu
Ethan Glasser-Camp
Vlad Filippov
Mitchell Hentges