[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1
殷啟聰
seamlikok at gmail.com
Tue Jul 19 09:11:50 UTC 2016
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
2. New src:android-platform-23 or src:android-platform-framework-23
for a combination of 4 repos
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
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.
C) Remain the 2 existing packages as is and only include necessary
file in src:android-platform-framework-23
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.
Cheers,
Kai-Chung Yan
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