[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1

Hans-Christoph Steiner hans at at.or.at
Thu Jun 16 13:36:38 UTC 2016 

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