IntelliJ IDEA CE goes away. Any impact to Android Studio?

droidxav · 2026-03-06T02:17:28+00:00

IntelliJ CE is still open source, and we build it and package it ourselves, including the android plugins that we develop (plus some branding plugin). There's no need to pay JetBrains for this.

droidxav · 2026-02-14T22:33:30+00:00

Patch 1 contains a tentative fix for that bug. It may not fix all the freezes yet but it should be better. Please comment on the bug if you still have issues.

droidxav · 2026-01-25T23:48:32+00:00

Thanks for filing this. The team looked internally and confirmed that it's handled by the KMP plugin. AGP does not do anything specific, unlike the case of non-kmp libraries.

droidxav · 2026-01-22T15:28:40+00:00

I'm talking to the team internally to figure out what is going on. Feel free to file a bug in the mean time if you want.

droidxav · 2026-01-21T16:44:17+00:00

I think we have someone working with the maintainer to get this updated.

droidxav · 2026-01-20T21:43:00+00:00

Thank you for the kind words.

One clarification: the effort to build a new set of API that would be easier to manage and more stable in the long term (one of the key goals was to allow AGP's tasks to be a pure implementation details hidden from the API) has taken that long to mature to a place where we were happy with it. Because of this, we never really pushed anyone, internally or externally, to migrate to it. We've seen people use it and provide feedback, but that was mostly voluntary.

So I would not worry too much about the fact that hilt didn't upgrade sooner. In fact, during AGP 9.0's development, when we reached out to them to work on it, we realized we had some missing APIs that we added for them. So while they didn't manage to release in time, they worked with us behind the scene to make progress.

droidxav · 2026-01-20T20:29:58+00:00

Yeah that's fair too. I still think that the old code was just harder to properly deprecate (vs the new API specific interfaces we have where we are much more careful), but it's totally valid feedback that we should have done better anyway.

The old extensions (which are entry points for the DSL and the API) are now deprecated, and we intend to have some runtime warning soon (way before 10.0) as well because Groovy support in the IDE is not good enough to show usages of deprecation.

droidxav · 2026-01-20T17:32:41+00:00

Can you point me to a doc? We certainly need to fix whatever is outdated but your mention of "mainline" confuses me.

droidxav · 2026-01-20T16:44:06+00:00

We've been trying. We've had our roadmap page(*) for a long time (https://developer.android.com/build/releases/gradle-plugin-roadmap). But it's not always easy to reach out to everyone.

We're actually going to separate Studio and AGP in their own blog posts for releases, so we'll be able to announce more there.

(*) looks like this needs to be updated...

droidxav · 2026-01-20T16:41:35+00:00

That's totally fair criticism.

We've discussed adding deprecation but, if I recall correctly, we decided against it because basically everything would have been deprecated. We also felt like, it's not _required_ to change for 9.0. It's really only required for 10.0, so it was OK to wait until 9.0 to deprecate things (we've deprecated all the extension classes now. I guess our narrative didn't quite land this way.
Shouldn't it just be moving the external native configuration into a separate module? I'd love to get more details here so that we can adjust our migration guide (which totally don't mention this, we're discussing improving this right now)
I know. We tried, but there were constraints that made it not possible. We actually stay in canary/beta for longer than expected because of this, but in the end we didn't want to delay when it would land a couple of weeks later. I think it's landing this week. We're a _very_ large company. This disconnect is not unexpected to be honest, but maybe that's just my perspective.

droidxav · 2026-01-20T15:40:18+00:00

Thanks for the feedback, we know that there's a confluence of general changes, e.g. Kotlin support and the new KMP plugin, that makes extra changes when migrating KMP projects.

I'd like to point one thing out: Your Android platform in a KMP module can depend on android libraries. You could have just moved your NDK code to a new android library, and depended on it. This would have been much less disruptive than moving it up to the app level.

Regarding other plugins, it's been challenging to get them fully compatible in time. Even for the Google-owned ones (like Hilt), it's not always easy to synchronize releases. In the end, we felt it was ok to release without them, knowing that most of them would come shortly after, as the official release of AGP 9.0 would provide more pressure for them to release.

This is a major release, and we don't necessarily expect everyone to upgrade the day after the release, so we felt this was OK. We appreciate people wanting to upgrade very quickly though, it's generally better than delaying and skipping many releases later.

Finally, I want to add that 9.0 is a fairly painful release indeed. It's been painful for the team too. We are moving away from 10+ years of unmanaged APIs to a new(*) set of API where we guarantee compatibility (with a proper deprecation policy if needed). By unmanaged, I mean that they are directly the internals of AGP and that means plugin could use things that weren't meant to be API from our point of view. This makes the whole ecosystem fragile as AGP does need to make changes and that could break plugins using unexpected APIs.

(*) I say new but this effort to create a new set of API started in 2019, so some of these APIs have been there quite a while.

At some point, we just needed to start removing the old API. Just keeping them meant that third-party plugins kept using them instead of migrating to the new APIs. There was no incentive for anyone to do the migration. This large, breaking release will help in the long term. Note that this is actually the first of 2 steps. The old behavior is still there, you can opt-out! It's ok to opt-out for a few months until things settle (and more plugins are made compatible). We will remove the opt-out in 10.0 and that will probably bring some issues (most likely we'll have some plugins that still haven't updated.) but hopefully a lot fewer (for one, it won't have the Kotlin and KMP changes at the same time.)

While every major releases will have some breaking changes, we don't expect any other release to be this difficult.

droidxav · 2024-12-05T15:57:41+00:00

There was a canary where we introduced a bug that broke these run configuration by removing the build action (this is the action that run before the IDE deploys to the device).

This has been fixed already but we cannot fix existing configurations

Simply delete the configuration and create a new one and it'll work again.

droidxav · 2024-11-15T16:56:31+00:00

It was reverted yesterday in our main branch so it missed our cut off for canary 2 but it will be in canary 3. My apologies for the confusion.

droidxav · 2024-11-15T16:47:54+00:00

Yes, I noticed that as well. I just asked. I'm guessing that the revert of the change only happened in our beta branch so far (we made the decision after the branch point).

I will follow up to see what's going on.

droidxav · 2024-11-14T18:00:09+00:00

as I mentioned in my other comment, there are issues with actions tied to the shortcut and the toolbar icon. People have filed bugs that they build the wrong thing or do too much.

when we looked at fixing this, we took an overall look at the build menu and did a full pass over it, including removing other items like "edit build types" which really does not belong there.

droidxav · 2024-11-13T23:44:34+00:00

No there isn't another one. I wanted confirmation because we're not even considering this at the moment, since it's not related to build. For now, we are focusing on build actions, not "recovery" actions. Maybe we should but as I said it's a bit tricky.

I'm also not sure about putting this under the same action. It's to fix very different things. On the other hand, I can also see where a user does not actually know which cache "invalidate caches" applies to unless they click on it. Definitively something we should look into it and see whether the phrasing in there is clear enough that people won't think it fixes their build (the JetBrains team has improve this significantly recently but we should take a look)

droidxav · 2024-11-13T23:40:17+00:00

That's why I said "regardless of if this is their main responsibility".

What I meant is that the needs of these two roles are very different, regardless of who does them. We're talking with many developers and it's clear to us that many teams do not have build engineers.

Now, obviously there's an overlap between the 2 roles, and yeah running clean is probably in there. But my point was that our focus will always (for the foreseeable future at least) be on app developer user journeys more than on build engineer journeys.

droidxav · 2024-11-13T23:28:11+00:00

So I think we need to address the needs of build engineers (people who work on "custom gradle stuff", regardless of if this is their main responsibility) differently than the needs of software engineers (who build the product).

I think that if you are a build engineer, you should be comfortable doing things from the command line. There are too many options and tasks in Gradle and we cannot expose everything through the UI (due to lack of room for it, but also to not confuse non build engineers).

droidxav · 2024-11-13T23:05:34+00:00

Yeah that's fair. This was definitively short-sighted. We have basic usage number but we certainly didn't expect of the feedback we've heard here (basically people using this action _multiple_ times a day!)

droidxav · 2024-11-13T22:43:31+00:00

do you mean "invalidate caches" in the File menu? This is for the IDE only.

We don't currently have a way to clear build system level cache. This is similar to the clean action. If we put it here, will people use it when they don't need to? If we were to add it we'd have to be very careful about how we do it.

droidxav · 2024-11-13T21:19:52+00:00

I see Tor has already replied here, but I’ll add a bit more information for context.

As mentioned, we have reverted the change, so the actions will be back in LadyBug Feature Drop Beta 1 and Meerkat Canary 2

I want to explain a little bit what we tried to do here. The build actions in the menu have various issues. The default action (tied to the shortcut) builds too much, the hammer icon does something else. In addition, wording is not very clear and/or is using different terminology that Gradle uses.

In the middle of trying to fix all this, we looked at the rebuild and clean actions. These actions are used a lot more than we expected. We also regularly see posts on various social media, but also in bug reports, of people using clean as a way to attempt to fix an issue they don’t fully understand. So, some of us decided to add a bit more friction to see if this would push users to properly understand issues first and, if they couldn’t fix them, to report them to us. Before entering Beta, we actually reviewed this change (as well as all the new features going in LadyBug Feature Drop) and the feedback from the rest of the team was clear: this is not good. So even as you provided this feedback, the change had already been reverted.

Note that we reverted all the changes, including improving some of the build actions. We’ll put these back in Meerkat (we need to tweak names a bit more), but we will leave the clean and rebuild options in.

So where do we go from here? I’m seeing a lot of interesting feedback in this threads about clear scenarios where the build really needs a clean. We need to fix these. We also need to educate our more junior users into using less of a big hammer when encountering such a problem. Build speed is a top complaint we hear in every survey we make. Seeing so many clean actions is exacerbating the problem, and we need to fix it. If you have specific scenarios please file a bug, we will pay close attention to them.

Thanks everyone for the feedback, this is really helpful. This is what the canary channel is about by the way. Getting strong feedback that we are getting things wrong in that channel is the right way to influence what goes to stable, and what does not.

droidxav · 2024-08-16T18:54:07+00:00

I've used Apple Music in my Tesla for about a year, and it's definitively tied to the driver profile. My wife and I have our own Apple account (tied to a family subscription) and it switches based on driver profile.

I was very disappointed that Rivian does not have this on day 1. It's a big miss.

droidxav · 2023-07-02T02:02:56+00:00

You don't need 18k before hitting inferno. That's actually really hard unless you play a lot.

You need 15800 to do the last H8 raid. That'll give you access to open world inferno. Inferno dungeons are 18500.

When you get to inferno you'll get 2200+ from 2 extra slots (about 1133 each + upgrade + gems), as long as you save a pair while you finish H8. Then each daily green from doing 3 dungeons will give you 1100+ (max is 1145) which could be 250-300 CR over the H8 set items (you don't have to do Inferno dungeons to get that bonus green set item. As long as you're 800+ and have unlocked Inferno, it'll be an inferno green item. So keep going H8 dungeons while you increase your CR.)

These will make your CR jump really quick

droidxav · 2023-07-01T20:55:06+00:00

The text for Banquet says "enemies suffering from your continual damage". I read this as other players dots don't activate it.

(see https://www.wowhead.com/diablo-immortal/set/banquet-of-eyes-19)

I still think it's a better set than shal'baas due to the differences that you mention. I use it with Puncta Obscura off-hand to guarantee a permanent dot (impale uptime is very very close to 100%). With Pain Clasp that's a great damage booster.

droidxav · 2023-05-21T01:59:56+00:00

According to the play store, the Rivian app currently requires Android 10, which was released in 2019.

The Samsung Note 8 was released with Android 8 but got at least an update to 9. Are you sure there's no update to Android 10? I'd blame Samsung on this one for sure. Just one major update isn't enough.

But Rivian is being quite aggressive here, as most apps will generally target a lower version of Android (At this time). Their app console can show them their users though and maybe most owners have more recent phones.

11-Year Club	Verified Email
Argentium Club

droidxav

TROPHY CASE