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

Meta tag parsing cause exception #314

Closed
b22n opened this issue Jan 26, 2015 · 9 comments
Closed

Meta tag parsing cause exception #314

b22n opened this issue Jan 26, 2015 · 9 comments
Assignees
Milestone

Comments

@b22n
Copy link

b22n commented Jan 26, 2015

Glide 3.5.0
com.bumptech.glide.module.ManifestParser
==> GLIDE_MODULE_VALUE.equals(appInfo.metaData.getString(key))

may cause ClassCastException if the manifest has meta-data for other libraries that is not a string value.

@sjudd
Copy link
Collaborator

sjudd commented Jan 26, 2015

The documentation for getString() claims that it will return null if no mapping of the desired type exists:

http://developer.android.com/reference/android/os/BaseBundle.html#getString(java.lang.String)

It's possible that may not be true on different versions of Android, do you have a stack trace?

@b22n
Copy link
Author

b22n commented Jan 27, 2015

It occurs on 5.0.1

Key com.google.android.gms.version expected String but value was a java.lang.Integer.  The default value <null> was returned.
Attempt to cast generated internal exception:
    java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
            at android.os.BaseBundle.getString(BaseBundle.java:921)
            at com.bumptech.glide.module.ManifestParser.parse(ManifestParser.java:29)
            at com.bumptech.glide.Glide.get(Glide.java:151)
            at com.bumptech.glide.RequestManager.<init>(RequestManager.java:64)
            at com.bumptech.glide.RequestManager.<init>(RequestManager.java:56)
            at com.bumptech.glide.manager.RequestManagerRetriever.supportFragmentGet(RequestManagerRetriever.java:184)
            at com.bumptech.glide.manager.RequestManagerRetriever.get(RequestManagerRetriever.java:103)
            at com.bumptech.glide.manager.RequestManagerRetriever.get(RequestManagerRetriever.java:86)
            at com.bumptech.glide.Glide.with(Glide.java:609)

@sjudd
Copy link
Collaborator

sjudd commented Jan 27, 2015

Can you add the metadata tag you're using? Does this cause a crash?

@b22n
Copy link
Author

b22n commented Jan 27, 2015

<meta-data
            android:name="com.google.android.gms.version"
            android:value="@integer/google_play_services_version"/>
<meta-data
            android:name="VERSION"
            android:value="5"/>
<meta-data
            android:name="QUERY_LOG"
            android:value="true"/>

It doesn't crash the app. but exception logs are printed.

@b22n
Copy link
Author

b22n commented Jan 27, 2015

It occurs on 4.3, 4.4.4 and logs only.

@sjudd
Copy link
Collaborator

sjudd commented Jan 27, 2015

Ok, glad it doesn't crash. We could either prefix the key, which would avoid the log but require String parsing or we could probably use get() and instanceof. I guess I'd lean toward the latter since it doesn't involve changing the format.

@Limitin
Copy link

Limitin commented Jan 27, 2015

I am getting this error as well.

In my Manifest:

    <meta-data
        android:name="com.google.android.gms.version"
        android:value="@integer/google_play_services_version" />

The previous version did not have this bug. Is there a fix yet, or would reverting be best for the time being?

@sjudd
Copy link
Collaborator

sjudd commented Jan 27, 2015

I'm inclined to not fix it until the next major release. Doing so will require changing our metadata tag format and this doesn't cause a crash, just some log spam.

If you feel strongly we could do a dot release with a new and legacy format, although that's rather ugly.

@sjudd sjudd added this to the 3.5.1 milestone Jan 28, 2015
@sjudd
Copy link
Collaborator

sjudd commented Jan 28, 2015

If I can find a way to remove this warnings without changing the format of our tag, I'll push that in 3.5.1 since we need to do the dot release anyway for #320.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants