Android Platform Development IDE

1,841 views
Skip to first unread message

Dave Smith

unread,
Dec 3, 2015, 3:42:58 PM12/3/15
to android-platform
What tools do you all use for developing platform/framework code these days? Since there doesn't seem to be a move towards compiling Gradle-style application packages in AOSP, it seems that using Android Studio for build/dev will continue to be a distant thought. Does anyone use pure IntelliJ (I understand the latest Android plugin still attempts to do Gradle builds)?

In the past, I've always done work in a suitable text editor (e.g. Atom) and run the command line build tools—though admittedly the work has never been too intense or complex. Would love to hear what the rest of the platform community (or Googlers) are using to do internals work.

Cheers,
--
Dave Smith, PE
@devunwired

Yury Zhauniarovich

unread,
Dec 4, 2015, 10:51:19 AM12/4/15
to android-platform
Hello Dave,

Actually, you can easily use Intellij Idea or Android Studio for your development (see https://android.googlesource.com/platform/development/+/master/tools/idegen/README how to import the source tree in the ide). However, to build the changes you still have to use command line tools. 

Arne-Christian Blystad

unread,
Dec 4, 2015, 10:51:47 AM12/4/15
to android-platform
I use IntelliJ.

When doing app development I use idegen to generate a IntelliJ project for me. Do the following (assuming Lollipop or newer):

source build/envsetup.sh
lunch ...
make idegen
development/tools/idegen/intellij-gen.sh packages/apps/Settings packages/apps/Settings

and I will be able to open the Settings app in IntelliJ (for example). I setup the SDK manually, and add "base" over "Android SDK" (so I get access to @Hide APIs).

I don't know why I have to specify the project twice, it didn't use to be like that before (Jellybean), but I've grown to accept it.

To build the application, I use the standard "mm" command, together with:

adb install -r $ANDROID_PRODUCT_OUT/system/app/MyApplication/MyApplication.apk

For C/C++ I just use Vim.

Satish Patel

unread,
Dec 4, 2015, 10:51:58 AM12/4/15
to android-...@googlegroups.com
Atom is good.

But still I love local editors vim, emac etc.. And for overall reference android xref site.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.



--
Regards,
satish patel

Dave Smith

unread,
Dec 4, 2015, 12:43:02 PM12/4/15
to android-platform
Thanks for the feedback all -

I'm familiar with idegen (even wrote a blog post on it awhile back). Didn't realize it was part of the daily flow for so many folks, though. It generally takes so much memory to pull the entire tree into the IDE just to work on a few specific modules.

Arne, thanks for the tip on intellij-gen.sh to generate a single-module project. I was only familiar with the global gen script, and I'll have to look into this a bit more.

Cheers,
--
Dave Smith, PE
@devunwired

Dave Smith

unread,
Dec 7, 2015, 1:38:26 PM12/7/15
to android-platform
After playing with this some more, I'm less convinced that idegen is a well-used tool internally…which leaves me wondering what other tools folks use for platform development?

There seem to be some fairly large bugs in idegen that would have been fixed if Google actually used it for project work (perhaps what they use is not available in the open). For starters:
  • All modules are assumed to be app packages, even though the tool explicitly traces packages from LOCAL_JAVA_LIBRARIES and LOCAL_STATIC_JAVA_LIBRARIES. This leads to incorrect generation of generated code paths for ANY library (including some framework libs like libcore) by assuming they ALL live at out/target/common/obj/APPS).
  • The tools also assumes the enclosing directory name is the same as the module name (instead of inspecting LOCAL_MODULE in the Android.mk file), which also creates the wrong <module>_intermediates path name inside out/target/common/obj/.
For top-level source files, this is not a really big deal, but accessing any generated code (AIDL stubs, R files, etc.) outside of the core framework looks completely broken. Do others have tricks that they use to work around this when using idegen, or is there another technique that circumvents the problem?

Cheers,
--
Dave Smith, PE
@devunwired

On Thursday, December 3, 2015 at 1:42:58 PM UTC-7, Dave Smith wrote:
Reply all
Reply to author
Forward
Message has been deleted
0 new messages