Android appcompat-v7, latest version?

Updated to 2363, downloaded special build you provided and did a rebuild with the new compiler. Seems I’m getting the same result (I’ve confirmed that the build uses the custom compiler):

Hmm, curious, yes, I can reproduce it’s own fully fixed.

it seems there’s two problems, one is picking there proper latest version based whats in the cache (thats fixed now), but even with a manually cleared cache, I’m getting 25.3.1 now (where i had 28 before). So there seems to be a problem with the remote lookup too. investigating…

Oh actually, the makes sense

Package com.android.support:appcompat-v7 found in repository <MavenRepository file:///Users/mh/Library/Android/sdk/extras/android/m2repository/>
D: Available Versions of ‘com.android.support:appcompat-v7’: 26.0.0-alpha1, 25.3.1, 25.3.0, 25.2.0, 25.1.1, 25.1.0, 25.0.1, 25.0.0, 24.2.1, 24.2.0, 24.1.1, 24.1.0, 24.0.0-beta1, 24.0.0-alpha2, 24.0.0-alpha1, 24.0.0, 23.4.0, 23.3.0, 23.2.1, 23.2.0, 23.1.1, 23.1.0, 23.0.1, 23.0.0, 22.2.1, 22.2.0, 22.1.1, 22.1.0, 22.0.0, 21.0.3, 21.0.2, 21.0.0, 20.0.0, 19.1.0, 19.0.1, 19.0.0, 18.0.0.
D:

this is the ones he finds locally, so it never goes beyond that to look on the server. kind consider this as designed, though, if I only have 25 (and 26 alpha) installed, it should not reach out to the server to get newer ones. Agreed?

I’ll try updating my local install now…

Hmm. I have 28 installed, but still ~/Library/Android/sdk/extras/android/m2repository only has 25.3.1 as the latest non-beta. Do you have the same?

If so, I’d consider this a broken ADK install, really and not an EBuild bug, as EBuild is doing “the right thing”. I’m not sure now to best fix this. Does Google no longer support/update the local folders? is this supposed to always go to the remote repositories now, for all packages?

I was just digging through my folders and saw the same thing. Files in sdk/extras/android/m2repository/…/appcompat-v7 haven’t been updated since November 2017. I’m thinking these are leftovers and Android Studio and Gradle manage those differently now. Trying to figure this out too…

If I disable the local repos, it works, except this one the does ntio resolve at all

E:                   Gradle package com.android.support.constraint:constraint-layout Version * not found in any repositories.

Since thats the only package that seems to be inside the root Android/sdk/extras/m2repository/ folder (opposed to subfolders of extra), I suppose one solution is to keep using THAT root repo for now, but disable the other ones? what do you think?

Can you see from build logs where Android Studio/Gradle gets that constraint-layout package from?

No such luck,

it then fails on

E:                   Gradle package com.android.support:cardview-v7 Version * not found in any repositories.

too :(.

Hmm, nevernind. it looks like these all are in maven.google.com — it’s just that (at least for me) 90% of the requests to that repro fail or time out :(.

Ok. I’ve disabled the local repos now and (my network issues, which I’m not sure are mine, or maybe a Mono bug), all resolves fine. So that is the proper solution. I’ll commit and send you a new build; will be curious too see if that works for you well, or if you too see network probs.

1 Like

Great. I’ll try this out after lunch.

Cheers!

1 Like

New build is up, btw.

1 Like

Version lookup seems better now but I’m getting those HTTP failures as well (along with a straight up error with cardview-v7):

Ok, “good”, at least that’s consistent. Could be a Mono bug or an Elements RTL HTTP bug; unfortunately I cannot reproduce it in a simple test case that loads the same URLs :(. I’ll investigate.

(The HTTP Error 0 ones are the bugs; the 404 are legit, those packages simply don’t exist ion those repos),

Workaround for now: delete your cache start Fire and load your project, and let Fire finish resolving the references (check the References node in the tree). That uses the native Cocoa version of EBuild that’s linked into the IDE, which (for me) does not exhibit this bug; once Fire is done resolving, all the packages will be in the cache, so when you build, the Mono-based version of EBuild that runs the compiler will pick them up from there.

I’ll see what I can do re the HTTP error over the next few days :frowning:

Fixed; I’ll send you a new build later today.

1 Like

Up.

Yes (and thank you for cleaning up those old downloads too!). Just tested it and the lookups seem to work now (and grab the correct version of the dependencies).

You can mark this as fixed. Thanks!

[I assume Fire will display the proper versions in the project pane in the next version?]

Cool!

Yes, Fire uses its own native-Cocoa copy of the same EBuild resolving code, to resolve references for CC & IDE smarts, so it will not pick p the fixes from the newer external compiler and only get them when I do a full new build of Fire. I can send you one in a bit, as I just installed the new build myself…

1 Like

Going up now, eta 5 mins.

Downloaded and installed. Project pane displays the versions properly now.

Cheers.

1 Like

Excellent!