VerifyError: register v2 has type Conflict but expected Integer [122887884]

Fixed

Bug

Status Update

No update yet.

Description

ga...@google.com

created issue #1

Jan 15, 2019 03:57PM

Updating AGP to 3.3 causes runtime failure for

https://github.com/libon/CleverTapVerifyError with stacktrace:

01-15 16:28:34.556 28244 28244 E AndroidRuntime: FATAL EXCEPTION: main
01-15 16:28:34.556 28244 28244 E AndroidRuntime: Process: com.example.clevertapverifyerror, PID: 28244
01-15 16:28:34.556 28244 28244 E AndroidRuntime: java.lang.VerifyError: Verifier rejected class com.clevertap.android.sdk.InAppFCManager: int[] com.clevertap.android.sdk.InAppFCManager.getInAppCountsFromPersistentStore(java.lang.String) failed to verify: int[]

com.clevertap.android.sdk.In
AppFCManager.getInAppCountsFromPersistentStore(java.lang.String): [0x3B] register v2 has type Conflict but expected Integer (declaration of 'com.clevertap.android.sdk.InAppFCManager' appears in /data/app/com.example.clevertapverifyerror-2/base.apk)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at com.clevertap.android.sdk.CleverTapAPI.<init>(CleverTapAPI.java:225)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at com.clevertap.android.sdk.CleverTapAPI.instanceWithConfig(CleverTapAPI.java:524)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at com.clevertap.android.sdk.CleverTapAPI.getDefaultInstance(CleverTapAPI.java:502)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at com.example.clevertapverifyerror.MainActivity.onCreate(MainActivity.java:16)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.app.Activity.performCreate(Activity.java:6915)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2746)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2864)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.app.ActivityThread.-wrap12(ActivityThread.java)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1567)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:105)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.os.Looper.loop(Looper.java:156)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6523)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:942)
01-15 16:28:34.556 28244 28244 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:832)
01-15 16:28:34.558 1291 3061 W ActivityManager: Force finishing activity com.example.clevertapverifyerror/.MainActivity

Downgrading to 3.2.1 fixes the issue.

Comments

ag...@google.com <ag...@google.com> #2Jan 15, 2019 04:03PM

Reassigned to ze...@google.com.

Too bad a fix for this didn't make it into the May 10 release of 1.1.0. Hopefully soon?

ze...@google.com <ze...@google.com> #3Jan 16, 2019 09:07AM

Same here. I need to do a custom action when pressing back when the modal is open. This is related to https://issuetracker.google.com/issues/271303558, where it was requested to close the dialog when pressing the back button. However, we should be able to override the default BackHandler behaviour of the dialog.

ze...@google.com <ze...@google.com> #4Jan 16, 2019 09:31AM

Accepted by ze...@google.com.

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

commit 90075b00a1b5e5ebd24fb8c03f8a3fc2a7c72e98
Author: Kevin Truong <kevinctruong@google.com>
Date: Wed Oct 04 16:06:44 2023

[BottomSheet] Adding ModalBottomSheetProperties class

Adding a ModalBottomSheetProperties that contains securePolicy, isFocuable, and shouldDismissOnBackPress. securePolicy is taken from the ModalBottomSheet API and placed into this class for neatness.
isFocusable and shouldDismissOnBackPress are parameters that can be used to determine if the modal bottom sheet should receive IME events, and shouldDismissOnBackPress determines if the modal bottom sheet should dismiss when back is pressed on the IME. These parameters are ported from PopupProperties and the implementation is very similar to their usage within Popup.

Bug: 278216859
Test: Updating modalBottomSheet_imePadding test to use the isFocusable parameter, so the text field within the modal bottom sheet can receive focus.
Relnote: adding ModalBottomSheetProperties. Moving securePolicy into ModalBottomSheetProperties. Adding isFocusable and shouldDismissOnBackPress to ModalBottomSheetProperties. These new booleans help determine how modal bottom sheet should handle IME events.
Change-Id: Iea56ff84fd2f8a70037607e8aef0ceaf7a47e3d0

M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ModalBottomSheetTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/ModalBottomSheet.android.kt

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

ap...@google.com <ap...@google.com> #5Jan 16, 2019 11:38AM

Any chance for a release including this fix soon?

da...@clevertap.com <da...@clevertap.com> #6Jan 16, 2019 12:33PM

BackHandler does not work when android:enableOnBackInvokedCallback="true" is set in the app

ag...@google.com <ag...@google.com> #7Jan 16, 2019 01:10PM

There’s already a dedicated issue about the back not working when android:enableOnBackInvokedCallback=“true” is set: https://issuetracker.google.com/issues/281967264

It seems like it’s blocked by a general lack of predictive back support in Compose, though: https://issuetracker.google.com/issues/281967264#comment3

ap...@google.com <ap...@google.com> #8Jan 16, 2019 01:16PM

What are the plans to ship it in a stable release? Is it possible to ship a 1.1.x hotfix that includes this fix? this is blocking multiple flows for us.

ap...@google.com <ap...@google.com> #9Jan 16, 2019 01:48PM

I've tried androidx.compose.material3:material3:1.2.0-beta01 and I believe it's still not working. BackHandler {} is not called inside ModalBottomSheet, the sheet is closing instead.

ze...@google.com <ze...@google.com> #10Jan 16, 2019 02:01PM

Still not working in 1.2.0-beta01
Any ideas on why this is marked as fixed?

da...@clevertap.com <da...@clevertap.com> #11Jan 16, 2019 04:00PM

It's still not working. I also do not understand why it says it's not fixed.

ze...@google.com <ze...@google.com> Jan 18, 2019 08:53AM

Marked as fixed.

ms...@gmail.com <ms...@gmail.com> #12Jan 18, 2019 10:39AM

The fix wasn't to support BackHandler {}. They just added a new properties arg that you can set whether the sheet should be dismissed on back or not:

ModalBottomSheet(
  ...
  properties = ModalBottomSheetDefaults.properties(shouldDismissOnBackPress = /* boolean goes here */),
  ...
)

Since the sheet is in a separate window, I'm afraid this might be the best they can do. That's pretty similar to the API of dialogs, which also have their own window:

Dialog(
  ...
  properties = DialogProperties(dismissOnBackPress = /* boolean goes here */),
  ...
)

But of course the APIs aren't super consistent 😅

ch...@google.com <ch...@google.com> #13Jan 18, 2019 10:42AM

So how should we handle the back press in this case? Okay It won't dismiss the window, any change to handle this?

ms...@gmail.com <ms...@gmail.com> #14Jan 18, 2019 10:44AM

The bug as it's stated in the title and the snippet still exists despite the "fix": it remains impossible to use a BackHandler inside a ModalBottomSheet.

Some thoughts after looking at the code: somehow the ModalBottomSheetWindow needs to implement a OnBackPressedDispatcherOwner and delegate to it when back is pressed (in dispatchKeyEvent), instead of directly calling onDismissRequest like it does today (material3 version 1.2.0). I note that the "ModalBottomSheetWindow" is actually a View, not a Window -- perhaps that's why this is not trivial to fix.

Knowing the code doesn't give me a good idea for a workaround though...