我想创建一个库，其他开发人员将其纳入自己的应用程序。图书馆将需要布局和支持意图的行动充满活动等。

我知道这是可能的Android图书馆的，但所有这些我所看到的是开源。 （开源在我所看到和修改源$ C ​​$ C）

我想是一个封闭源代码，认为开发商可能只下降到他们的项目，也许添加几行到清单罐子，类型库。 Android中的当前状态是这可能吗？

我想是一个封闭源代码，认为开发商可能只下降到他们的项目，也许添加几行到清单罐子，类型库。 Android中的当前状态是这可能吗？

您可以创建一个Android库项目不能同步分发Java源代码code。刚刚在库项目的库/ 目录中的一个JAR替换的src / 目录。事实上，要准确，你就需要一个空的的src / 目录 - 如果它的缺失，构建工具会胡思乱想

不过，所有的资源（如，布局）都被分配为开源。而你的Java code将无法使用 R.layout.foo 或 R.drawable.bar ，因为code将不会被重新编译为建设主体项目的一部分。相反，你需要使用反射或则getIdentifier（）来查找这些ID在运行时给他们的名字，那就是昂贵的不够，你还需要考虑缓存这些查询。

您的客户必须将库项目添加到他们像其他库项目，该项目将包括添加条目到他们的表现为您发货，他们正在使用的每个活动或其他组件。

然而，存在的这一个方面，你或许没有经过想到一路：

这是支持意图的行动充分活动

在支持的意图行动的一部分是不是一个好主意。用户会发现你住的地方，并会燃烧你的赌注，如果他们的手机获得堆满了10份处理同样的动作相同的活动，因为它们发生在安装使用库的10个应用程序，发生的一切。而且，如果用户没有得到你的开发人员，在90％的时间他们的应用程序中断，因为用户选择的活动副本从其他应用程序。

您船舶上的任何部件的必须被设计成完全使用在应用程序中默认 - IOW，没有＆LT;意向滤光器＆gt; 元素。如果您的客户选择添加＆LT;意向滤光器＆gt; 为自己的目的的元素，那是他们的问题。

I would like to create a library for other developers to incorporate into their apps. The Library will need to have layouts and full activities that support intent actions etc.

I know this is possible with Android Libraries but all of these I have seen are open source. (open source as in I can see and modify the source code)

What I would like is a closed source, think jar, type library that developers could just drop into their projects and maybe add a few lines into manifest. Is this possible in the current state of Android?

What I would like is a closed source, think jar, type library that developers could just drop into their projects and maybe add a few lines into manifest. Is this possible in the current state of Android?

You can create an Android library project that does not distribute Java source code. Just replace the src/ directory with a JAR in the library project's libs/ directory. Actually, to be accurate, you do need an empty src/ directory -- if it's missing, the build tools will get cranky.

However, all of your resources (e.g., layouts) have to be distributed as "open source". And your Java code will not be able to use R.layout.foo or R.drawable.bar, since the code will not be recompiled as part of building the host project. Instead, you will need to use reflection or getIdentifier() to look up these IDs at runtime given their names, and that is expensive enough that you will also need to think about caching those lookups.

Your customer will have to add the library project to theirs like any other library project, which will include adding entries into their manifest for each activity or other component that you are shipping that they are using.

However, there is one aspect of this that you perhaps haven't thought all the way through:

full activities that support intent actions

The "support intent actions" part is not a good idea. Users will find where you live and will burn you at the stake if their phones get cluttered up with 10 copies of the same activity for handling the same action, because they happened to install 10 apps that happen to all use your library. And if the users don't get to you, the developers will, when 90% of the time their apps break because the user chose the copy of the activity from another application.

Any components you ship MUST be designed to be used completely within the application itself by default -- IOW, no <intent-filter> elements. If your customers elect to add <intent-filter> elements for their own purposes, that's their problem.