IssueTracker

since these are in public API (:/) we need to do this in 1.2

Opening diff shortly

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

commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date:   Tue Aug 11 09:30:34 2020

    [GH] Hide deprecated internal API.
   
    ## Proposed Changes
   
    * `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
   
    ## Testing
   
    Test: Ran unit tests locally
   
    ## Issues Fixed
   
    Fixes: 76109329
   
    This is an imported pull request from https://github.com/androidx/androidx/pull/61.
   
    Resolves #61
    Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
    GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
   
    Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92

A       room/runtime/api/current.ignore
M       room/runtime/api/current.txt
M       room/runtime/api/public_plus_experimental_current.txt
M       room/runtime/api/restricted_current.txt
M       room/runtime/src/main/java/androidx/room/RoomDatabase.java

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

Update:

slightly modified the config I proivided:

## Android architecture components: Lifecycle
# LifecycleObserver's empty constructor is considered to be unused by proguard
-keepclassmembers class * implements android.arch.lifecycle.LifecycleObserver {
    <init>(...);
}
# ViewModel's empty constructor is considered to be unused by proguard
-keepclassmembers class * extends android.arch.lifecycle.ViewModel {
    <init>(...);
}
# keep Lifecycle State and Event enums values
-keepclassmembers class android.arch.lifecycle.Lifecycle$State { *; }
-keepclassmembers class android.arch.lifecycle.Lifecycle$Event { *; }
# keep methods annotated with @OnLifecycleEvent even if they seem to be unused
# (Mostly for LiveData.LifecycleBoundObserver.onStateChange(), but who knows)
-keepclassmembers class * {
    @android.arch.lifecycle.OnLifecycleEvent *;
}


It turns out that generated GenericLifecycleObserver is unreachable after obfuscation because it is created using reflection by adding "_LifecycleAdapter" to LifecycleObserver class name (which is definitely changed). This leads to Lifecycle using fallback ReflectiveGenericLifecycleObserver (a little slower because of looking for your callback methods with reflection in order to call them). So we might just as well lose GenericLifecycleObserver generated by apt.

Another option is to keep both LifecycleObserver and generated GenericLifecycleObserver to improve performance. In that case replace
-keepclassmembers class * implements android.arch.lifecycle.LifecycleObserver {
    <init>(...);
}

with

-keep class * implements android.arch.lifecycle.LifecycleObserver {
    <init>(...);
}

This is still broken for me in alpha 2. I still need to specify ProGuard rules myself.

Looks like I missed part in our .gradle file.

Can you verify which version of architecture components was this fixed in? We are using alpha3, and we still need to provide our own proguard rules because otherwise the lifecycle callbacks get stripped.

alpha-4

I still have an issue with these proguard rules inserted.

java.lang.NoSuchMethodError: No virtual method setRetainInstance(Z)V in class Landroid/arch/lifecycle/HolderFragment; or its super classes (declaration of 'android.arch.lifecycle.HolderFragment' appears in /data/app/package_name/base.apk)

still present in alpha9

Unfortunately still not fixed up until today, not sure why it has been marked as fixed.

still present in alpha 9

With alpha9 I am getting a lot of this when proguarding:

Warning: android.arch.lifecycle.Transformations: can't find referenced class android.arch.core.util.Function

Addendum to comment #15:

Happens when using alpha9 + support 26.1.0 but not with alpha9 + support 26.0.0

Yep you have to use alpha9-1 + support lib 26.1.0, or alpha9 + support 26.0.0
This class was moved in that release.

To others: could you please share what is broken for you?

So with minifyEnabled set to true and with 26.1.0 support library and alpha9-1 android arch, this is the error I still get when I create a release build apk.

java.lang.NoSuchMethodError: No virtual method setRetainInstance(Z)V in class Landroid/arch/lifecycle/HolderFragment; or its super classes (declaration of 'android.arch.lifecycle.HolderFragment' appears in /data/app/package.name/base.apk)

seems like a minify tool issue.

Hello from the tooling side :) Do we have repro steps for this? Can someone attach a full stack trace for this NoSuchMethodError? Is setRetainInstance called reflectively?

minifyEnabled set to true and with 26.1.0 support library and alpha9-1 android arch. After building a release apk, installing it, and launching it, it crashes with the following stacktrace.

Stacktrace:
09-29 13:52:13.205 30730 30730 E AndroidRuntime: java.lang.NoSuchMethodError: No virtual method setRetainInstance(Z)V in class Landroid/arch/lifecycle/HolderFragment; or its super classes (declaration of 'android.arch.lifecycle.HolderFragment' appears in /data/app/package_name==/base.apk)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.arch.lifecycle.HolderFragment.<init>(HolderFragment.java:52)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.arch.lifecycle.HolderFragment$HolderFragmentManager.createHolderFragment(HolderFragment.java:148)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.arch.lifecycle.HolderFragment$HolderFragmentManager.holderFragmentFor(HolderFragment.java:186)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.arch.lifecycle.HolderFragment.holderFragmentFor(HolderFragment.java:89)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.arch.lifecycle.ViewModelStores.of(ViewModelStores.java:53)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.arch.lifecycle.ViewModelProviders.of(ViewModelProviders.java:90)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at com.test.fragments.MyFragment.setUpGui(MyFragment.java:170)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at com.test.fragments.MyFragment.onActivityCreated(MyFragment.java:140)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.Fragment.performActivityCreated(Fragment.java:2363)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1442)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1740)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1809)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.BackStackRecord.executeOps(BackStackRecord.java:799)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.executeOps(FragmentManager.java:2580)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2367)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2322)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2229)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.dispatchStateChange(FragmentManager.java:3221)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentManagerImpl.dispatchActivityCreated(FragmentManager.java:3171)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentController.dispatchActivityCreated(FragmentController.java:192)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v4.app.FragmentActivity.onStart(FragmentActivity.java:560)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.support.v7.app.AppCompatActivity.onStart(AppCompatActivity.java:177)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1333)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.app.Activity.performStart(Activity.java:6992)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2780)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2892)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.app.ActivityThread.-wrap11(Unknown Source:0)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1593)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:105)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:164)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:6541)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
09-29 13:52:13.205 30730 30730 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)

Are you able to reproduce the issue on an example project that you could share with us?

Looking at the stack trace and corresponding source code, there are direct (statically known) calls all the way from ViewModelProviders.of(...) to HolderFragment.setRetainInstance(...) and I was unable to reproduce the problem.

When you open your APK in Studio with "Build -> Analyze APK", how many dex files are there in the APK? Can you see the setRetainInstance method in android.arch.lifecycle.HolderFragment?

I see one dex file. And yes I can see setRetainInstance method in android.arch.lifecycle.HolderFragment

I will try to get an example project with the same bug for you tonight.

These are all the dependencies I've added from the arch lib

   compile "android.arch.lifecycle:runtime:1.0.0-alpha9-1"
    compile "android.arch.lifecycle:extensions:1.0.0-alpha9-1"
    annotationProcessor "android.arch.lifecycle:compiler:1.0.0-alpha9-1"
    compile "android.arch.persistence.room:runtime:1.0.0-alpha9-1"
    annotationProcessor "android.arch.persistence.room:compiler:1.0.0-alpha9-1"

I met the same problem and I am looking forward to being able to fix it.

I have attached a sample project with the bug. The app crashes on start up with the same error.

`java.lang.NoSuchMethodError: No virtual method setRetainInstance(Z)V in class Landroid/arch/lifecycle/HolderFragment; or its super classes (declaration of 'android.arch.lifecycle.HolderFragment' appears in /data/app/com.sample.sample-hQELEWb8KGV9KcOgMhgy3Q==/base.apk)`

It has minify set to true, and the release apk is signed with a keystore with both V1 and V2 checked.

I believe it to be line `viewModel = ViewModelProviders.of(this, viewModelFactory).get(ViewModel.class);` in dashboardfragment.java to be crashing the app.

Can you verify on your end if this is an existing bug or if there is a way we can add a rule in proguard to prevent this from occurring?

This indeed looks like a bug in our custom shrinker. For now please add "useProguard true" to build.gradle to force ProGuard to be used to shrinking (as opposed to our implementation).

OK, to give a bit more context. In 2.x we added our custom implementation of a code shrinker which was disabled by default and considered experimental. It could be enabled by setting `useProguard false` on top of `minifyEnabled true`. We know the DSL is not intuitive, it will be changed in Studio 3.1.

The `useProguard` flag was not documented (see https://google.github.io/android-gradle-dsl/2.3/com.android.build.gradle.internal.dsl.BuildType.html) as this was all considered work in progress. So in this case the fix is just to remove the `useProguard false` line altogether. Obfuscation should be enabled/disabled in the proguard config file as desired.

In 3.0 the bug is fixed and our custom shrinker produces a working APK. It's also the case that in 3.0 the custom shrinker is by default used when building from the IDE for instant run. As before, setting `useProguard true` on top of `minifyEnabled true` will force the ProGuard tool to be used during build, always.

So for now, remove useProguard false and when 3.0 is released, we can add that rule back in?

Most people should have no need to set the `useProguard` flag explicitly. It's `minifyEnabled` that matters, in combination with the proguard-rules.pro configuration file. I suggest you just remove it.

I am getting the following error when I use ROOM library

java.lang.RuntimeException:cannot find implementation for fm.qingting.qtradio.log.j.c. j_c_Impl does not exist.

So now what do I add to proguard rules file or what else should I do?
I get this both with 2.3.3 and 3.0.0 android build plugin.

Room already ships w/ the following proguard rules:

-keep public class * extends android.arch.persistence.room.RoomDatabase
-dontwarn android.arch.persistence.room.paging.**

So, I'm assuming j_c is your RoomDatabase class,which should've never been obfuscated.

I don't believe this to be a ProGuard issue. At least not with the final v1.0 release of Arch Components.
If I build the release APK with minifyEnabled true and shrinkResources true, then observers don't work throughout the app.
If however I add useProguard false, even without *any* ProGuard rules, it works.

We are using the 1.1.1 version for Arch Components. Once we build the release build with minifyEnabled true shrinkResources true, observers don't work throughout the app.
I assume the proguard rules for Arch Components are already included with the library.
We are not able to figure out whats the exact issue. Any help here?

Running room integration tests with minifyEnabled true and useProguard false, all test fail due to no such method errors GithubBrowserSample even fails to compile due to proguard warinings

At this point you should probably remove the `useProguard` line from build.gradle, the old experimental shrinker was replaced by R8 which doesn't need the flag (see https://developer.android.com/studio/preview/features/#R8-enabled for details). If you still see the issue, please file a separate bug.