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

Fri Jul 17 16:07:38 UTC 2015

殷啟聰:
> 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.

Arg, why on earth did they move AndroidConfig.h?  What a pain.  I think we
should just include a copy of all the AndroidConfig.h (i.e.
core/combo/include/arch) in android-platform-system and document that in
debian/README.Source.

Then android-platform-build should make core/combo/include in a separate
package, like you said before.

> 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.

It is true that these git repos include a mix of SDK Tools and components of
Android OS. We are not building the core components of Android itself, we're
building the SDK Tools and SDK.  Upstream also builds the SDK Tools and
Android from the same git repos, and yet upstream gives the SDK Tools separate
version numbers from Android OS.

> 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.

We should do what upstream does.  For Build-tools, it is obvious that they
make minor (22, 22.1, etc.) and bugfix releases (22.1.1, 22.1.2, etc.).  For
"Android SDK Platform-tools", the only make major releases (20, 21, 22) though
they have recently starting doing RC (23 rc4).  Its an insane system for sure,
but if we don't follow it in Debian, it will confuse users when they are
comparing to the official releases from Google.

We need to track these SDK versions anyway, since
/usr/share/android-sdk/build-tools needs to have versioned subdirectories.

.hc

> 
> 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>
>>>
>>>
>>>
>>