View model has no zero arg constructor when using getViewModelStoreOwner [159540434]

Fixed

Bug

Status Update

No update yet.

Description

sp...@gmail.com

created issue #1

Jun 21, 2020 11:04PM

Component used: Fragment
Version used: com.google.dagger:hilt-android:2.28-alpha
Devices/Android versions reproduced on: nexus 5x emulator, android 9.0

If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).

When creating a view model using the navigation scope i get an error stating that ViewModel has no zero argument constructor.

userViewModel = new ViewModelProvider(requireActivity()).get(UserViewModel.class); // works
userViewModel = new ViewModelProvider(getStoreOwner()).get(UserViewModel.class); // crashes

private ViewModelStoreOwner getStoreOwner() {

NavController navController = Navigation
.findNavController(requireActivity(), R.id.root_navigator_fragment);
if (layoutIdentifier.equals(Constants.MAIN_IDENTIFIER)) {

return navController.getViewModelStoreOwner(R.id.root_navigator);

} else {

return navController.getViewModelStoreOwner(R.id.MessageGraph);

}
}

Comments

da...@google.com <da...@google.com> #2Jun 22, 2020 03:45PM

The issue is that Jetifier modifies jars and does not remove signatures. Below is the original class:

Classfile /tmp/non-jetified/org/bouncycastle/jce/provider/ExtCRLException.class
Last modified Mar 1, 2015; size 362 bytes
MD5 checksum 3968a716f9e60e1ad36c34157bd0239f
class org.bouncycastle.jce.provider.ExtCRLException extends java.security.cert.CRLException
minor version: 0
major version: 49
flags: ACC_SUPER
Constant pool:
#1 = Utf8 <init>
#2 = Utf8 cause
#3 = Utf8 getCause
#4 = Utf8 java/security/cert/CRLException
#5 = Utf8 org/bouncycastle/jce/provider/ExtCRLException
#6 = Class #4 // java/security/cert/CRLException
#7 = Class #5 // org/bouncycastle/jce/provider/ExtCRLException
#8 = Utf8 Ljava/lang/Throwable;
#9 = Utf8 (Ljava/lang/String;)V
#10 = Utf8 ()Ljava/lang/Throwable;
#11 = Utf8 (Ljava/lang/String;Ljava/lang/Throwable;)V
#12 = NameAndType #2:#8 // cause:Ljava/lang/Throwable;
#13 = NameAndType #1:#9 // "<init>":(Ljava/lang/String;)V
#14 = Fieldref #7.#12 // org/bouncycastle/jce/provider/ExtCRLException.cause:Ljava/lang/Throwable;
#15 = Methodref #6.#13 // java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
#16 = Utf8 Code
{
java.lang.Throwable cause;
descriptor: Ljava/lang/Throwable;
flags:

org.bouncycastle.jce.provider.ExtCRLException(java.lang.String, java.lang.Throwable);
descriptor: (Ljava/lang/String;Ljava/lang/Throwable;)V
flags:
Code:
stack=2, locals=3, args_size=3
0: aload_0
1: aload_1
2: invokespecial #15 // Method java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
5: aload_0
6: aload_2
7: putfield #14 // Field cause:Ljava/lang/Throwable;
10: return

public java.lang.Throwable getCause();
descriptor: ()Ljava/lang/Throwable;
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: getfield #14 // Field cause:Ljava/lang/Throwable;
4: areturn
}

One processed with Jetifier:

Classfile /tmp/jetified/org/bouncycastle/jce/provider/ExtCRLException.class
Last modified Oct 14, 2019; size 362 bytes
MD5 checksum 76bc557706ee3480e53d88b21316913f
class org.bouncycastle.jce.provider.ExtCRLException extends java.security.cert.CRLException
minor version: 0
major version: 49
flags: ACC_SUPER
Constant pool:
#1 = Utf8 org/bouncycastle/jce/provider/ExtCRLException
#2 = Class #1 // org/bouncycastle/jce/provider/ExtCRLException
#3 = Utf8 java/security/cert/CRLException
#4 = Class #3 // java/security/cert/CRLException
#5 = Utf8 cause
#6 = Utf8 Ljava/lang/Throwable;
#7 = Utf8 <init>
#8 = Utf8 (Ljava/lang/String;Ljava/lang/Throwable;)V
#9 = Utf8 (Ljava/lang/String;)V
#10 = NameAndType #7:#9 // "<init>":(Ljava/lang/String;)V
#11 = Methodref #4.#10 // java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
#12 = NameAndType #5:#6 // cause:Ljava/lang/Throwable;
#13 = Fieldref #2.#12 // org/bouncycastle/jce/provider/ExtCRLException.cause:Ljava/lang/Throwable;
#14 = Utf8 getCause
#15 = Utf8 ()Ljava/lang/Throwable;
#16 = Utf8 Code
{
java.lang.Throwable cause;
descriptor: Ljava/lang/Throwable;
flags:

org.bouncycastle.jce.provider.ExtCRLException(java.lang.String, java.lang.Throwable);
descriptor: (Ljava/lang/String;Ljava/lang/Throwable;)V
flags:
Code:
stack=2, locals=3, args_size=3
0: aload_0
1: aload_1
2: invokespecial #11 // Method java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
5: aload_0
6: aload_2
7: putfield #13 // Field cause:Ljava/lang/Throwable;
10: return

public java.lang.Throwable getCause();
descriptor: ()Ljava/lang/Throwable;
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: getfield #13 // Field cause:Ljava/lang/Throwable;
4: areturn
}

Changes in the constants pool cause changes in the code (indices change), which causes different MD5 checksums. This means that signatures will not match any more.

This started happening in 3.6.0-beta01 because we are using Jetifier with copyUnmodifiedLibsAlso=true flag (previously it was false).

sp...@gmail.com <sp...@gmail.com> #3Jun 23, 2020 12:30PM

@Chris You can work around this by updating gradle.properties with:

android.jetifier.blacklist=.*bcprov.*

This will avoid Jetifying the bouncycastle library.

sp...@gmail.com <sp...@gmail.com> #4Jun 23, 2020 02:05PM

Thanks Ivan!

sp...@gmail.com <sp...@gmail.com> #5Jun 23, 2020 02:07PM

Pending fix in:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1151460

sp...@gmail.com <sp...@gmail.com> #6Jun 23, 2020 02:17PM

did this fix make it in for 3.6?

da...@google.com <da...@google.com> #7Jun 23, 2020 03:17PM

Jetifier 1.0.0-beta08 was released and has a fix for this.

To avoid waiting for new Android Studio you can workaround this in the meantime by forcing usage of a new version of jetifier in gradle:
buildscript {
dependencies {
classpath 'com.android.tools.build:gradle:x.y.z'
classpath 'com.android.tools.build.jetifier:jetifier-processor:1.0.0-beta08' // <- Add this
}
}

sp...@gmail.com <sp...@gmail.com> #8Jun 23, 2020 04:34PM

Jetifier 1.0.0-beta08, which has the fix for this issue, will be integrated into AGP 3.6.0-rc01 and 4.0.0-alpha06:

https://android.googlesource.com/platform/tools/base/+/ef5e56702b626b6be642ecce7d0078b7b1a81bcb

da...@google.com <da...@google.com> #9Jun 24, 2020 05:51PM

Is SentenceFragment annotated with @AndroidEntryPoint? It looks like you have setup injection of it yourself vs letting Hilt inject it.

sp...@gmail.com <sp...@gmail.com> #10Jul 1, 2020 01:11PM

yes its annotated, not sure what you mean how could i do it myself? rather than letting hilt do it? im fairly new to Hilt and dagger2 so its most probably something I'm not doing properly

ap...@google.com <ap...@google.com> #11Aug 11, 2020 03:15PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 00068c24a9e483cc7a8f930e546a67b841c70382
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Mon Aug 10 11:45:49 2020

Apply hilt-android-compiler to AndroidX's Hilt-common

The aggregating compiler has to be applied to the project
where the extension annotations are annotated with
@GeneratesRootInput so the aggregating data is generated
and therefore Hilt can correctly await for these to be
processed.

Relnote: "Fix an issue where AndroidX Hilt extension Modules would not get correctly picked up by Hilt causing ViewModels or Workers to not be available for creation."
Bug: 159540434
Test: Existing tests pass.
Change-Id: I3181c8aad0973d15d82661b48404f2eeeb7ef954

M hilt/hilt-common/build.gradle

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

da...@google.com <da...@google.com> #12Aug 11, 2020 03:20PM

Marked as fixed.

Sorry took a while since it was a bit hard to track. The next alpha version should contain contain a fix for this.