[Android-tools-devel] google-android-platform-* packages WAS: android-platform-libcore/6.0.1+r16-1

Hans-Christoph Steiner hans at at.or.at
Mon Jul 11 09:10:59 UTC 2016 

Its definitely clear that building the android.jar is quite complicated.
 I think its a good idea to make a package for each platform binary from
Google and use that for now.  Mouaad already has the template for that
kind of package quite polished, so we can just use those and it should
not be a lot of work to make the 24 platforms packages.

Here are some open questions:

* we should handle mirror selection in a global way for all
google-android-* packages. I guess we could just have
/etc/default/google-android-installers as the file where that preference
is stored

* In order for any package to have a contrib package in Recommends:, it
must also be in contrib.  I don't think we should move android-sdk-meta
to contrib, so perhaps we should have a google-android-sdk-meta or
something like that to install all the required bits from contrib to
have a working build.

* android-sdk-meta can have contrib packages in Suggests:, so I think we
should definitely have some there.

.hc



Chirayu Desai:
> 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
>

More information about the Android-tools-devel mailing list