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

[殷啟聰]

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

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.

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

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