Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shrink build fails #4890

Closed
loki666 opened this issue Sep 28, 2018 · 13 comments
Closed

shrink build fails #4890

loki666 opened this issue Sep 28, 2018 · 13 comments
Assignees
Labels

Comments

@loki666
Copy link
Contributor

loki666 commented Sep 28, 2018

Issue description

when shrinking a build (not using proguard), the build fails

Reproduction steps

using exoPlayer 2.9.0

add to build.gradle

    buildTypes {
        debug {
            minifyEnabled true
            useProguard false
        }
    }

Version of ExoPlayer being used

2.9.0

Device(s) and version(s) of Android being used

emulator API 26

A full bug report captured from the device

:app:transformClassesWithAndroidGradleClassShrinkerForDebug
com/google/android/exoplayer2/upstream/DefaultDataSource.getResponseHeaders:()Ljava/util/Map; references unknown class member: com/google/android/exoplayer2/upstream/DataSource.getResponseHeaders:()Ljava/util/Map;
com/google/android/exoplayer2/upstream/cache/CacheDataSource.getResponseHeaders:()Ljava/util/Map; references unknown class member: com/google/android/exoplayer2/upstream/DataSource.getResponseHeaders:()Ljava/util/Map;
@erdemguven erdemguven self-assigned this Oct 1, 2018
@erdemguven
Copy link
Contributor

I can not reproduce the issue on the ExoPlayer demo app. I copied your configuration to demos/main/build.gradle. The app builds and runs fine. If you can reproduce the issue on the demo app please let us know.

@ojw28
Copy link
Contributor

ojw28 commented Oct 1, 2018

It looks like your setup isn't properly handling default methods (e.g. DataSource.getResponseHeaders), which is a Java 8 feature. It might be a good idea to try updating Android Studio, the version of build tools that you're using etc. I suspect doing this will resolve the issue.

If you happen to be including ExoPlayer as source, please also see the RELEASE NOTES for an extra step.

@loki666
Copy link
Contributor Author

loki666 commented Oct 1, 2018

can't reproduce with the demo either...

I'm using an compiled dependancy using latest Android Studio and build tools.

I'll try include ExoPlayer a source dependancy

@ojw28
Copy link
Contributor

ojw28 commented Oct 1, 2018

You really shouldn't need to include it as a source dependency. That's just making things more difficulty. What buildToolsVersion is specified in the gradle file of whatever you're building?

@ojw28
Copy link
Contributor

ojw28 commented Oct 1, 2018

Actually, I think the important thing is probably the com.android.tools.build:gradle dependency you have. Not sure :).

@loki666
Copy link
Contributor Author

loki666 commented Oct 1, 2018

bah my project doesn't like to use ExoPlayer as source
something with annotation package (I've migrated to androidX)

@loki666
Copy link
Contributor Author

loki666 commented Oct 1, 2018

buildToolsVersion: '28.0.3'
classpath "com.android.tools.build:gradle:3.2.0"

adding
-dontwarn com.google.android.exoplayer2.upstream.DataSource
to my proguard-rules.pro fixed it

@ojw28
Copy link
Contributor

ojw28 commented Oct 3, 2018

I think it sounds a like a pro-guard or some other tool issue, in that case? I'm going to close this for now, since it's only a single report. It still seems possible something in your toolchain is out of date. If we get additional reports then we'll look at getting the proguard config to the library, so developers don't need to figure this out for themselves. Thanks for reporting how to fix it!

@ojw28 ojw28 closed this as completed Oct 3, 2018
@cemrich
Copy link

cemrich commented Oct 10, 2018

I have the same issue with the same buildTools and gradle version and an up to date Android Studio installation (3.2).

@loki666 s dontwarn directive fixed the build error, but causes the exo player instance to throw exceptions:

Caused by: com.google.android.exoplayer2.upstream.FileDataSource$FileDataSourceException: java.io.FileNotFoundException: : open failed: ENOENT (No such file or directory)
        at com.google.android.exoplayer2.upstream.FileDataSource.open(FileDataSource.java:73)
        at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:249)
        at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:83)
        at com.google.android.exoplayer2.source.SingleSampleMediaPeriod$SourceLoadable.load(SingleSampleMediaPeriod.java:389)
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:379)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
        at java.lang.Thread.run(Thread.java:761)
     Caused by: java.io.FileNotFoundException: : open failed: ENOENT (No such file or directory)
        at libcore.io.IoBridge.open(IoBridge.java:455)
        at java.io.RandomAccessFile.<init>(RandomAccessFile.java:247)
        at java.io.RandomAccessFile.<init>(RandomAccessFile.java:128)
        at com.google.android.exoplayer2.upstream.FileDataSource.open(FileDataSource.java:65)
        at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:249) 
        at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:83) 
        at com.google.android.exoplayer2.source.SingleSampleMediaPeriod$SourceLoadable.load(SingleSampleMediaPeriod.java:389) 
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:379) 
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607) 
        at java.lang.Thread.run(Thread.java:761) 
     Caused by: android.system.ErrnoException: open failed: ENOENT (No such file or directory)
        at libcore.io.Posix.open(Native Method)
        at libcore.io.BlockGuardOs.open(BlockGuardOs.java:187)
        at libcore.io.IoBridge.open(IoBridge.java:441)
        at java.io.RandomAccessFile.<init>(RandomAccessFile.java:247) 
        at java.io.RandomAccessFile.<init>(RandomAccessFile.java:128) 
        at com.google.android.exoplayer2.upstream.FileDataSource.open(FileDataSource.java:65) 
        at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:249) 
        at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:83) 
        at com.google.android.exoplayer2.source.SingleSampleMediaPeriod$SourceLoadable.load(SingleSampleMediaPeriod.java:389) 
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:379) 
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607) 
        at java.lang.Thread.run(Thread.java:761) 

I am pretty sure the exceptions is caused by the shrinking but I cannot confirm right now, because I've hit the DEX limit. I will report back as soon as I find out more.

@loki666
Copy link
Contributor Author

loki666 commented Oct 10, 2018

I don't have this crash, but I'm not using FileDataSource

@ojw28
Copy link
Contributor

ojw28 commented Oct 10, 2018

It seems more likely that the file uri is incorrect, given the stack trace.

@cemrich
Copy link

cemrich commented Oct 14, 2018

You were right, my issue was related to loading subtitles and had nothing to do with proguard. I am sorry for causing confusion.

In the process of finding this out I made a minimal test app to reproduce the Proguard issue: https://github.com/cemrich/ExoTestApp-4890. You can edit https://github.com/cemrich/ExoTestApp-4890/blob/master/app/proguard-rules.pro and comment out the single line to provoke the error when doing a debug build.

@ojw28
Copy link
Contributor

ojw28 commented Oct 17, 2018

Thanks. I was able to reproduce a problem. It seems shrinking has a problem with default methods being called in implementing subclasses using InterfaceName.super.methodName syntax. We'll fix this one way or another (e.g. by not calling default methods like that, or by adjusting the library proguard file) for the next release.

@ojw28 ojw28 reopened this Oct 17, 2018
@ojw28 ojw28 assigned ojw28 and unassigned erdemguven Oct 17, 2018
@ojw28 ojw28 added the bug label Oct 17, 2018
ojw28 added a commit that referenced this issue Oct 18, 2018
Just not doing it seems simplier and more obviously correct
than suppressing the warnings in our proguard file.

Issue: #4890

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217675527
ojw28 added a commit that referenced this issue Oct 20, 2018
Just not doing it seems simplier and more obviously correct
than suppressing the warnings in our proguard file.

Issue: #4890

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217675527
@ojw28 ojw28 closed this as completed Oct 20, 2018
@google google locked and limited conversation to collaborators May 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants