Reputation: 116000
Google has a website for all of the AOSP apps here, which includes its launcher, contacts etc...
I'd like to know how to import those apps. More specifically, the launcher and the contacts apps (though I'd also like to know about others too).
Thing is, it's not that simple. You can't just import the cloned project and that's it. Even if you use Eclipse (which seems like the official tool used on those repositories, according to the folders hirerchy ) it doesn't work as easily.
I've found an old post regarding how to import the launcher (version 4.4.x) , but it's using Eclipse and I think require Linux to build some files.
I've tried to import using Eclipse, but for some reason I couldn't get to use a working "protobuf" library. I've tried to use a jar from here, but it didn't succeed importing it.
There is also a nice third party library that has an imported version of the launcher app, but currently it's a bit behind as it's based on Kitkat (4.4) and not Lollipop (5.0) .
How do you import those projects? Is there an easy way? Would it work even on Windows OS and Android Studio ?
Upvotes: 15
Views: 6452
Reputation: 659
For Launcher3, you can visit https://android.googlesource.com/platform/packages/apps/Launcher3/+/android-6.0.1_r9 .
The aosp Launcher3 adds build.gradle
file now, you could just copy the total directory to your work directory, and change gradlew
file mode to let it can execute, and then use ./gradlew clean && ./gradlew build
to build the Launcher3. Also you need close the abortOnError
of lint in build.grale
use
android {
// Other configuration
lintOptions {
abortOnError false
}
}
Note:Don't change protobuf version in build.gradle
, otherwise it may broke the build process.
Upvotes: 0
Reputation: 3465
Here is another approach. AOSP apps are intended to be "native", First you should think, what does this means? This actually means that they are intended to be compiled via the 'mm' command after doing an envsetup and lunch on your main AOSP directory. Also notice that the Android.mk for each app(found at aosp/packages/apps) compiles the file to store them on the /system/app folder on your final image. So yes, this approach makes it difficult to import to AndroidStudio because this type of compilation lacks AndroidStudio's gradle build system, which actually works in an entirely different way.
Other problems you may encounter: - Since Native AOSP app live on /system in Android and are compiled with odex optimization they may give trouble when trying to install any derived work unless you change the module names, and the app name on the AndroidManifest File.
One simple solution: Simply start a new Android Studio project and import relevant java classes and resources from the aosp to your project. I know this sounds like a "lazy" solution but still, y taking this approach you should make sure to name your app differently (different module name) than the AOSP app so it will not conflict with the native aosp app(or any derived app such as GoogleCamera(which extends from AOSP Camera)). Also this will setup the gradle environment required to normally create Android Apps. Hope this helps.
Upvotes: 4
Reputation: 2309
How do you import those projects?
You just clone their git repositories. However the only way to compile them will be together will all the AOSP project.
Trying to compile the app without it is impossible because of an ugly mix of:
1.Dependencies with other projects of AOSP
2.Using hidden API's which are not available to a regular app(these apps were designed to be system apps which have additional API's). These APIS don't even exist in the SDK.
3.Using Android.mk system with hacks that can't be used with Gradle or even the eclipse plugin.
Is there an easy way?
No. For the Launcher its few days of work, for the Contacts its easier to start from scratch.
Would it work even on Windows OS and Android Studio ?
Not without a lot of effort.
There is one more thing, the applications you see in Nexus devices are not a result of compiling the code you download from Google's website. Their apps go through many patch cycles and QA while what you will compile result in a very buggy product which will need heavy maintenance.
My suggestion is to look for truly open source applications, and not count on Google's good will.
Upvotes: 4