[Android-tools-devel] Updating android-platform-system-core

[殷啟聰]

Hi,

I found another circular dependencies! zipalign in android-platform-build
requires libcutils.so in android-platform-system while
android-platform-system build-depends on AndroidConfig.h in
android-platform-build.

About the version scheme, I still insist using 5.1.1.8 instead. These
various repo do not only contain the SDK programs, instead they are
actually the core components of Android. For example platform/dalvik which
contains dx, is the apparently the code base of Dalvik Virtual Machine. As
for platform/system/core, it is the minimal boot environment of Android as
is written. So the best solution is to follow the entire Android version
number.

If you check the git history you can find that even the "SDK version" has
remains 22 but the codes have changed a lot. Also, if you simply ignore the
minor part in 22.1.3 (Build-tools version) and simply use 22 for both
toolsets, some day Google may have released 22.1.4 and the users still has
the old version because we have ignored the difference.

Cheers,
Kai-Chung Yan

2015 年 7 月 17 日 (週五)12:15 <Hans-Christoph Steiner> 於 hans at at.or.at 寫道：

>
>
> 殷啟聰:
> > Hi,
> >
> > I am currently working on a new source package
> > "android-platform-system" based on "android-platform-system-core", and
> > another new source package "android-platform-build". They are
> > currently on GitHub:
> >
> > * android-platform-system:
> https://github.com/seamlik/android-platform-system
> > * android-platform-build:
> https://github.com/seamlik/android-platform-build
>
> android-platform-build already exists, it should be updated:
> https://anonscm.debian.org/cgit/android-tools/android-platform-build.git
>
>
> > Currently android-platform-build only produces one binary package:
> > android-globalconfig-dev, which installs AndroidConfig.h for all
> > architectures originating from
> > <
> https://android.googlesource.com/platform/build/+/master/core/combo/arch>
> > to /usr/include/android/. The upstream of the source package is simply
> > platform/build. These AndroidConfig.h must be included in all Android
> > C/C++ libraries so it makes sense to become a separated package.
> > Packages like android-platform-system and android-platform-dalvik
> > should build-depends on it.
> >
> > However the mechanism of selecting which AndroidConfig.h to use is
> > rather unreliable for now. It uses uname -m to determine the
> > architecture currently, but I will use dpkg-architecture in the
> > future. Do you have a better idea?
> >
> > Currently android-platform-system consists of platform/system/core and
> > platform/system/extra. The reason I chose not to make separated ones
> > is the circular dependencies between them if they are separated. For
> > example, fastboot requires f2fs_utils (in platform/system/extra), and
> > f2fs_utils requires libsparse (in platform/system/core). There are
> > more components under platform/system/ but it is good to include this
> > two for now, maybe we will need to include others like
> > platform/system/bluetooth in the future.
> >
> > I also restructured the Debian codes so that every modules
> > android-platform-system produces uses an individual .mk file, and they
> > are not managed by Quilt.
>
> That's a nice system. :)
>
>
> > However there is a problem now. f2fs_utils requires another libraries
> > from upstream f2fs-tools and e2fsprogs which are external projects
> > (also available at
> > https://android.googlesource.com/platform/external/f2fs-tools and
> > https://android.googlesource.com/platform/external/e2fsprogs) and
> > available in Debian as well (See
> > https://packages.debian.org/source/sid/f2fs-tools and
> > https://packages.debian.org/source/sid/e2fsprogs). But none of their
> > Debian versions contains the libraries f2fs_utils requires. It
> > requires      .so from e2fsprogs and libf2fs_format.so from
> > f2fs-tools.
> >
> > The best and ideal solution is to contact with their maintainers in
> > Debian and make the packages produce those libraries, but it may take
> > a long time and the required libraries may be simply unnecessary for
> > the upstream. The second solution is to check the upstream and the
> > Debian sources and see if the upstream's main libraries has already
> > included all APIs in libext2_uuid.so and libf2fs_format.so, but I
> > guess it is rather unlikly. The third solution is to make another new
> > source package "android-platform-external" which consist of
> > platform/external/f2fs-tools and platform/external/e2fsprogs. This
> > solution is the easiest and fastest one but I don't know if it breaks
> > any Debian policies.
> >
> > What are you opinion?
>
> If the versions of f2fs-tools and e2fsprogs in Android and Debian are quite
> close, then I think the best approach would be to make the Debian packages
> include those libraries.  If Android uses old versions or doesn't update
> much,
> then I think the android-platform-external approach is better.
>
> .hc
>
>
> >
> > Cheers,
> > Kai-Chung Yan
> >
> > 2015-07-11 20:12 GMT+08:00 殷啟聰 <seamlikok at gmail.com>:
> >> Hi,
> >>
> >> So far we have 2 options of defining the version of android-platform-*
> >> source packages. Suppose we are fetching sources with tag
> >> "android-5.1.1_r8", then the source version can be "22" or "1:5.1.1.8".
> The
> >> former may be  incorrect to some extent because the version of SDK
> >> Build-tools is 22.1.3 but the version of SDK Platform-tools is 22.0.0
> which
> >> do not match. Therefore I prefer "1:5.1.1.8" which seems odd though.
> >>
> >> Although androidsdk-tools is good to remain the version scheme.
> >>
> >> I am also thinking of installing symlinks to the tools in
> >> /usr/share/android-sdk/ which serves as the pseudo SDK installation
> >> location.
> >>
> >> Cheers,
> >> Kai-Chung Yan
> >>
> >>
> >> 2015 年 7 月 11 日 (週六)14:31 <Hans-Christoph Steiner> 於 hans at at.or.at 寫道：
> >>>
> >>>
> >>> Markus Koschany:
> >>>> Hi,
> >>>>
> >>>> Am 10.07.2015 um 18:42 schrieb 殷啟聰:
> >>>> [...]
> >>>>> 1. How should we define the version of the source package?
> >>>>> platform/dalvik produces tools belonging to both SDK Built-tools and
> >>>>> SDK Platform-tools, but this two toolsets have different version
> >>>>> numbers. Should we simply use "android-5.1.1_r6" as the version
> >>>>> number? Or "5.1.1~r6"?
> >>>
> >>> We need to find the source of the "Android SDK Tools" 24.3.3. and
> "Android
> >>> SDK
> >>> Build-tools" 22.0.1.
> >>>
> >>>
> >>>> I suppose r stands for (pre)release and the next "real" release will
> be
> >>>> 5.1.2 or similar. Then it makes sense to use 5.1.1~r6 because the
> number
> >>>> is smaller than 5.1.2. This is a common pattern in Debian.
> >>>
> >>> As far as I understand it, that _r6 is actually a bugfix version, so
> like
> >>> 5.1.1.6.
> >>>
> >>> The tricky part of all this is that Google uses different version
> schemes
> >>> for
> >>> the SDK and build tools.  For example, Android 5.1.1 is SDK android-22.
> >>> "Platform Tools" uses the SDK version e.g. 22.  Then the "Build Tools"
> >>> uses
> >>> that SDK version as a major version with its own minor and bugfix
> >>> versions.
> >>> But some parts of the SDK use a different major version, e.g "Android
> SDK
> >>> Tools v 24.3.3".  Its a mess...
> >>>
> >>>
> >>>>> 2. Why is the architecture of android-platform-system-core packages
> is
> >>>>> "linux-any" instead of "any"?
> >>>
> >>> Upstream only supports GNU/Linux not GNU/Hurd or GNU/kFreeBSD.
> >>>
> >>>
> >>>> It seems the build failed at least on kfreebsd architectures.
> >>>>
> >>>>
> >>>>
> https://buildd.debian.org/status/logs.php?pkg=android-platform-system-core&arch=kfreebsd-amd64
> >>>>
> >>>> This may be a temporary problem with the buildd, a bug in
> >>>> android-platform-system-core or upstream doesn't support
> >>>> freebsd/kfreebsd at all. I don't think the latter is true because I
> can
> >>>> find several Android related ports for FreeBSD, e.g.
> >>>>
> >>>> https://www.freshports.org/devel/android-tools-adb/
> >>>>
> >>>> So the decision to build only for Linux should be reconsidered.
> >>>
> >>> There is still lots to be done, we don't need to get bogged down with
> >>> details
> >>> like supporting non-Linux kernels.  We can leave the kFreeBSD porting
> to
> >>> the
> >>> kFreeBSD people.  Let's get these packages working well for the vast
> >>> majority
> >>> of people (Linux on amd64 and i386).
> >>>
> >>>
> >>>>> 3. Are executables looks for .so files recursively under /usr/lib/ or
> >>>>> /lib/ ? libzipfile.so and other Android libraries are placed under
> >>>>> /usr/lib/android/ but I do not see any specific configuration for
> >>>>> that.
> >>>>
> >>>> You can find an dh_shlibdeps override in debian/rules. From the man
> page
> >>>> of dh_shlibdeps:
> >>>>
> >>>>  -ldirectory[:directory ...]
> >>>> With recent versions of dpkg-shlibdeps, this option is generally not
> >>>> needed. It tells dpkg-shlibdeps (via its -l parameter), to look for
> >>>> private package libraries in the specified directory (or directories
> --
> >>>> separate with colons). With recent versions of dpkg-shlibdeps, this is
> >>>> mostly only useful for packages that build multiple flavors of the
> same
> >>>> library, or other situations where the library is installed into a
> >>>> directory not on the regular library search path.
> >>>>
> >>>>
> >>>>> 4. Why the .so version is 0.21.0? For example libzipfile.so.0.21.0,
> >>>>> why is it not libzipfile.so.21?
> >>>>
> >>>> I guess that's a question for upstream because they define the
> >>>> versioning. :)
> >>>>
> >>>> Regards,
> >>>>
> >>>> Markus
> >>>
> >>>
> >>> I chose those versions.  Upstream does not build dynamic versions of
> those
> >>> libraries, but only statically links that code into each executable.  I
> >>> used
> >>> 0.21.0 to give room to set an 'epoch' as the first version number.
> the 21
> >>> is
> >>> the SDK version. You can see that particular example here:
> >>>
> >>> debian/patches/libandroidzipfile_makefile_pkgconfig
> >>>
> >>> .hc
> >>>
> >> --
> >>
> >> 殷啟聰 | Kai-Chung Yan
> >> 一生只向真理與妻子低頭
> >> Full-time student of Providence University of Taiwan
> >> LinkedIn: <https://linkedin.com/in/seamlik>
> >> Blog: <seamlik.logdown.com>
> >
> >
> >
>
-- 

殷啟聰 | Kai-Chung Yan
一生只向真理與妻子低頭
Full-time student of National Taichung University of Education
LinkedIn: <https://linkedin.com/in/seamlik>
Blog: <seamlik.logdown.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20150717/1260e9ec/attachment.html>