Chromium changes:
https://chromium.googlesource.com/chromium/src/+/7d3c16b9bb778a09b643288fe47bae4c1d8e53b7
commit 7d3c16b9bb778a09b643288fe47bae4c1d8e53b7
Author: Jingping Sun <jings@microsoft.com>
Date: Mon Apr 27 10:58:12 2026 -0700
[Unchecked] Enable -Xlint:unchecked for Chromium-owned code
Conditionally append -Xlint:unchecked to the base javac flags only when
options.chromium_code is true. This makes javac fail the build on any
new unchecked-conversion / heap-pollution / raw-type warnings in
Chromium-owned Java code, while leaving synced third-party Java sources
(chromium_code=false; auto-defaulted for third_party/ paths without
org.chromium namespace) compiled silently as before.
Why conditional, not global: Synced third-party Java code under
third_party/{junit,google-truth}/ src/ contains unchecked-warning sites
we cannot fix in chromium code base.
Bug: 358366667
Change-Id: I904b09cd4484098cee3b59e6d4aae94eba8d33ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7790536
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Peter Wen <wnwen@chromium.org>
Commit-Queue: Jingping Sun <jings@microsoft.com>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1621171}
This affects how targets are added now, and a shadow file had to be
corrected.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/bd7255bd8bf88581d34c38be1b16b05f7d5703b6
commit bd7255bd8bf88581d34c38be1b16b05f7d5703b6
Author: Vasilii Sukhanov <vasilii@chromium.org>
Date: Tue Mar 31 05:13:51 2026 -0700
Refactor: Move PasswordManagerSettingsServiceFactory to factories/
Moves password_manager_settings_service_factory.{h,cc} from
//chrome/browser/password_manager/ to
//chrome/browser/password_manager/factories/.
Eliminates the `password_factory_headers` source_set in
factories/BUILD.gn and wires everything cleanly to the unified
//chrome/browser/password_manager/factories target. All internal include
directives and BUILD.gn usages across webauthn, webid, autofill,
ui/passwords, and actor_login were adjusted properly.
Bug: 353332589
Change-Id: I318230d1df39b0b849a026977f00f2d3d0047831
Bypass-Check-License: moving the files
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7710837
Reviewed-by: Friedrich Hauser <friedrichh@chromium.org>
Commit-Queue: Vasilii Sukhanov <vasilii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1607791}
* Android: Implement favicons for Password Manager entries
We now display favicons for Password Manager as happens for our desktop
edition.
In order to do this, the C++ side now passes in the full origin so that
we have the clean, proper URI in order to fetch the favicon.
Resolvesbrave/brave-browser#52775
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/61a82a1566fd970e84e97a209528055da082b76e
commit 61a82a1566fd970e84e97a209528055da082b76e
Author: Henrique Nakashima <hnakashima@chromium.org>
Date: Mon Mar 2 13:10:58 2026 -0800
[Android] Null-annotate RootUiCoordinator (part 5)
This CL focuses on ModalDialogManager.
In different places it's nullable or not, and it is sometimes passed as
a Supplier and sometimes not. Generally, ChromeBaseAppCompatActivity has
a MonotonicObservableSupplier which in some subclasses never gets set,
but in the ones that create a RootUiCoordinator, the provider is set
before the RootUiCoordinator is created.
I've tried to keep Suppliers where instances are mostly passed via
Supplier and the actual ModalDialogManager where the Suppliers have
generally already been resolved.
Reduced NullAway errors down to 69 again.
Cq-Include-Trybots: luci.chrome.try:android-internal-dbg,android-internal-binary-size
Change-Id: I081f4cfab1a80dc074b2886a0ff59cb176feff30
Bug: 485252552
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7604913
Owners-Override: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1592697}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/416a61c418c152a7a7ae568d89302e5ecb6e4a3d
commit 416a61c418c152a7a7ae568d89302e5ecb6e4a3d
Author: Andrew Grieve <agrieve@chromium.org>
Date: Tue Dec 2 14:13:59 2025 -0800
Android: Split ObservableSupplier into Nullable / Monotonic / NonNull variants
The goal is to use proper @Nullable annotations with
ObservableSuppliers.
To achieve this, we use interfaces that define nullness:
* (Settable)NullableObservableSupplier
* (Settable)ObservableSupplier <-- monotonic
* (Settable)NonNullObservableSupplier
And we have ObservableSupplierImpl implement all of them.
In order to make this migration manageable, I've marked the interfaces
as @NullUnmarked, and will fix annotations in batches until they
can be marked @NullMarked.
This CL includes a batch in order to test out the new interfaces (and
because many were necessary to make the change).
Monotonic suppliers are by far the most common afaict, so that's why
the non-prefixed ObservableSupplier is the monotonic one (that, and
because "Monotonic" is a mouthful).
One implication of this approach is that we'll never have:
ObservableSupplier<@Nullable Foo>
We'd have instead:
NullableObservableSupplier<Foo>
Having the nullness in the interface rather than in the generic
allows for defining toNonNull() only on monotonic suppliers, and
simplifies the implementation.
Bug: 455874046
Change-Id: Id48e235b9ff16a5b21a9c1199863150d17c22736
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7206746
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Calder Kitagawa <ckitagawa@chromium.org>
Owners-Override: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1553094}
This PR does some IWYU for `base/memory/scoped_refptr.h` under
`//brave/browser`. This uses the standard script with the following
dataset:
```
HEADER_FUNCTION_SETS = [
(
'"base/memory/scoped_refptr.h"',
(
"scoped_refptr",
),
),
]
```
Bug: https://github.com/brave/brave-browser/issues/42212
When we fetch localisation strings which have different cases for
singular and plural, we should pass the count twice.
This is because the first argument determines whether the singular or
plural form will be used and the second one is used for substitution.
Technically, we could hard-code the first count param as a numeric
literal, but this gains us nothing and it is the opinion of the author
that using the variable as a single-source-of-truth is the better
approach.
Resolvesbrave/brave-browser#50245
Upstream removes login database during pref migration on Android.
We need to keep it otherwise passwords are wiped and recreated on
each app start.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/62fdf60f5e40bb6fc6bf31d292482c353be23dcc
[passwords/android] Drop fallback deletion of downloaded CSV on startup
UMA indicates this code path isn't exercised. Worst case, if the
deletion fails, the CSV can be downloaded again.
Unrelated to that: inline the code that deletes the LoginDatabase
files in browser_prefs.cc and move it to the bottom of the file. This
means the code will go away 1 year from now during browser_prefs
clean-up, without requiring any additional clean-up password manager
code.
OBSOLETE_HISTOGRAM[PasswordManager.AccountLoginData.RemovalStatus]=The deletion is done unconditionally and does not need metrics anymore
OBSOLETE_HISTOGRAM[PasswordManager.ProfileLoginData.RemovalStatus]=The deletion is done unconditionally and does not need metrics anymore
OBSOLETE_HISTOGRAM[PasswordManager.UPM.AutoExportedCsvStartupDeletionSuccess]=The startup CSV deletion was removed
Bug: 442347616
Change-Id: I5c18bdbb9cda6b37ae6f05540746bfb9cc4fe12c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6913683
- kLoginDataForProfileFileName;
- kLoginDataJournalForProfileFileName;
- MaybeDeleteLoginDatabases.
Chromim change:
https://source.chromium.org/chromium/chromium/src/+/62fdf60f5e40bb6fc6bf31d292482c353be23dcc
[passwords/android] Drop fallback deletion of downloaded CSV on startup
UMA indicates this code path isn't exercised. Worst case, if the
deletion fails, the CSV can be downloaded again.
Unrelated to that: inline the code that deletes the LoginDatabase
files in browser_prefs.cc and move it to the bottom of the file. This
means the code will go away 1 year from now during browser_prefs
clean-up, without requiring any additional clean-up password manager
code.
OBSOLETE_HISTOGRAM[PasswordManager.AccountLoginData.RemovalStatus]=The deletion is done unconditionally and does not need metrics anymore
OBSOLETE_HISTOGRAM[PasswordManager.ProfileLoginData.RemovalStatus]=The deletion is done unconditionally and does not need metrics anymore
OBSOLETE_HISTOGRAM[PasswordManager.UPM.AutoExportedCsvStartupDeletionSuccess]=The startup CSV deletion was removed
Bug: 442347616
Change-Id: I5c18bdbb9cda6b37ae6f05540746bfb9cc4fe12c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6913683
- password_manager::RegisterLegacySplitStoresPref
- password_manager::SetLegacySplitStoresPrefForTest
- kUpmUnmigratedPasswordsExported
- kEmptyProfileStoreLoginDatabase
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/e4d18fe2cd562dd016dafc60cdfe18b1bf2488f2
[android/passwords] Stop compiling LoginDatabase (pt 1)
Stops auto-exporting the LoginDatabase to a CSV in the Chrome app
data folder. Existing CSVs are left untouched and the UI to move them
to a different folder is still around. IsPasswordManagerAvailable()
now only depends on GmsCore version and the presence of the internal
backend.
Removes:
- kUpmUnmigratedPasswordsExported pref
- kPasswordsUseUPMLocalAndSeparateStores pref
- kEmptyProfileStoreLoginDatabase pref
- LoginDbDeprecationRunner and friends
OBSOLETE_HISTOGRAMS=The LoginDatabase auto-export was removed
Bug: 378652343
Change-Id: I7c8cd9e9d0adf35643634b15ef375153aa11d444
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6859683
* [Android] Refactor PasswordSettings.java to use an XML layout file.
The PasswordSettings.java file now integrates with a new XML file that
contains the layout for the page. This modification was completed using
Cursor but does not appear to have introduced any breaks.
There should be no semantic changes caused by this commit and the Brave
Password settings screen should continue to function exactly as it did
prior to this commit.
* [Android] Introduce new Import/Export items to password manager menu.
The password manager dialog now features two items for export and
import. Prior to this commit, Export was hidden away in a small
drop-down menu accessible from the top-right of the screen.
The import item is also present, but non-functional in this commit.
* [Android] Implement importing passwords from CSV.
We now support importing a CSV file containing the user's passwords.
This commit builds upon its parent by implementing the necessary code to
call Chromium's password manager which is responsible for executing the
import.
Additionally, the icons in the password manager screen have been changed
to new ones taken from Google's Material UI icon set.
Localisation strings have been introduced - some of which are copied
from Google's base since, after discussion, this is the way we currently
make strings usable for Android. If this changes in future, these could
be de-duplicated. Translations into other languages are still necessary
since only English is implemented.
Closesbrave/brave-browser#35729
Updated BravePasswordManagerAndroidUtilTest.
Replaced MaybeDeleteLoginDatabases with an empty implementation.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5794e9a0461497b7b810e9366c1c53eab711b6f2
[passwords/android] Limit kPasswordsUseUPMLocalAndSeparateStores access
No behavior change.
Instead of allowing arbitrary reads/writes to this three-state pref
(kOff/kOffAndMigrationPending/kOn), this CL exposes a minimal API to
satisfy production needs. This should prevent bugs like
crbug.com/428667627 and make it easier to get rid of the pref in the
future. The API consists of:
1. (existing) A bool getter which treats kOff and
kOffAndMigrationPending alike. It is renamed to include "Legacy"
and thus discourage new usages.
2. (new) A test-only bool setter. The pref is not updated in production
ever since LoginDbDeprecationAndroid launched.
3. (new) A function for pref registration.
Besides that:
* Rename SetUsesSplitStoresAndUPMForLocal() to
MaybeDeleteLoginDatabases(), since it doesn't set the pref at all
anymore.
* Stop unnecessarily setting the pref in tests where
UsesSplitStoresAndUPMForLocal() is never called (verified by
temporarily replacing the implementation with NOTREACHED and observing
whether the test crashes).
This definition of "unnecessary" is rather conservative, but handling
more tests is left for future CLs.
After this CL the legacy pref is only read in these places (only public
APIs are listed, not internal helpers):
* MaybeDeleteLoginDatabases()
* IsPasswordManagerAvailable()
* LoginDbDeprecationReady()
* LoginDbDeprecationRunnerFactory::GetForProfile()
Bug: 433682805
Change-Id: I987c653cdae9d9c862b80686950902dac9d27e9a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6691158
Files that use base::NumberToString() and friends should include
string_number_conversions.h directly instead of depending on transitive
includes from far away.
This is a mechanical change done with the following script.
```
remove_header_if_unused() {
files=$(git grep -l "base/strings/string_number_conversions.h")
for file in $files; do
if ! git grep -qE "base::NumberToString|base::StringToInt|base::StringToUint|base::StringToSizeT|base::StringToDouble|base::HexEncode|base::AppendHexEncodedByte|base::HexStringTo" "$file"; then
sed -i '/base\/strings\/string_number_conversions.h/d' "$file"
echo "Removed 'base/strings/string_number_conversions.h' from $file"
fi
done
}
add_header_if_needed() {
files=$(git grep -lE "base::NumberToString|base::StringToInt|base::StringToUint|base::StringToSizeT|base::StringToDouble|base::HexEncode|base::AppendHexEncodedByte|base::HexStringTo")
for file in $files; do
../tools/add_header.py --header '"base/strings/string_number_conversions.h"' "$file"
done
}
remove_header_if_unused
add_header_if_needed
```
Resolves https://github.com/brave/brave-browser/issues/46382
Related Chromium change:
https://source.chromium.org/chromium/chromium/src/+/2c75e2c2eb925ce0e5f2c7b59eb18cd5442f381c
[UPMLoginDbSunset] Disable the old UPM activation algorithm
With the login db deprecation, automatic migrations to UPM no longer
happen. Instead the unmigrated passwords are automatically saved to a
CSV that the user can download.
Instead of the previous algorithm, UPM activation will be determined by
checking that the correct version of GMS Core is installed and that no
unmigrated passwords remain.
In order to ensure metrics continuity, PasswordManager.LocalUpmActivated
and PasswordManager.LocalUpmActivationStatus will still be recorded,
but separately from the activation algorithm.
Bug: 378652664
Change-Id: I669c1dc9551daee18d1ee95f81887e178948a706
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6377026
Artem Samoilenko