[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r16-1
Chirayu Desai
chirayudesai1 at gmail.com
Fri Jun 17 06:47:07 UTC 2016
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
More information about the Android-tools-devel
mailing list