Closed Bug 2019953 Opened 14 days ago Closed 14 days ago

Update android nightly application-services version bump to new version 98f59750e2652dde6a5aab712ed2bbe63e536b16 from 2026-02-27 13:49:53

Categories

(Firefox for Android :: General, enhancement)

All
Unspecified
enhancement

Tracking

()

RESOLVED FIXED
150 Branch
Tracking Status
firefox150 --- fixed

People

(Reporter: update-bot, Assigned: update-bot)

Details

(Whiteboard: [3pl-filed][task_id: VdwpiNFqSOeJxMsk-gTvTg])

Attachments

(1 file)

This update covers 4 commits. Here are the overall diff statistics, and then the commit information.


mobile/android/android-components/plugins/dependencies/src/main/java/ApplicationServices.kt | 2 +-
mobile/android/android-components/plugins/dependencies/src/main/java/moz.yaml | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)


98f59750e2652dde6a5aab712ed2bbe63e536b16 by Jan-Erik Rediger <jrediger@mozilla.com>

https://github.com/mozilla/application-services/commit/98f59750e2652dde6a5aab712ed2bbe63e536b16
Authored: 2026-02-27 10:15:34 +0100
Committed: 2026-02-27 09:15:34 +0000

Don't log the database user version at warn level (#7248)

It's not really an actionable warning, nor does it hold much
information.

Files Modified:

  • components/logins/src/schema.rs

fdd8988bf755141b1afc4077a6c5174c00a2d77c by Mark Hammond <mhammond@skippinet.com.au>

https://github.com/mozilla/application-services/commit/fdd8988bf755141b1afc4077a6c5174c00a2d77c
Authored: 2026-02-26 19:32:38 -0500
Committed: 2026-02-27 00:32:38 +0000

Bug 1908824 - bookmark sync should not always consider bookmarks as modified "now" after being reconciled. (#7230)

When applying remote bookmarks to the local database, lastModified was
set to MAX(v.dateAdded, {now}) which in practice is always "now".
This caused all reconciled items appear "recently modified locally".
This in turn caused a sync after a reset to often re-upload all bookmarks as the
local bookmark "won" due to its recent lastModified, even though it
had never actually changed.

But a lastModified timestamp is not in the sync payload - it's purely a
local concept. So while it's not perfect, we use the server's modified
timestamp - that's likely to be close to when the record was most
recently modified somewhere.

The applyNewLocalStructure trigger was also problematic as this updated the
timestamp to now(), and this trigger executed for new incoming items. This
meant that the timestamp of an item might move backwards - it would end up
as now() as it was created, but move backwards to the server timestamp if
reapplied. There's no good reason for this trigger to change the
timestamp - if the item moved parents remotely then it will have a new server
timestamp.

A desktop patch landing under bug 2018096 fixes the same problem there.

Files Modified:

  • components/places/sql/create_sync_temp_tables.sql
  • components/places/sql/create_sync_triggers.sql
  • components/places/src/bookmark_sync/engine.rs

caacb076a22264d7359fe7c14661d804943cebd7 by Mark Hammond <mhammond@skippinet.com.au>

https://github.com/mozilla/application-services/commit/caacb076a22264d7359fe7c14661d804943cebd7
Authored: 2026-02-26 18:43:01 -0500
Committed: 2026-02-26 23:43:01 +0000

monorepo import script tweaks and bindgen fix (#7247)

Files Modified:

  • build-scripts/component-common.gradle
  • tools/import-app-services-to-central.sh

18cfb220c6c02aa2fcdfc453d89077c998435d52 by bendk <bdk@mozilla.com>

https://github.com/mozilla/application-services/commit/18cfb220c6c02aa2fcdfc453d89077c998435d52
Authored: 2026-02-26 14:46:16 -0500
Committed: 2026-02-26 19:46:16 +0000

Call ensure_initialized() in more tests (#7249)

Files Modified:

  • components/logins/src/db.rs

Assignee: nobody → update-bot
Status: NEW → ASSIGNED
Pushed by dsmith@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/4c7a2de64898 https://hg.mozilla.org/integration/autoland/rev/0aa9966707a9 Update android nightly application-services version bump to 98f59750e2652dde6a5aab712ed2bbe63e536b16 r=release-managers,diannaS
Status: ASSIGNED → RESOLVED
Closed: 14 days ago
Resolution: --- → FIXED
Target Milestone: --- → 150 Branch

The try push is done, we found jobs with unclassified failures.

Needs Close Investigation:

  • org.mozilla.fenix.ui.CrashReportingTest#useAppWhileTabIsCrashedTest

    • 2 of 4 failed on the same (retriggered) task
      - ui-test-apk-fenix-arm-debug (V0clEWanRJ6WTcFZgTpLtA)
      - ui-test-apk-fenix-arm-debug (eqExlscASki-FVA0h02V7A)
  • org.mozilla.fenix.ui.UnifiedTrustPanelTest#verifySecurePageConnectionFromQuickSettingsWithTrackersTest

    • 2 of 4 failed on the same (retriggered) task
      - ui-test-apk-fenix-arm-debug (V0clEWanRJ6WTcFZgTpLtA)
      - ui-test-apk-fenix-arm-debug (eqExlscASki-FVA0h02V7A)

These failures could mean that the library update changed something and caused
tests to fail. You'll need to review them yourself and decide where to go from here.

In either event, I have done all I can and you will need to take it from here. If you
don't want to land my patch, you can replicate it locally for editing with
./mach vendor mobile/android/android-components/plugins/dependencies/src/main/java/moz.yaml

When reviewing, please note that this is external code, which needs a full and
careful inspection - not a rubberstamp.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: