IssueTracker

Are there many use cases for this? The current logic works fine with dark mode of platform, appcompat, and Compose.

When I was trying out integrating this with Now in Android, I ran into this issue since Now in Android currently doesn't inherit from AppCompatActivity and doesn't call AppCompatDelegate.setDefaultNightMode, so maybe the solution is instead to inherit from AppCompatActivity instead of just ComponentActivity to update the underlying configuration.

I just tested it with ComponentActivity. It's working fine for me. The scrim for 3-button nav and the icons are properly changed on light/dark mode switch. The extension function detect light/dark mode from resources.configuration.uiMode which is commonly used by the platform, AppCompat, and Compose, so I don't know why it doesn't work. Can I take a look at what you tried in Now in Android.

https://github.com/android/nowinandroid/tree/av/enable-edge-to-edge is the rough progress I made so far.

The theme switcher based on the user's preference within the app is handled separately from Configuration.uiMode and isn't updating the configuration directly, so I was attempting to call enableEdgeToEdge and manually specifying the dark and light themes.

The two options I see:

• Allow a different way of specifying for enableEdgeToEdge whether the app is effectively in dark mode or light mode instead of that being based just on Configuration.uiMode (this issue)
• Switch Now in Android to use AppCompatActivity and AppCompatDelegate.setDefaultNightMode so that the Configuration.uiMode is updated based on the user's preference

I see, so it has in-app light/dark setting.

On API 31+, apps with custom in-app light/dark settings should call UiModeManager.setApplicationNightMode to declare its theme to the system. This way, the system can use suitable colors duiring the splash screen. This should fix enableEdgeToEdge as well.

On API <31, it's easy if you can use AppCompatDelegate.setDefaultNightMode(int), but I can understand that you don't want to add appcompat dependency just for this.

So, custom mode is useful for apps that:

• Provide in-app light/dark mode settings on API <31.
• Don't want to depend on appcompat

I'm not sure if it's super common, but I guess the feature is worth implementing. I'll put it during the next alpha phase.

For Now in Android, I recommend you still call setApplicationNightMode on API 31+ regardless of enableEdgeToEdge. On API <31, just for the time being, you can either use the current e2e implementation, hide the setting, depend on appcompat, or just bear with the minor UI glitch. None of these are great, but I don't have a good solution now.

Thank you for reporting this issue. We just need a few things for us to further investigate this issue:

Please fill out each question and comment, thank you.

• Have you observed this bug on Pixel devices as well?

• Android Build Version (go to Settings > About Device > Build Number (hold down to copy))

• Android Device Model:

• Capture the issue in a screen recording (desktop and/or phone capture) to show an example of the issue.

• Upload the full bug report file after the issue has occurred. Steps followed here: https://developer.android.com/studio/debug/bug-report

• Please provide a simple sample project (exported zip Android Studio file) that reproduces the issue. This gives us the closest test environment to yours and allows us to inspect the code/structure used which will help analyze your issue.

• Steps to reproduce issue specific to the provided sample project, including steps steps to reproduce with test certificates etc... [Be as specific as possible]

  • 1
  • 2
  • 3

• Expected Results:

• Observed Results:

Note: Please upload to google drive and share the folder to android-bugreport@google.com, then share the link here.

The more information we have, the more accurately our product and engineering team can solve the issue. Thank you so much for your time and for your cooperation.

It seems to me that you are rather looking for an excuse to close this issue rather than try to fix it. KeyChain.createInstallIntent() has been pulled, but has legit use cases. The scope of use is narrow, thus the posed resolution of add an adb command to import a certificate.

This isn't a bug - it's an essential but missing feature. It's an issue on all Android 11+ devices, including Pixel devices, and all Google Play Android emulators.

It's not possible to make a screen recording, upload a bug report, or provide a sample or repro steps, because the functionality doesn't exist. The previous KeyChain.createInstallIntent() did provide similar functionality, but that's been removed (for good reasons).

In general, these security restrictions are good for normal users, but I think there is a strong argument that Android developers should still able to automatically configure user CA certificates on their own devices. Providing this capability via ADB only seems like a sensible way to expose that functionality only to developers. There's clearly a lot of support for this, as you can see from the other comments and stars here.

It looks like there are simple ways to implement this, if there is the appetite. For example, you could create a tiny on-device command runnable only by ADB which takes a path to a certificate and sends a certificate install intent with that path to CertInstaller (just like the settings do and as some apps used to do pre-Android 11), and then change CertInstaller to accept such intents from that command (or from the ADB user in general). That would be sufficient.

Right now CertInstaller is capable of automatically installing certificates, but it limits who can send the intents to do so, so that it's only possible from the Settings app. The specific CertInstaller lines that currently limit this access are here:

• https://android.googlesource.com/platform/packages/apps/CertInstaller/+/master/src/com/android/certinstaller/CertInstaller.java#244
• https://android.googlesource.com/platform/packages/apps/CertInstaller/+/master/src/com/android/certinstaller/CertInstaller.java#356

Great update. Thanks. The product and engineering teams have been updated.

Why limit this to only user certificates? There is an important and legitimate use-case when a person would need to install a certificate to the system CA store. Security researchers need to be able to inspect Android apps traffic. Currently, the only way to do this is to use a rooted device which is hardly an acceptable way. Since this is a system CA store that, in theory, shouldn't be modified, I suggest providing an option that will install the certificate temporarily. For instance, until the device reboot.

It is acceptable to prevent users from installing certificates If they do not READ AND ACKNOWLEDGE BIG SCARY WARNINGS ⚠️

It is not acceptable to prevent legitimate developers from installing CA certs, at least at the user store level, with sufficient trust to achieve their limited scope usage cases.

We can develop things; like for example your key icon for VPNs; to inform users that custom certificates are in use. Perhaps a secondary icon like a certificate with a key overlay on it.

While I think ADB can possibly be a vector of attack; I also believe it is protected now by modern RSA Fingerprint verification and appropriate SCARY WARNING ⚠️ dialogues to prevent casual exploitation.

It shouldn't be the mission of Android OSP to prevent social engineering attacks; only make them difficult enough by informing the end user of what they are doing. It isn't your fault if people choose to ignore prominent warning signs.

If we can't trust the current iteration of ADB security then we need to up it more; and that may even mean we start forcing users of ADB to generate and install debug bridge certificates in full to make them acknowledge the BIG SCARY WARNING ⚠️ at least once.

Great article with sovereign securities and global stability implications. Indeed this is a most significant inherent, built-in vulnerability unnecessarily exploitative hidden from most and under appreciated to countless others already aware of this mechanism's existence embedded in our devices.

Commentary FYI: Admist a global pandemic as the United States and allied nations in Europe, Australia, and around the world grapple with increasingly more consequential cyber challenges, we individual citizens also struggle against the onslaught of micro-targeted dynamics of the same.

Europe (EC) has thankfully codified measures for individual protections and industry accountability to profit-first configurations on core ubiquitous consumer technologies, the US except California hasn't yet placed national security and its people above its more self-serving political class dynamics.

The issue of what de facto "trust relations" ride along with every purchase of smartphone, computer, TV, and home network and security components should and MUST be elevated highest priority for us all BOTH organizational institutions and citizen. This embedded hidden list -- unknown to most important of Trusted Root Certificate authentication spanning globally a RANGE OF Sovereign Nations and privacy-mining, corporate, comercial interests -- would concern any conscientious. organization or individual person.

Manually determining dependencies of each preloaded de facto "Trusted Authorization" to important services and aupplications for each of our devices has so far been a daunting, evolutionary endeavor.

One new change makes this issue higher priority imo: Chrome 99+ on Android now appears to enforce certificate transparency on all certificates in the system store.

That's relevant because many of us have worked around this issue by rooting all the relevant devices, and installing system certificates instead (since that is easily automated, on rooted devices). Since these are system certificates, they're treated differently to installed user certificates for cert transparency purposes, but this workaround now makes Chrome unusable in these environments.

It would be very helpful to have an official path to automatically install user certificates for debugging & development, so we can stop messing around with the system store to work around this.

נכון מאד וחשוב ביותר

זה חשוב מאד גם בשבילי

#1

Re-comment#64:

Hello, your comments were flagged for review. We understand that you’re frustrated, but please keep your language civil. If you continue to post abusive statements to the Google Issue Tracker, we will be forced to take action by removing your ability to make any comments or changes on the Google Issue Tracker.