Androidx SplashScreen compat library: Icon missing [207095799]

Duplicate

of 205021357

Bug

core-splashscreen

Status Update

No update yet.

Description

ma...@tillsimon.com

created issue #1

Nov 19, 2021 05:08PM

I created a fresh project from a Android Studio (2020.3.1 Patch 3) template (Bottom Navigation Activity, minSDK 23, Java, compileSDK+targetSDK 31) and implemented the Androidx SplashScreen compat library as described in the docs (https://developer.android.com/guide/topics/ui/splash-screen/migrate).

So what I did:

Added the dependency:

implementation 'androidx.core:core-splashscreen:1.0.0-alpha02'

Added the necessary splash style:

<style name="Theme.MySplashScreen" parent="Theme.SplashScreen">
        <item name="windowSplashScreenBackground">@color/teal_700</item>
        <item name="postSplashScreenTheme">@style/Theme.MySplashApplication</item>
</style>

Called installSplashScreen from the Activity

@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        SplashScreen splashScreen = SplashScreen.installSplashScreen(this);
        binding = ActivityMainBinding.inflate(getLayoutInflater());
        setContentView(binding.getRoot());

Adjusted the AndroidManifest to include the new splash style for the main activity and also included an intent-filter to react to deeplinks for my domain:

<application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/Theme.MySplashApplication">
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:label="@string/app_name"
            android:theme="@style/Theme.MySplashScreen">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
            <intent-filter>
                <action android:name="android.intent.action.VIEW" />

                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />

                <data android:scheme="http" />
                <data android:scheme="https" />
                <data android:host="www.buildfox.de" />
            </intent-filter>
        </activity>
    </application>

Then I install the app on a default Pixel5 emulator with Android 12 / API 31

What happened:

Normal cold starts work just fine, but when the app is completely closed and I trigger a deeplink to www.buildfox.de, the app starts, but it doesn't show the icon, only the teal_700-colored background.
Same behavior if I go to AppInfo->Force stop and then ->Open again: The logo is missing

(Btw, also no change if I include a custom vector drawable <item name="windowSplashScreenAnimatedIcon">@drawable/my_splash_logo</item>)

Expected behavior:

The splash screen should always display the icon

deleted

Restricted

0 B

Comments

vi...@google.com <vi...@google.com> #2Nov 20, 2021 02:25AM

Assigned to vi...@google.com.

I don't think this falls under pointer input so this is simply less tied to the area I've been focusing on. I think this should be considered open for anyone else to start working on. I think the two main areas of work for keyboard input are building out the equivalent of focusableInTouchMode and routing keyboard input events to the appropriate node/modifier.

Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.

se...@gmail.com <se...@gmail.com> #3Nov 20, 2021 07:40AM

Hey Shep, thanks for the info.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).

Happy to hear from Ryan and Ralston in case this subject was discussed before.

ma...@tillsimon.com <ma...@tillsimon.com> #4Nov 20, 2021 02:03PM

I don't think this is/should be within Semantics's domain. Hardware keyboard input should, as far as I know, follow the same path as (and is, as far as I understand it, indistinguishable from) soft keyboard input (in fact, Gboard actually interacts with hardware keyboards).

I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).

deleted

Restricted

0 B

deleted

Restricted

0 B

deleted

Restricted

0 B

deleted

Restricted

0 B

t6...@gmail.com <t6...@gmail.com> #5Nov 20, 2021 02:10PM

Ah, I based on Siyamed's comment, this bug is intended to track the work necessary to handle keyboard events that aren't related to IME. (like menu shortcuts). I'm not sure what is needed here.

vi...@google.com <vi...@google.com> #6Nov 23, 2021 11:17PM

Reassigned to di...@google.com.

Oh I see. There's probably some overlap there. For instance, the accessibility focus traversal ordering is probably pretty similar to the input focus traversal ordering (though a11y would likely focus things that input would not).

I think one question is probably at what level these things live. There are a bunch of keys that probably don't need to go to substantially all widgets with keyboard input, like volume/menu/search/back. Then there are things like tab, which some input widgets will want, but others should ignore and pass through to another handler (to, say, move input focus).

I think Android's model for this is pretty decent - an intercept pass down the hierachy, then a pass back up for normal handling. It handles both cases well, as each component can decide which keys it cares about, rather than us trying to predict all use-cases in advance. We would, of course, handle these correctly in our controls, and we'd need to make it easy (no internals or copy-pasting of internals) to implement, say, correct tab behavior.

All of which is a long-winded way of saying: "I think we should handle these like any other keyboard input."

ke...@google.com <ke...@google.com> #7Nov 24, 2021 12:37AM

Reassigned to vi...@google.com.

bulk comment, fyi: we have added icebox to all the tickets because it was suggested by blintz in order to prevent auto-close tickets. we want to keep our Compose tickets to remain opened.

see

b/123001228#comment6

vi...@google.com <vi...@google.com> #8Nov 24, 2021 11:38AM

Reassigned to al...@google.com.

Looks like there is currently a ticket assigned to Ralston. Will keep this ticket active for testing as well. Ralston feel free to dup this ticket, or we can use it as a reminder to test.

vi...@google.com <vi...@google.com> #9Nov 24, 2021 11:39AM

Let's keep this ticket open. I can see that it is already marked as blocked by the keyboard Input ticket that I am working on right now.

al...@google.com <al...@google.com> Nov 24, 2021 02:27PM

Reassigned to ca...@google.com.

ab...@gmail.com <ab...@gmail.com> #10Dec 19, 2021 12:32PM

Project: platform/frameworks/support
Branch: androidx-main

commit 072a880c9ab1a245711fe9e67e9a56f2da04b790
Author: Andrey Rudenko <andrei.rudenko@jetbrains.com>
Date: Fri Feb 05 22:43:02 2021

Hardware Keyboard support in TextField

It adds onKeyEvent Modifier to CoreTextField and sets up the handling of KeyEvent in a uniform way across Android and Desktop. This includes support of all main keyboard shortcuts to edit, navigate and select text in TextField.

This CL doesn't touch any of the existing APIs and doesn't introduce the new ones. On Desktop in changes significantly how hardware keyboard events are handled. PlatformInput is responsible only for interaction with IM.

Most of the text operations in this CL were abstracted to TextFieldPreparedSelection and TextPreparedSelection, the latter one can be used in future CL to implement similar keyboard shortcuts for CoreText.

It's incomplete, we have to define better the Compose behavior on Android with a hardware keyboard, possibly it has to react to TouchMode changes and, for example, do not show software keyboard when hardware one is in action

Relnote: N/A
Bug: 139322105
Test: ./gradlew :compose:foundation:foundation:connectedAndroidTest
Change-Id: I2d5d462ec1f57de41ddfd9218411e695fe4bb2e2

M compose/desktop/desktop/samples/src/jvmMain/kotlin/androidx/compose/desktop/examples/example1/Main.jvm.kt
M compose/foundation/foundation/api/1.0.0-beta02.txt
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_1.0.0-beta02.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_1.0.0-beta02.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/build.gradle
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/HardwareKeyboardTest.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/KeyMapping.android.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.android.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/CoreTextField.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyCommand.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyMapping.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/StringHelpers.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/selection/TextPreparedSelection.kt
M compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/DesktopCoreTextField.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/KeyMapping.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.desktop.kt
A compose/foundation/foundation/src/jvmMain/kotlin/androidx/compose/foundation/text/StringHelpers.jvm.kt
M compose/ui/ui-text/src/desktopMain/kotlin/androidx/compose/ui/text/platform/DesktopParagraph.desktop.kt
M compose/ui/ui-text/src/desktopTest/kotlin/androidx/compose/ui/text/DesktopParagraphTest.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/desktop/ComposeLayer.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/input/key/Key.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwner.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwners.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopPlatformInput.desktop.kt

https://android-review.googlesource.com/1578803

Message last modified on Dec 19, 2021 12:32PM

ca...@google.com <ca...@google.com> #11Dec 20, 2021 08:53AM

Andrei, can you please share with us

overall requirements
what is implemented
what is to be implemented
what are we planning in the near team to support those requirements

[Deleted User] <[Deleted User]> #12Dec 22, 2021 08:00PM

Overall requirements

I can formulate some general goals:

it should be as much "native" for the user as possible. The definition of "native" is not very clear, for desktop, for example, it differs from platform to platform, and on Linux is anarchy. On Android keyboard was some sort of a second-class citizen for a long time, as I understand, so I'm not sure how it's "native" at all for most of the users. Should we use the original text field implementation as a reference? Or Chrome one?
full first-class rtl/bidi support
CoreText interaction with the keyboard and especially mouse is very similar to TextField interaction, so I guess they have to share both experience and implementation, where it's possible / needed.
exotic shortcuts like ctrl-t (emacs-like transpose) and kill-"ring" (in quotes because this "ring" is of size 1) ctrl-k/ctrl-y. Most users have no idea of them. But Chrome supports it
undo/redo functionality
uniformed implementation between Android and Compose for Desktop platforms

what is implemented

Adding support of key events was the easy part, thanks to the current state of focus and KeyEvent in compose. A small addition to KeyEvent interface (isTypedEvent) allowed uniform handling between Android and Desktop. Few dozens of basic keyboard commands are implemented and abstracted to the separate internal interface (TextPreparedSelection).

what is to be implemented

rtl/bidi support is broken currently (the separate issue is here https://partnerissuetracker.corp.google.com/u/1/issues/181900696)
better mouse support, at least double / triple clicks (the separate issue is here https://partnerissuetracker.corp.google.com/u/1/issues/180639271)
make CoreText supports the same selection capabilities, including keyboard shortcuts
undo/redo

what are we planning in the near term to support those requirements

Proper support of keyboard and mouse in textfield is essential for desktop experience, so we gonna continue to work on it. Everything described in "general goals" should be implemented before the beta release of CfD. With exception of "exotic shortcuts", maybe :) It would be great to hear thoughts/vision from Google, especially about Android platform.

Before the next steps I want to finish the current iteration, address some of the comments in merged CL, first of all, better test coverage, then RTL/bidi support.

I also going to write undo/redo doc, where we can discuss options that we have.

iv...@gmail.com <iv...@gmail.com> #13Jan 18, 2022 05:29PM

One more thing. Cursor animation should be disabled during cursor navigation. Currently, the cursor is blinking as usual.

eu...@gmail.com <eu...@gmail.com> #14Jan 19, 2022 03:16AM

Project: platform/frameworks/support
Branch: androidx-main

commit 8423691f9f730b9c6da33310183169ed94392101
Author: Andrey Rudenko <andrei.rudenko@jetbrains.com>
Date: Thu Mar 11 11:42:17 2021

Hardware Keyboard vertical navigation improvements and tests

To properly support navigation by lines, the logic should be stateful. It saves the x-position of the cursor when navigation was started and tries to preserve it during vertical navigation

Bug: 139322105
Test: ./gradlew :compose:foundation:foundation:connectedAndroidTest
Change-Id: Ic4daa8159146649dcc8b8982b590b700db7c8a90

A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/text/TextPreparedSelectionTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/HardwareKeyboardTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/selection/TextPreparedSelection.kt

https://android-review.googlesource.com/1628580

ca...@google.com <ca...@google.com> Feb 22, 2022 02:47PM

Status: Duplicate of

205021357

mi...@gmail.com <mi...@gmail.com> #15Aug 13, 2024 10:19AM

Project: platform/frameworks/support
Branch: androidx-main

commit 91ea279ff99d2ade8998596eb34254c472df8baf
Author: Siyamed Sinir <siyamed@google.com>
Date: Mon Mar 29 21:05:25 2021

RecordingInputConnection.sendKeyEvent

Since hardware keyboard on view/composable level
is added, we do not need to handle sendKeyEvent.

Test: Manual test on Pixel 4, Android 11, GBoard
Test: Manual test on Samsung S8, Android 9, Samsung keyboard

Test: ./gradlew compose:ui:ui-text:test
Test: ./gradlew compose:ui:ui-text:connectedAndroidTest
Test: ./gradlew compose:ui:ui:test
Test: ./gradlew compose:ui:ui:connectedAndroidTest

Bug: 184003208
Bug: 139322105
Change-Id: I68c6369a046c8e66b6945afa7679d2166eb9e08a

M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/input/RecordingInputConnectionTest.kt
A compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/text/input/InputEventCallback2.android.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/text/input/RecordingInputConnection.android.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/text/input/TextInputServiceAndroid.android.kt
M compose/ui/ui/src/test/kotlin/androidx/compose/ui/input/RecordingInputConnectionUpdateTextFieldValueTest.kt

https://android-review.googlesource.com/1657169

Issue 207095799

Description

Issue summary

Comments

vi...@google.com <vi...@google.com> #2Nov 20, 2021 02:25AM

se...@gmail.com <se...@gmail.com> #3Nov 20, 2021 07:40AM

ma...@tillsimon.com <ma...@tillsimon.com> #4Nov 20, 2021 02:03PM

t6...@gmail.com <t6...@gmail.com> #5Nov 20, 2021 02:10PM

vi...@google.com <vi...@google.com> #6Nov 23, 2021 11:17PM

ke...@google.com <ke...@google.com> #7Nov 24, 2021 12:37AM

vi...@google.com <vi...@google.com> #8Nov 24, 2021 11:38AM

vi...@google.com <vi...@google.com> #9Nov 24, 2021 11:39AM

al...@google.com <al...@google.com> Nov 24, 2021 02:27PM

ab...@gmail.com <ab...@gmail.com> #10Dec 19, 2021 12:32PM

ca...@google.com <ca...@google.com> #11Dec 20, 2021 08:53AM

[Deleted User] <[Deleted User]> #12Dec 22, 2021 08:00PM

Overall requirements

what is implemented

what is to be implemented

what are we planning in the near term to support those requirements

iv...@gmail.com <iv...@gmail.com> #13Jan 18, 2022 05:29PM

eu...@gmail.com <eu...@gmail.com> #14Jan 19, 2022 03:16AM

ca...@google.com <ca...@google.com> Feb 22, 2022 02:47PM

mi...@gmail.com <mi...@gmail.com> #15Aug 13, 2024 10:19AM

Add comment

Issue metadata