<div dir="ltr">Hi,<br><br><div class="gmail_quote"></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jun 30, 2016 at 4:48 PM 殷啟聰 <<a href="mailto:seamlikok@gmail.com" target="_blank">seamlikok@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Including libcore, frameworks/opt/telephony & frameworks/opt/net/voip into<br>
src:android-platform-frameworks-base does make sense because:<br>
<br>
* This 3 repos are necessary to build the "android.jar", so it makes sense to<br>
put them together.</blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div>Agreed. It would be best to have those 3 upstream repos in one debian source package. </div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="line-height:1.5"> </span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* "android.jar" is the core of an "Android Platforms", hence it makes<br>
sense to remain the package name as "android-platform-frameworks-base".<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Using "sources.zip" may not be a good idea because:<br>
<br>
* "sources.zip" and "platforms.zip" are non-free just like the official SDK<br>
bundle.<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div>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) </div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* "sources.zip" still lacks some classes in "android.jar". (For example the<br>
classes in "junit/" directory<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div>Are those classes included included under a folder with their package name perhaps?</div><div>I remember getting confused by that for some other class.</div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Although the Java sources inside the "sources.zip" is open source, the tarball<br>
itself is not. I do not know if that violates Debian's policy. If we are<br>
creating source packages depending on this tarball, the package might remain in<br>
"non-free" category.<br>
<br>
As we all have observed the structure of the "platforms/" directory, we know<br>
that the "Android Platforms" consists of plenty of files originate from various<br>
upstream repos, which makes it very complicated to reproduce the entire "Android<br>
Platforms" from source. How about we make a source package<br>
src:google-android-platforms-installer consists of downloader packages of all<br>
"Android Platforms" directly from Google?<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div>I agree with this, trying to build the android platforms would not be a good idea.<br>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)</div><div>Also, since those platforms wouldn't be oss they would probably go to non-free. I'm not exactly sure about this.<br>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.<br></div><div><br></div><div>hc another email about this with some ideas.</div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Kai-Chung Yan<br>
<br>
2016-06-17 14:47 GMT+08:00 Chirayu Desai <<a href="mailto:chirayudesai1@gmail.com" target="_blank">chirayudesai1@gmail.com</a>>:<br>
> We could run doclava on those files, which is what would have to be<br>
> done anyways.<br>
> So,<br>
> frameworks/base = full sources.<br>
> sources.zip = full public API sources, no hidden methods or classes<br>
> android.jar = stubs compiled using doclava from either of the above,<br>
> doclava is what produces the file list for sources.zip in the first<br>
> place.<br>
><br>
> sources.zip and android.jar should have matching classes (apart from<br>
> maybe uiautomator, not sure) - the content of each class would differ<br>
> (stubs vs code), but there wouldn't be any class which is in<br>
> android.jar and not in sources.zip<br>
><br>
> On Fri, Jun 17, 2016 at 12:41 AM, Hans-Christoph Steiner <<a href="mailto:hans@at.or.at" target="_blank">hans@at.or.at</a>> wrote:<br>
>><br>
>> I think I just found the fatal flaw in the sources-23-r01.zip approach:<br>
>> sources-23-r01.zip contains the full .java source files, file<br>
>> android.jar includes only the stub versions. Is there a tool that we<br>
>> can easily convert those sources to the stubbed versions? If not, then<br>
>> we should go with the plan that seamlik outlined.<br>
>><br>
>> .hc<br>
>><br>
>> Hans-Christoph Steiner:<br>
>>><br>
>>> Chirayu and I are probing around this approach. I think it makes sense<br>
>>> to make a custom source tarball for the platforms based on<br>
>>> sources-23_r01.zip, platform-23_r03.zip, then the remaining bits from<br>
>>> android-platform-frameworks-base.<br>
>>><br>
>>> Then we can keep the current android-platform-frameworks-base as it is.<br>
>>> For things that might need security updates like aapt, etc., they<br>
>>> should use the one-package-per-git-repo model so its easy to do security<br>
>>> updates. The android-platform-23 package does not really have<br>
>>> executable code, instead just API files for cross-compiling.<br>
>>><br>
>>> .hc<br>
>>><br>
>>> Hans-Christoph Steiner:<br>
>>>><br>
>>>> Is this only about building the 'platform' and android.jar? How about<br>
>>>> making a custom source package from the two upstream tarballs:<br>
>>>><br>
>>>> <a href="https://dl.google.com/android/repository/platform-23_r03.zip" rel="noreferrer" target="_blank">https://dl.google.com/android/repository/platform-23_r03.zip</a><br>
>>>> <a href="https://dl.google.com/android/repository/sources-23_r01.zip" rel="noreferrer" target="_blank">https://dl.google.com/android/repository/sources-23_r01.zip</a><br>
>>>><br>
>>>> We could make a little script that downloads those two and repacks into<br>
>>>> a DFSG-free tarball with just .java and res XML. Would that cover<br>
>>>> everything needed?<br>
>>>><br>
>>>> .hc<br>
>>>><br>
>>>> 殷啟聰:<br>
>>>>> Hi Chirayu,<br>
>>>>><br>
>>>>> IMO it is fine to reuse this existing<br>
>>>>> src:android-platform-frameworks-base. And we will probably need to<br>
>>>>> file an removal of src:android-platform-libcore since everything is<br>
>>>>> built from src:android-platform-frameworks-base.<br>
>>>>><br>
>>>>> It is indeed highly likely that we will need to prepare another merged<br>
>>>>> source package when we are doing NDK, but I think it is fine to avoid<br>
>>>>> the merging as long as every single artifacts (e.g. .so, .jar) can be<br>
>>>>> built from an independent repo of AOSP.<br>
>>>>><br>
>>>>> Cheers,<br>
>>>>> Kai-Chung Yan<br>
>>>>><br>
>>>>> Cheers,<br>
>>>>> Kai-Chung Yan<br>
>>>>><br>
>>>>> 2016-06-15 17:37 GMT+08:00 Chirayu Desai <<a href="mailto:chirayudesai1@gmail.com" target="_blank">chirayudesai1@gmail.com</a>>:<br>
>>>>>> Hi,<br>
>>>>>><br>
>>>>>> I get what you mean, which is why I suggested the src:android package.<br>
>>>>>> The name can be something else, but I would say it could be something<br>
>>>>>> other than android-platform-frameworks-base too because that would be<br>
>>>>>> confusing as well.<br>
>>>>>><br>
>>>>>> So src:name-of-new-package-for-android-jar<br>
>>>>>> tree:<br>
>>>>>> frameworks<br>
>>>>>> base<br>
>>>>>> opt<br>
>>>>>> net<br>
>>>>>> voip<br>
>>>>>> telephony<br>
>>>>>> libcore<br>
>>>>>> debian<br>
>>>>>><br>
>>>>>> which would be used to build the android.jar, having all the android<br>
>>>>>> sources needed in one debian source package would make it easier.<br>
>>>>>> Question is, what about the existing frameworks-base package, and the<br>
>>>>>> other packages it builds (aapt, etc)<br>
>>>>>> Also, it might be worth to think if we would need to do this kind of<br>
>>>>>> thing again in the future, for something else like the NDK or emulator<br>
>>>>>> images (just some random examples, as the emulator images would need a<br>
>>>>>> full android build which would be really complex)<br>
>>>>>><br>
>>>>>> Cheers,<br>
>>>>>> Chirayu Desai<br>
>>>>>><br>
>>>>>> On Wed, Jun 15, 2016 at 3:01 PM, 殷啟聰 <<a href="mailto:seamlikok@gmail.com" target="_blank">seamlikok@gmail.com</a>> wrote:<br>
>>>>>>> Hi Chirayu,<br>
>>>>>>><br>
>>>>>>> We can refer to the way how src:android-platform-system generate the<br>
>>>>>>> merged upstream tarball. And I don't think we need git submodule or<br>
>>>>>>> repo, because Git is only used to manage the history of our debian/<br>
>>>>>>> files, not the upstream files. We don't really need so much<br>
>>>>>>> complicated mechanism...<br>
>>>>>>><br>
>>>>>>> Cheers,<br>
>>>>>>> Kai-Chung Yan<br>
>>>>>>><br>
>>>>>>> 2016-06-15 17:22 GMT+08:00 Chirayu Desai <<a href="mailto:chirayudesai1@gmail.com" target="_blank">chirayudesai1@gmail.com</a>>:<br>
>>>>>>>> Hi,<br>
>>>>>>>><br>
>>>>>>>> On Wed, Jun 15, 2016 at 2:43 PM, 殷啟聰 <<a href="mailto:seamlikok@gmail.com" target="_blank">seamlikok@gmail.com</a>> wrote:<br>
>>>>>>>>> Hi,<br>
>>>>>>>>><br>
>>>>>>>>> The name of "src:android" is too general. Since this repo contains<br>
>>>>>>>>> mostly files of android-platform-frameworks-base, we can simply reuse<br>
>>>>>>>>> this source package. Actually there was an src:sndroid-platform-system<br>
>>>>>>>>> [1] which consisted of android-platform-system-core and<br>
>>>>>>>>> android-platform-system-extras, but we later use staged builds to<br>
>>>>>>>>> resolve the circular dependency between them and we split them up.<br>
>>>>>>>>> src:android-platform-frameworks-compile [2] is also a combination of<br>
>>>>>>>>> multiple upstream sources, but I am also thinking about splitting them<br>
>>>>>>>>> up.<br>
>>>>>>>> Yes, I agree "src:android" is too general. However I suggested that<br>
>>>>>>>> because you said you wanted to maintain the upstream structure, and I<br>
>>>>>>>> would think that it would make sense.<br>
>>>>>>>><br>
>>>>>>>> Or did you mean something else?<br>
>>>>>>>><br>
>>>>>>>> It seems that if there was a way to properly replicate the upstream<br>
>>>>>>>> structure properly, i.e. one git repo per upstream repo, one source<br>
>>>>>>>> tarball, etc., and then do something combining all of those, it might<br>
>>>>>>>> be best. If possible, of course.<br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Cheers,<br>
>>>>>>>>> Kai-Chung Yan<br>
>>>>>>>>><br>
>>>>>>>>> [1]: <a href="https://anonscm.debian.org/cgit/android-tools/android-platform-system.git" rel="noreferrer" target="_blank">https://anonscm.debian.org/cgit/android-tools/android-platform-system.git</a><br>
>>>>>>>>> [2]: <a href="https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-compile.git" rel="noreferrer" target="_blank">https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-compile.git</a><br>
>>>>>>>>><br>
>>>>>>>>> 2016-06-14 22:24 GMT+08:00 Chirayu Desai <<a href="mailto:chirayudesai1@gmail.com" target="_blank">chirayudesai1@gmail.com</a>>:<br>
>>>>>>>>>> Hi,<br>
>>>>>>>>>><br>
>>>>>>>>>> On Tue, Jun 14, 2016 at 6:54 PM, 殷啟聰 <<a href="mailto:seamlikok@gmail.com" target="_blank">seamlikok@gmail.com</a>> wrote:<br>
>>>>>>>>>>> Hi Markus and Hans,<br>
>>>>>>>>>>><br>
>>>>>>>>>>> The reason of providing Java source files in android-platform-libcore<br>
>>>>>>>>>>> is because we use Doclava to analyze all Java source of the Android<br>
>>>>>>>>>>> platform framework and generate some API stubs which are Java sources<br>
>>>>>>>>>>> having only the definitions but not the implementations, much like a<br>
>>>>>>>>>>> header file in C/C++. And "android.jar" is built using these API<br>
>>>>>>>>>>> stubs. All compiled classes are bundled into a single "android.jar",<br>
>>>>>>>>>>> so we are not building any separated Java libraries.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> I successfully built "android.jar" in the android-jar-old branch [1]<br>
>>>>>>>>>>> and after I compare this "android.jar" to the upstream one I found<br>
>>>>>>>>>>> that it is not enough. We need 2 more repos:<br>
>>>>>>>>>>><br>
>>>>>>>>>>> * <a href="https://android.googlesource.com/platform/frameworks/opt/telephony" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/frameworks/opt/telephony</a><br>
>>>>>>>>>>> * <a href="https://android.googlesource.com/platform/frameworks/opt/net/voip" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/frameworks/opt/net/voip</a><br>
>>>>>>>>>>><br>
>>>>>>>>>>> I find it unacceptable if we are also building another 2 binary<br>
>>>>>>>>>>> packages containing Java source files and with version string in the<br>
>>>>>>>>>>> package names. So it would be better if we combine<br>
>>>>>>>>>>> android-platform-libcore and this 2 repos into one single<br>
>>>>>>>>>>> src:android-platform-frameworks-base.<br>
>>>>>>>>>> Or it could be a new single src:android, preserving the upstream<br>
>>>>>>>>>> directory structure.<br>
>>>>>>>>>> i.e.<br>
>>>>>>>>>> android<br>
>>>>>>>>>> frameworks<br>
>>>>>>>>>> base<br>
>>>>>>>>>> opt<br>
>>>>>>>>>> net<br>
>>>>>>>>>> voip<br>
>>>>>>>>>> telephony<br>
>>>>>>>>>> libcore<br>
>>>>>>>>>><br>
>>>>>>>>>> and so on.<br>
>>>>>>>>>><br>
>>>>>>>>>> However, it might get too big.<br>
>>>>>>>>>> Also, existing packages, mainly from<br>
>>>>>>>>>> src:android-platform-frameworks-base would have to be migrated.<br>
>>>>>>>>>><br>
>>>>>>>>>> Is there any other saner way?<br>
>>>>>>>>>> Could we perhaps use git submodules (or upstream's 'repo' tool) in some way?<br>
>>>>>>>>>>><br>
>>>>>>>>>>> I don't know if there are any conventional or simple way of making a<br>
>>>>>>>>>>> source package tarball from multiple upstream tarball. I only know<br>
>>>>>>>>>>> that the latest uscan (version 4 watch file) supports creating<br>
>>>>>>>>>>> tarballs from multiple upstream tarballs, but I don't know if<br>
>>>>>>>>>>> mk-origtargz supports it or there are other ways.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Cheers,<br>
>>>>>>>>>>> Kai-Chung Yan<br>
>>>>>>>>>>><br>
>>>>>>>>>>> [1]: <a href="https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-base.git/?h=android-jar-old" rel="noreferrer" target="_blank">https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-base.git/?h=android-jar-old</a><br>
>>>>>>>>>>><br>
>>>>>>>>>>> 2016-06-10 18:53 GMT+08:00 Markus Koschany <<a href="mailto:apo@debian.org" target="_blank">apo@debian.org</a>>:<br>
>>>>>>>>>>>> On 08.06.2016 20:43, Hans-Christoph Steiner wrote:<br>
>>>>>>>>>>>> [...]<br>
>>>>>>>>>>>>> About android-platform-libcore-source-6.0.1, seems like we'll have to<br>
>>>>>>>>>>>>> combine multiple upstream git repos into a single debian source package<br>
>>>>>>>>>>>>> if android.jar needs to be built from multiple git repos at the same<br>
>>>>>>>>>>>>> time. I think a source package can have multiple source tarballs, so<br>
>>>>>>>>>>>>> the source tarballs could still be directly tied to the git repos.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Sure, you can combine multiple upstream repos into one Debian repo as<br>
>>>>>>>>>>>> well. It is just a matter of documentation.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>>> Another approach that's a bit hacky is packaging the bits of android.jar<br>
>>>>>>>>>>>>> separately from each git repo, then make a post-install script that<br>
>>>>>>>>>>>>> compiles android.jar from them. Markus might kill me for making that<br>
>>>>>>>>>>>>> suggestion ;)<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> I guess I need to see the whole packaging for android.jar first before I<br>
>>>>>>>>>>>> ask Igor to do something terrible. ;)<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>>> Android-tools-devel mailing list<br>
>>>>>>>>>>>> <a href="mailto:Android-tools-devel@lists.alioth.debian.org" target="_blank">Android-tools-devel@lists.alioth.debian.org</a><br>
>>>>>>>>>>>> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel</a><br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> --<br>
>>>>>>>>>>> /*<br>
>>>>>>>>>>> * 殷啟聰 | Kai-Chung Yan<br>
>>>>>>>>>>> * 一生只向真理與妻子低頭<br>
>>>>>>>>>>> * Undergraduate student in National Taichung University of Education<br>
>>>>>>>>>>> * LinkedIn: <<a href="https://linkedin.com/in/seamlik" rel="noreferrer" target="_blank">https://linkedin.com/in/seamlik</a>><br>
>>>>>>>>>>> * Blog: <<a href="http://seamlik.logdown.com" rel="noreferrer" target="_blank">http://seamlik.logdown.com</a>><br>
>>>>>>>>>>> */<br>
>>>>>>>>>>><br>
>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>> Android-tools-devel mailing list<br>
>>>>>>>>>>> <a href="mailto:Android-tools-devel@lists.alioth.debian.org" target="_blank">Android-tools-devel@lists.alioth.debian.org</a><br>
>>>>>>>>>>> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> --<br>
>>>>>>>>> /*<br>
>>>>>>>>> * 殷啟聰 | Kai-Chung Yan<br>
>>>>>>>>> * 一生只向真理與妻子低頭<br>
>>>>>>>>> * Undergraduate student in National Taichung University of Education<br>
>>>>>>>>> * LinkedIn: <<a href="https://linkedin.com/in/seamlik" rel="noreferrer" target="_blank">https://linkedin.com/in/seamlik</a>><br>
>>>>>>>>> * Blog: <<a href="http://seamlik.logdown.com" rel="noreferrer" target="_blank">http://seamlik.logdown.com</a>><br>
>>>>>>>>> */<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> /*<br>
>>>>>>> * 殷啟聰 | Kai-Chung Yan<br>
>>>>>>> * 一生只向真理與妻子低頭<br>
>>>>>>> * Undergraduate student in National Taichung University of Education<br>
>>>>>>> * LinkedIn: <<a href="https://linkedin.com/in/seamlik" rel="noreferrer" target="_blank">https://linkedin.com/in/seamlik</a>><br>
>>>>>>> * Blog: <<a href="http://seamlik.logdown.com" rel="noreferrer" target="_blank">http://seamlik.logdown.com</a>><br>
>>>>>>> */<br>
>>>>><br>
>>>>><br>
>>>>><br>
>><br>
>> _______________________________________________<br>
>> Android-tools-devel mailing list<br>
>> <a href="mailto:Android-tools-devel@lists.alioth.debian.org" target="_blank">Android-tools-devel@lists.alioth.debian.org</a><br>
>> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel</a><br>
><br>
> _______________________________________________<br>
> Android-tools-devel mailing list<br>
> <a href="mailto:Android-tools-devel@lists.alioth.debian.org" target="_blank">Android-tools-devel@lists.alioth.debian.org</a><br>
> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel</a><br>
<br>
<br>
<br>
--<br>
/*<br>
* 殷啟聰 | Kai-Chung Yan<br>
* 一生只向真理與妻子低頭<br>
* Undergraduate student in National Taichung University of Education<br>
* LinkedIn: <<a href="https://linkedin.com/in/seamlik" rel="noreferrer" target="_blank">https://linkedin.com/in/seamlik</a>><br>
* Blog: <<a href="http://seamlik.logdown.com" rel="noreferrer" target="_blank">http://seamlik.logdown.com</a>><br>
*/<br>
<br>
_______________________________________________<br>
Android-tools-devel mailing list<br>
<a href="mailto:Android-tools-devel@lists.alioth.debian.org" target="_blank">Android-tools-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel</a></blockquote></div></div>