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

Thu Jul 16 17:38:27 UTC 2015

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

We need to match the version upstream uses for the public releases.  Those are
only really visible when updating Build-tools, Platform-tools, etc. via the
`android` tool, but they are also visible in the versioned folder names for
Build-tools.

So those are the versions like "22", "22.1.3", etc.  There is no need to add
.0.0 to versions if upstream doesn't.  "22" is a perfectly valid version
number in Debian.

> 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

That's a good idea, then that can serve as $ANDROID_HOME ultimately when we
have everything packaged, i.e. $ANDROID_HOME/build-tools,
$ANDROID_HOME/platform-tools, $ANDROID_HOME/tools, etc.

Could you document that idea in a new section on the AndroidTools wiki?

.hc

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