Android Chomecast发件人应用程序:MediaRouteActionProvider

Android Chomecast发件人应用程序:MediaRouteActionProvider,android,google-cast,Android,Google Cast,我对Android的Chromecast sender应用程序有问题。这是我的第二个发件人应用程序,所以,一般来说,我有基本的 什么是正确的: 当我直接从Eclipse运行应用程序时,它可以在我的两个测试设备上运行。 当我直接从Android Studio运行应用程序时,它可以在我的两台测试设备上运行 问题是: 当我通过Eclipse和Android Studio生成一个签名的APK时,应用程序在两台设备上都达到“cast活动”时崩溃 logcat错误如下所示: 07-04 12:39:54.8

我对Android的Chromecast sender应用程序有问题。这是我的第二个发件人应用程序,所以,一般来说,我有基本的

什么是正确的:

当我直接从Eclipse运行应用程序时,它可以在我的两个测试设备上运行。 当我直接从Android Studio运行应用程序时,它可以在我的两台测试设备上运行

问题是:

当我通过Eclipse和Android Studio生成一个签名的APK时,应用程序在两台设备上都达到“cast活动”时崩溃

logcat错误如下所示:

07-04 12:39:54.887: W/SupportMenuInflater(31144): Cannot instantiate class: android.support.v7.app.MediaRouteActionProvider
07-04 12:39:54.887: W/SupportMenuInflater(31144): java.lang.ClassNotFoundException: Didn't find class "android.support.v7.app.MediaRouteActionProvider" on path: DexPathList[[zip file "/data/app/com.victuallist.shred-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.victuallist.shred-1, /vendor/lib, /system/lib]]
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.internal.view.f.a(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.internal.view.f.b(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.internal.view.d.a(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.internal.view.d.inflate(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at com.victuallist.castgame.CastGameActivity.onCreateOptionsMenu(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.app.Activity.onCreatePanelMenu(Activity.java:2538)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v4.app.k.onCreatePanelMenu(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.a.g.a(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.a.n.a(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.a.g.onCreatePanelMenu(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.support.v7.a.o.onCreatePanelMenu(Unknown Source)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at com.android.internal.policy.impl.PhoneWindow.preparePanel(PhoneWindow.java:436)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at com.android.internal.policy.impl.PhoneWindow.doInvalidatePanelMenu(PhoneWindow.java:800)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at com.android.internal.policy.impl.PhoneWindow$1.run(PhoneWindow.java:221)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.view.Choreographer$CallbackRecord.run(Choreographer.java:761)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.view.Choreographer.doCallbacks(Choreographer.java:574)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.view.Choreographer.doFrame(Choreographer.java:543)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:747)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.os.Handler.handleCallback(Handler.java:733)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.os.Handler.dispatchMessage(Handler.java:95)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.os.Looper.loop(Looper.java:136)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at android.app.ActivityThread.main(ActivityThread.java:5001)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at java.lang.reflect.Method.invokeNative(Native Method)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at java.lang.reflect.Method.invoke(Method.java:515)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
07-04 12:39:54.887: W/SupportMenuInflater(31144):   at dalvik.system.NativeStart.main(Native Method)
07-04 12:39:54.897: D/AndroidRuntime(31144): Shutting down VM
07-04 12:39:54.897: W/dalvikvm(31144): threadid=1: thread exiting with uncaught exception (group=0x41611ba8)
07-04 12:39:54.897: E/AndroidRuntime(31144): FATAL EXCEPTION: main

更新:看来我有它的工作。我禁用了proguard。尽管它在运行,我仍然有兴趣知道为什么我会遇到这个问题。任何提示都将不胜感激。谢谢。

ProGuard不会检查菜单资源之类的内容来尝试查找需要避免混淆的类。您从参考资料中引用的任何类都需要保持不变,通常是通过ProGuard配置中的某种
-keep
指令


可能发生的情况是,ProGuard对MediaRouteActionProvider进行了模糊处理,因此您的代码已编译,但Android无法通过其未模糊的名称找到该类。

ProGuard不会检查菜单资源之类的内容,以试图找到需要避免模糊处理的类。您从参考资料中引用的任何类都需要保持不变,通常是通过ProGuard配置中的某种
-keep
指令


可能发生的情况是,ProGuard对MediaRouteActionProvider进行了模糊处理,因此您的代码已编译,但Android无法通过其未模糊的名称找到该类。

在ProGuard文件中添加3行

-keep        class android.support.v13.** { *; }
-keep        class android.support.v7.** { *; }
-keep        class android.support.v4.** { *; }

将解决所有支持库中未找到类的问题。

在proguard文件中添加3行

-keep        class android.support.v13.** { *; }
-keep        class android.support.v7.** { *; }
-keep        class android.support.v4.** { *; }

将解决所有支持库中未找到类的问题。

这些行解决了问题,并允许我保持proguard的活动状态。谢谢对于其他人,请看@commonwareas给出的答案,我理解,
-keep
不仅可以防止类被重命名,还可以防止类在收缩阶段被删除。我建议在较窄的范围内使用
-keep
,或者切换到
-keepnames
作为通配符(如果仍然需要,
-keep
保留
MediaRouteActionProvider
)。请参阅:具体地说,构造函数正在从MediaRouteActionProvider中收缩出来,并通过反射进行调用。这个proguard规则是为了保持构造函数
-keepclassmembers公共类android.support.v7.app.MediaRouteActionProvider{public(…);}
,正如其他人所说,使用如此宽泛的“keep”语句违背了proguard的一个主要目的,即去掉未使用的代码以使应用程序更小更快。此答案将“保留”支持库中的所有类,其中大部分应用程序将不使用。这些行解决了问题,并允许我保持proguard处于活动状态。谢谢对于其他人,请看@commonwareas给出的答案,我理解,
-keep
不仅可以防止类被重命名,还可以防止类在收缩阶段被删除。我建议在较窄的范围内使用
-keep
,或者切换到
-keepnames
作为通配符(如果仍然需要,
-keep
保留
MediaRouteActionProvider
)。请参阅:具体地说,构造函数正在从MediaRouteActionProvider中收缩出来,并通过反射进行调用。这个proguard规则是为了保持构造函数
-keepclassmembers公共类android.support.v7.app.MediaRouteActionProvider{public(…);}
,正如其他人所说,使用如此宽泛的“keep”语句违背了proguard的一个主要目的,即去掉未使用的代码以使应用程序更小更快。此答案将“保留”支持库中的所有类,其中大部分应用程序将不使用。如果我可以接受两个答案为“正确”,我也会选择此答案。谢谢你的解释!当我将项目迁移到AndroidX时,我也遇到了同样的问题。我添加了-keep类androidx.mediarouter.app.MediaRouteActionProvider{public;}-keep类androidx.mediarouter.app.MediaRouteActionProvider{public;}。这就解决了问题。如果我能接受两个“正确”的答案,我也会选择这一个。谢谢你的解释!当我将项目迁移到AndroidX时,我也遇到了同样的问题。我添加了-keep类androidx.mediarouter.app.MediaRouteActionProvider{public;}-keep类androidx.mediarouter.app.MediaRouteActionProvider{public;}。这就解决了问题