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

Fri Jul 17 04:15:41 UTC 2015

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