[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1
Chirayu Desai
chirayudesai1 at gmail.com
Tue Jul 19 10:40:23 UTC 2016
Hi,
On Tue, Jul 19, 2016 at 2:41 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
> Hi everyone,
>
> Sorry for the late reply, I am finally able to use a Debian laptop...
>
> So, we now have 2 options for the road beyond:
>
> 1. Integrate 3 other repos into src:android-platform-frameworks-base
We already build things from the above, so it would be good. Name
would be confusing though.
> 2. New src:android-platform-23 or src:android-platform-framework-23
> for a combination of 4 repos
This would be less confusing, and I guess we'll also move things like
aapt and framework-res to the new repo.
>
> If we do not need to care about disk spaces for Debian's servers,
> option #2 is also preferred by me. Because if we are making a new
> source package for option #2, this package will have duplicated codes
> in src:android-platform-libcore and
> src:android-platform-framework-base. What should we do to this 2
> existing packages? We have several options:
>
> A) Remove src:android-platform-libcore as all of its binary packages
> can also be built in src:android-platform-framework-23
+1
> B) Remove those large-sized resource files, which are used to build
> frameworks-res.apk, from src:android-platform-frameworks-base. This
> source package used to exclude all those resource files in order to
> keep fit.
They aren't that large.
cdesai at sid: ~/android-tools/android-platform-frameworks-base
((e9bbe9a9d6...)) $ du -sh core/res/
56M core/res/
> C) Remain the 2 existing packages as is and only include necessary
> file in src:android-platform-framework-23
That'll lead to some duplication, but also make the existing
frameworks-base smaller.
>
> In option #C, packages like libandroid-json-java and
> android-framework-res are still built from where they are now. I am
> not sure but if the upstream "framework-res.apk" only contains
> resource files but not any Java classes, option #C seems nice.
It does not contain any java classes at all.
core/res is what is included in it, nothing more.
That's why we're able to build it with a one liner with aapt.
>
> Cheers,
> Kai-Chung Yan
There's one more concern here. This is just for 23. What about the
older releases? Many are still quite popular. And the newer release
(7.0), which'll come sometime around August/September, will also need
quite some work - and a lot of repos too, if we make
src:android-platform-<n>.
>
> 2016-07-02 13:08 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>> Hi,
>>
>> On Thu, Jun 30, 2016 at 4:48 PM 殷啟聰 <seamlikok at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Including libcore, frameworks/opt/telephony & frameworks/opt/net/voip into
>>> src:android-platform-frameworks-base does make sense because:
>>>
>>> * This 3 repos are necessary to build the "android.jar", so it makes sense
>>> to
>>> put them together.
>>
>> Agreed. It would be best to have those 3 upstream repos in one debian source
>> package.
>>>
>>>
>>>
>>> * "android.jar" is the core of an "Android Platforms", hence it makes
>>> sense to remain the package name as "android-platform-frameworks-base".
>>
>> Still don't agree with this, as this source package already exists and name
>> android-platform-foo is used for upstream repo platform/foo. Minor nit in
>> the grand scheme of this though.
>>>
>>>
>>> Using "sources.zip" may not be a good idea because:
>>>
>>> * "sources.zip" and "platforms.zip" are non-free just like the official
>>> SDK
>>> bundle.
>>
>> I think the idea here was to create our very own sources.zip (I think that's
>> what I remember from the chat with hc on IRC a few days ago)
>>>
>>> * "sources.zip" still lacks some classes in "android.jar". (For example
>>> the
>>> classes in "junit/" directory
>>
>> Are those classes included included under a folder with their package name
>> perhaps?
>> I remember getting confused by that for some other class.
>>>
>>>
>>> Although the Java sources inside the "sources.zip" is open source, the
>>> tarball
>>> itself is not. I do not know if that violates Debian's policy. If we are
>>> creating source packages depending on this tarball, the package might
>>> remain in
>>> "non-free" category.
>>>
>>> As we all have observed the structure of the "platforms/" directory, we
>>> know
>>> that the "Android Platforms" consists of plenty of files originate from
>>> various
>>> upstream repos, which makes it very complicated to reproduce the entire
>>> "Android
>>> Platforms" from source. How about we make a source package
>>> src:google-android-platforms-installer consists of downloader packages of
>>> all
>>> "Android Platforms" directly from Google?
>>
>> I agree with this, trying to build the android platforms would not be a good
>> idea.
>> What we could do is have the open source installer / manager (android
>> command) and then perhaps have those downloader packages containing the
>> upstream repository info (i.e. just the xml)
>> Also, since those platforms wouldn't be oss they would probably go to
>> non-free. I'm not exactly sure about this.
>> However, I remember seeing an alternative (hc linked it a few days ago),
>> somebody had recompiled all the platforms from the aosp sources - we could
>> create a repository xml from that and put it in contrib.
>>
>> hc another email about this with some ideas.
>>>
>>> Cheers,
>>> Kai-Chung Yan
>>>
>>> 2016-06-17 14:47 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>>> > We could run doclava on those files, which is what would have to be
>>> > done anyways.
>>> > So,
>>> > frameworks/base = full sources.
>>> > sources.zip = full public API sources, no hidden methods or classes
>>> > android.jar = stubs compiled using doclava from either of the above,
>>> > doclava is what produces the file list for sources.zip in the first
>>> > place.
>>> >
>>> > sources.zip and android.jar should have matching classes (apart from
>>> > maybe uiautomator, not sure) - the content of each class would differ
>>> > (stubs vs code), but there wouldn't be any class which is in
>>> > android.jar and not in sources.zip
>>> >
>>> > On Fri, Jun 17, 2016 at 12:41 AM, Hans-Christoph Steiner <hans at at.or.at>
>>> > wrote:
>>> >>
>>> >> I think I just found the fatal flaw in the sources-23-r01.zip approach:
>>> >> sources-23-r01.zip contains the full .java source files, file
>>> >> android.jar includes only the stub versions. Is there a tool that we
>>> >> can easily convert those sources to the stubbed versions? If not, then
>>> >> we should go with the plan that seamlik outlined.
>>> >>
>>> >> .hc
>>> >>
>>> >> Hans-Christoph Steiner:
>>> >>>
>>> >>> Chirayu and I are probing around this approach. I think it makes
>>> >>> sense
>>> >>> to make a custom source tarball for the platforms based on
>>> >>> sources-23_r01.zip, platform-23_r03.zip, then the remaining bits from
>>> >>> android-platform-frameworks-base.
>>> >>>
>>> >>> Then we can keep the current android-platform-frameworks-base as it
>>> >>> is.
>>> >>> For things that might need security updates like aapt, etc., they
>>> >>> should use the one-package-per-git-repo model so its easy to do
>>> >>> security
>>> >>> updates. The android-platform-23 package does not really have
>>> >>> executable code, instead just API files for cross-compiling.
>>> >>>
>>> >>> .hc
>>> >>>
>>> >>> Hans-Christoph Steiner:
>>> >>>>
>>> >>>> Is this only about building the 'platform' and android.jar? How
>>> >>>> about
>>> >>>> making a custom source package from the two upstream tarballs:
>>> >>>>
>>> >>>> https://dl.google.com/android/repository/platform-23_r03.zip
>>> >>>> https://dl.google.com/android/repository/sources-23_r01.zip
>>> >>>>
>>> >>>> We could make a little script that downloads those two and repacks
>>> >>>> into
>>> >>>> a DFSG-free tarball with just .java and res XML. Would that cover
>>> >>>> everything needed?
>>> >>>>
>>> >>>> .hc
>>> >>>>
>>> >>>> 殷啟聰:
>>> >>>>> Hi Chirayu,
>>> >>>>>
>>> >>>>> IMO it is fine to reuse this existing
>>> >>>>> src:android-platform-frameworks-base. And we will probably need to
>>> >>>>> file an removal of src:android-platform-libcore since everything is
>>> >>>>> built from src:android-platform-frameworks-base.
>>> >>>>>
>>> >>>>> It is indeed highly likely that we will need to prepare another
>>> >>>>> merged
>>> >>>>> source package when we are doing NDK, but I think it is fine to
>>> >>>>> avoid
>>> >>>>> the merging as long as every single artifacts (e.g. .so, .jar) can
>>> >>>>> be
>>> >>>>> built from an independent repo of AOSP.
>>> >>>>>
>>> >>>>> Cheers,
>>> >>>>> Kai-Chung Yan
>>> >>>>>
>>> >>>>> Cheers,
>>> >>>>> Kai-Chung Yan
>>> >>>>>
>>> >>>>> 2016-06-15 17:37 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
>>> >>>>>> Hi,
>>> >>>>>>
>>> >>>>>> I get what you mean, which is why I suggested the src:android
>>> >>>>>> package.
>>> >>>>>> The name can be something else, but I would say it could be
>>> >>>>>> something
>>> >>>>>> other than android-platform-frameworks-base too because that would
>>> >>>>>> be
>>> >>>>>> confusing as well.
>>> >>>>>>
>>> >>>>>> So src:name-of-new-package-for-android-jar
>>> >>>>>> tree:
>>> >>>>>> frameworks
>>> >>>>>> base
>>> >>>>>> opt
>>> >>>>>> net
>>> >>>>>> voip
>>> >>>>>> telephony
>>> >>>>>> libcore
>>> >>>>>> debian
>>> >>>>>>
>>> >>>>>> which would be used to build the android.jar, having all the
>>> >>>>>> android
>>> >>>>>> sources needed in one debian source package would make it easier.
>>> >>>>>> Question is, what about the existing frameworks-base package, and
>>> >>>>>> the
>>> >>>>>> other packages it builds (aapt, etc)
>>> >>>>>> Also, it might be worth to think if we would need to do this kind
>>> >>>>>> of
>>> >>>>>> thing again in the future, for something else like the NDK or
>>> >>>>>> emulator
>>> >>>>>> images (just some random examples, as the emulator images would
>>> >>>>>> need a
>>> >>>>>> full android build which would be really complex)
>>> >>>>>>
>>> >>>>>> Cheers,
>>> >>>>>> Chirayu Desai
>>> >>>>>>
>>> >>>>>> On Wed, Jun 15, 2016 at 3:01 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
>>> >>>>>>> Hi Chirayu,
>>> >>>>>>>
>>> >>>>>>> We can refer to the way how src:android-platform-system generate
>>> >>>>>>> the
>>> >>>>>>> merged upstream tarball. And I don't think we need git submodule
>>> >>>>>>> or
>>> >>>>>>> repo, because Git is only used to manage the history of our
>>> >>>>>>> debian/
>>> >>>>>>> files, not the upstream files. We don't really need so much
>>> >>>>>>> complicated mechanism...
>>> >>>>>>>
>>> >>>>>>> Cheers,
>>> >>>>>>> Kai-Chung Yan
>>> >>>>>>>
>>> >>>>>>> 2016-06-15 17:22 GMT+08:00 Chirayu Desai
>>> >>>>>>> <chirayudesai1 at gmail.com>:
>>> >>>>>>>> Hi,
>>> >>>>>>>>
>>> >>>>>>>> On Wed, Jun 15, 2016 at 2:43 PM, 殷啟聰 <seamlikok at gmail.com> wrote:
>>> >>>>>>>>> Hi,
>>> >>>>>>>>>
>>> >>>>>>>>> The name of "src:android" is too general. Since this repo
>>> >>>>>>>>> contains
>>> >>>>>>>>> mostly files of android-platform-frameworks-base, we can simply
>>> >>>>>>>>> reuse
>>> >>>>>>>>> this source package. Actually there was an
>>> >>>>>>>>> src:sndroid-platform-system
>>> >>>>>>>>> [1] which consisted of android-platform-system-core and
>>> >>>>>>>>> android-platform-system-extras, but we later use staged builds
>>> >>>>>>>>> to
>>> >>>>>>>>> resolve the circular dependency between them and we split them
>>> >>>>>>>>> up.
>>> >>>>>>>>> src:android-platform-frameworks-compile [2] is also a
>>> >>>>>>>>> combination of
>>> >>>>>>>>> multiple upstream sources, but I am also thinking about
>>> >>>>>>>>> splitting them
>>> >>>>>>>>> up.
>>> >>>>>>>> Yes, I agree "src:android" is too general. However I suggested
>>> >>>>>>>> that
>>> >>>>>>>> because you said you wanted to maintain the upstream structure,
>>> >>>>>>>> and I
>>> >>>>>>>> would think that it would make sense.
>>> >>>>>>>>
>>> >>>>>>>> Or did you mean something else?
>>> >>>>>>>>
>>> >>>>>>>> It seems that if there was a way to properly replicate the
>>> >>>>>>>> upstream
>>> >>>>>>>> structure properly, i.e. one git repo per upstream repo, one
>>> >>>>>>>> source
>>> >>>>>>>> tarball, etc., and then do something combining all of those, it
>>> >>>>>>>> might
>>> >>>>>>>> be best. If possible, of course.
>>> >>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> Cheers,
>>> >>>>>>>>> Kai-Chung Yan
>>> >>>>>>>>>
>>> >>>>>>>>> [1]:
>>> >>>>>>>>> https://anonscm.debian.org/cgit/android-tools/android-platform-system.git
>>> >>>>>>>>> [2]:
>>> >>>>>>>>> https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-compile.git
>>> >>>>>>>>>
>>> >>>>>>>>> 2016-06-14 22:24 GMT+08:00 Chirayu Desai
>>> >>>>>>>>> <chirayudesai1 at gmail.com>:
>>> >>>>>>>>>> Hi,
>>> >>>>>>>>>>
>>> >>>>>>>>>> On Tue, Jun 14, 2016 at 6:54 PM, 殷啟聰 <seamlikok at gmail.com>
>>> >>>>>>>>>> wrote:
>>> >>>>>>>>>>> Hi Markus and Hans,
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> The reason of providing Java source files in
>>> >>>>>>>>>>> android-platform-libcore
>>> >>>>>>>>>>> is because we use Doclava to analyze all Java source of the
>>> >>>>>>>>>>> Android
>>> >>>>>>>>>>> platform framework and generate some API stubs which are Java
>>> >>>>>>>>>>> sources
>>> >>>>>>>>>>> having only the definitions but not the implementations, much
>>> >>>>>>>>>>> like a
>>> >>>>>>>>>>> header file in C/C++. And "android.jar" is built using these
>>> >>>>>>>>>>> API
>>> >>>>>>>>>>> stubs. All compiled classes are bundled into a single
>>> >>>>>>>>>>> "android.jar",
>>> >>>>>>>>>>> so we are not building any separated Java libraries.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I successfully built "android.jar" in the android-jar-old
>>> >>>>>>>>>>> branch [1]
>>> >>>>>>>>>>> and after I compare this "android.jar" to the upstream one I
>>> >>>>>>>>>>> found
>>> >>>>>>>>>>> that it is not enough. We need 2 more repos:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> *
>>> >>>>>>>>>>> https://android.googlesource.com/platform/frameworks/opt/telephony
>>> >>>>>>>>>>> *
>>> >>>>>>>>>>> https://android.googlesource.com/platform/frameworks/opt/net/voip
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I find it unacceptable if we are also building another 2
>>> >>>>>>>>>>> binary
>>> >>>>>>>>>>> packages containing Java source files and with version string
>>> >>>>>>>>>>> in the
>>> >>>>>>>>>>> package names. So it would be better if we combine
>>> >>>>>>>>>>> android-platform-libcore and this 2 repos into one single
>>> >>>>>>>>>>> src:android-platform-frameworks-base.
>>> >>>>>>>>>> Or it could be a new single src:android, preserving the
>>> >>>>>>>>>> upstream
>>> >>>>>>>>>> directory structure.
>>> >>>>>>>>>> i.e.
>>> >>>>>>>>>> android
>>> >>>>>>>>>> frameworks
>>> >>>>>>>>>> base
>>> >>>>>>>>>> opt
>>> >>>>>>>>>> net
>>> >>>>>>>>>> voip
>>> >>>>>>>>>> telephony
>>> >>>>>>>>>> libcore
>>> >>>>>>>>>>
>>> >>>>>>>>>> and so on.
>>> >>>>>>>>>>
>>> >>>>>>>>>> However, it might get too big.
>>> >>>>>>>>>> Also, existing packages, mainly from
>>> >>>>>>>>>> src:android-platform-frameworks-base would have to be migrated.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Is there any other saner way?
>>> >>>>>>>>>> Could we perhaps use git submodules (or upstream's 'repo' tool)
>>> >>>>>>>>>> in some way?
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I don't know if there are any conventional or simple way of
>>> >>>>>>>>>>> making a
>>> >>>>>>>>>>> source package tarball from multiple upstream tarball. I only
>>> >>>>>>>>>>> know
>>> >>>>>>>>>>> that the latest uscan (version 4 watch file) supports creating
>>> >>>>>>>>>>> tarballs from multiple upstream tarballs, but I don't know if
>>> >>>>>>>>>>> mk-origtargz supports it or there are other ways.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Cheers,
>>> >>>>>>>>>>> Kai-Chung Yan
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> [1]:
>>> >>>>>>>>>>> https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-base.git/?h=android-jar-old
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> 2016-06-10 18:53 GMT+08:00 Markus Koschany <apo at debian.org>:
>>> >>>>>>>>>>>> On 08.06.2016 20:43, Hans-Christoph Steiner wrote:
>>> >>>>>>>>>>>> [...]
>>> >>>>>>>>>>>>> About android-platform-libcore-source-6.0.1, seems like
>>> >>>>>>>>>>>>> we'll have to
>>> >>>>>>>>>>>>> combine multiple upstream git repos into a single debian
>>> >>>>>>>>>>>>> source package
>>> >>>>>>>>>>>>> if android.jar needs to be built from multiple git repos at
>>> >>>>>>>>>>>>> the same
>>> >>>>>>>>>>>>> time. I think a source package can have multiple source
>>> >>>>>>>>>>>>> tarballs, so
>>> >>>>>>>>>>>>> the source tarballs could still be directly tied to the git
>>> >>>>>>>>>>>>> repos.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Sure, you can combine multiple upstream repos into one Debian
>>> >>>>>>>>>>>> repo as
>>> >>>>>>>>>>>> well. It is just a matter of documentation.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>> Another approach that's a bit hacky is packaging the bits of
>>> >>>>>>>>>>>>> android.jar
>>> >>>>>>>>>>>>> separately from each git repo, then make a post-install
>>> >>>>>>>>>>>>> script that
>>> >>>>>>>>>>>>> compiles android.jar from them. Markus might kill me for
>>> >>>>>>>>>>>>> making that
>>> >>>>>>>>>>>>> suggestion ;)
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> I guess I need to see the whole packaging for android.jar
>>> >>>>>>>>>>>> first before I
>>> >>>>>>>>>>>> ask Igor to do something terrible. ;)
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>>> Android-tools-devel mailing list
>>> >>>>>>>>>>>> Android-tools-devel at lists.alioth.debian.org
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> --
>>> >>>>>>>>>>> /*
>>> >>>>>>>>>>> * 殷啟聰 | Kai-Chung Yan
>>> >>>>>>>>>>> * 一生只向真理與妻子低頭
>>> >>>>>>>>>>> * Undergraduate student in National Taichung University of
>>> >>>>>>>>>>> Education
>>> >>>>>>>>>>> * LinkedIn: <https://linkedin.com/in/seamlik>
>>> >>>>>>>>>>> * Blog: <http://seamlik.logdown.com>
>>> >>>>>>>>>>> */
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>> Android-tools-devel mailing list
>>> >>>>>>>>>>> Android-tools-devel at lists.alioth.debian.org
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> --
>>> >>>>>>>>> /*
>>> >>>>>>>>> * 殷啟聰 | Kai-Chung Yan
>>> >>>>>>>>> * 一生只向真理與妻子低頭
>>> >>>>>>>>> * Undergraduate student in National Taichung University of
>>> >>>>>>>>> Education
>>> >>>>>>>>> * LinkedIn: <https://linkedin.com/in/seamlik>
>>> >>>>>>>>> * Blog: <http://seamlik.logdown.com>
>>> >>>>>>>>> */
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> /*
>>> >>>>>>> * 殷啟聰 | Kai-Chung Yan
>>> >>>>>>> * 一生只向真理與妻子低頭
>>> >>>>>>> * Undergraduate student in National Taichung University of
>>> >>>>>>> Education
>>> >>>>>>> * LinkedIn: <https://linkedin.com/in/seamlik>
>>> >>>>>>> * Blog: <http://seamlik.logdown.com>
>>> >>>>>>> */
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>
>>> >> _______________________________________________
>>> >> Android-tools-devel mailing list
>>> >> Android-tools-devel at lists.alioth.debian.org
>>> >>
>>> >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>>> >
>>> > _______________________________________________
>>> > Android-tools-devel mailing list
>>> > Android-tools-devel at lists.alioth.debian.org
>>> >
>>> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>>>
>>>
>>>
>>> --
>>> /*
>>> * 殷啟聰 | Kai-Chung Yan
>>> * 一生只向真理與妻子低頭
>>> * Undergraduate student in National Taichung University of Education
>>> * LinkedIn: <https://linkedin.com/in/seamlik>
>>> * Blog: <http://seamlik.logdown.com>
>>> */
>>>
>>> _______________________________________________
>>> Android-tools-devel mailing list
>>> Android-tools-devel at lists.alioth.debian.org
>>>
>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>>
>>
>> _______________________________________________
>> Android-tools-devel mailing list
>> Android-tools-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>
>
>
> --
> /*
> * 殷啟聰 | Kai-Chung Yan
> * 一生只向真理與妻子低頭
> * Undergraduate student in National Taichung University of Education
> * LinkedIn: <https://linkedin.com/in/seamlik>
> * Blog: <http://seamlik.logdown.com>
> */
More information about the Android-tools-devel
mailing list