[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1
Hans-Christoph Steiner
hans at at.or.at
Thu Jun 16 19:11:12 UTC 2016
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>
>>>>> */
>>>
>>>
>>>
More information about the Android-tools-devel
mailing list