Some modules were using package names or namespaces inherited from copy-paste
or from older module names (e.g. `features.logout.impl` in the deactivation
module, `features.api` in the migration api module, `sessionstorage` in the
cachestore module), or containing typos (`roomaliasesolver`,
`roomdetetailsedit`).
Move the sources to the package matching their module, update the imports, and
rename the impacted screenshots accordingly.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Remove dependencies flagged as unused by the Dependency Analysis Gradle Plugin
(`./gradlew buildHealth`) and explicitly declared in module build files.
Removals were skipped when the dependency provides transitively something the
module (or a consumer of an `api` dependency) uses directly, as well as for
runtime-only dependencies (element-call-embedded, sentry-android,
rustls-platform-verifier). Dependencies added by the convention plugin helpers
(composeDependencies, testCommonDependencies) are left untouched.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Extract `IsEnterpriseBuild` use case
Having it inside `EnterpriseService` made having DI cycles with the `BuildMeta` provider too easy
* Rename `EnterpriseService.defaultHomeserverList()` to `homeserverAllowList()`
This seems more aligned with the way this list works
* Move most of the logic from `:libraries:wellknown` to `:enterprise:feature:enterprise`, both `shared` and `impl` modules
Ideally I would have added everything into `impl`, but some of the classes needed to be shared between the different `:enterprise:features` modules, and those are in the `shared` module, lacking a better name/strategy
* Add `EnterpriseService.isElementProEnforced`
With this, we don't need to provide the `RemoteEnterpriseConfig` anymore to any consumers, everything goes through `EnterpriseService` or other providers
* Remove `EnterpriseService.overriddenElementWellKnown`
This leaks the remote enterprise config/element well known contents to the app in a public interface.
* Create `CustomMapTilerConfigProvider` to avoid leaking the `RemoteEnterpriseConfig` in public APIs
This commit also starts moving some of the well-known related values to the enterprise modules
* Add missing docs to `EnterpriseService` and `SessionEnterpriseService`
* Fix tests
* Fix lint issues
* Bump enterprise module
Document WellknownRetriever, ElementWellknownStore, ElementWellKnownParser and
their factories, along with every member.
The caching semantics are the part callers need and cannot see in the signatures,
so they are recorded here: the store reports entries older than a day as outdated
rather than missing, the retriever returns such a value immediately and refreshes
in the background, an enterprise build with a hardcoded configuration
short-circuits entirely, and the parser ignores unknown JSON fields.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Also, allow instantiating it using a factory: with this we can always decide where to take the config from and how to do it
Do the same for `ElementWellknownStore` so we can store and restore the values for different sources (endpoints) independently
* Add `ExtraDeveloperOptionsRenderer` to display extra UI components in the developer settings screen. It defaults to not displaying anything, using `NoopExtraDeveloperOptionsRenderer`
* Add `EnterpriseService.overriddenElementWellKnown` method to fetch the current overridden element well known value, if any
* Modify the well known retrievers to use the overridden value if it's there. Also extract the JSON parsing to its own `ElementWellKnownParser` component.
* Bump enterprise repo reference.
* Allow HS to disable encryption in Element Pro
Add `force_disable_e2ee` support in the Element well known retriever and cache to allow a homeserver to disable encrypted room creation and enabling encryption in an existing room in Element Pro clients
* Bump enterprise repo back to `main` branch
* Create a `ContentScanner` component:
- Add `:features:contentscanner:api` module with the interface.
- Implement the concrete component using the Rust SDK in `:libraries:matrix:impl`.
This can be used to both set up the content scanner media fetching in the SDK Client and manually scanning media sources from the Android side
* Create `ContentScannerUrlProvider` in a new `:features:contentscaner:api` module as a noop implementation
Use it as a placeholder for the code to instantiate a `RustContentScanner` with the fetched URL and set it as part of the SDK client.
* Expose the optional `ContentScanner` in the `@SessionScope`
* Split the storage part of the Element well-known retriever so it can be reused for the non-session bound retriever.
Also add the new `content_scanner_url` field to it.
This will be used by the enterprise code to fetch the actual content scanner url.
* Bump enterprise commit to have access to the actual content scanner url provider implementation
* Fix tests and lint issues
* Use the right namespace for `:features:contentscanner:api`, also use the right namespace for `impl`
---------
Co-authored-by: Benoit Marty <benoitm@element.io>
The merged element-enterprise#261 well-known schema advertises the feature
under custom_recovery_passphrase (no _settings/_requirements suffix), so the
parser previously looking for custom_recovery_passphrase_settings would never
activate the flow. Update the @SerialName and drop the narrow "Requirements"
suffix from the type — the block is now general, extensible feature settings —
to mirror the .pkl CustomRecoveryPassphrase class. Bumps the enterprise
submodule to the matching consumer change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When the homeserver advertises custom_recovery_passphrase_settings, always run
the custom passphrase flow, flooring min_character_count at 1 (covering missing,
zero, and negative values) so the derived passphrase can never be empty. Any
stronger minimum stays the operator's choice. Replaces the previous behaviour of
dropping the spec and falling back to the auto-generated key.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add CustomRecoveryPassphraseRequirements to ElementWellKnown and decode
the custom_recovery_passphrase_settings block (currently just
min_character_count) from the homeserver's element.json. Invalid specs
(missing or non-positive min_character_count) are logged and mapped to
null so the setup flow falls back to the generated-key path. Field names
match the ESS well-known schema (element-enterprise#261).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Use the SDK `Client` to check whether a HS is compatible
* Remove usage of unused `WellKnown`, keep `ElementWellKnown`
* Make `HomeServerLoginCompatibilityChecker.check` return `true/false` values to distinguish non-valid homeservers from a failed check
* Use `inMemoryStore` and `serverNameOrHomeserverUrl`
* Do some cleanup of `isValid` and `isWellknownValid`
* Make the debounce for starting the search a bit higher, as checking for the homeservers seems more resource-intensive now
Benoit Marty
Benoit Marty
Jorge Martin Espinosa
Jenna Vassar
Benoit Marty