<p dir="ltr">Hi,</p>
<p dir="ltr">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.</p>
<p dir="ltr">Although androidsdk-tools is good to remain the version scheme.</p>
<p dir="ltr">I am also thinking of installing symlinks to the tools in /usr/share/android-sdk/ which serves as the pseudo SDK installation location.</p>
<p dir="ltr">Cheers,<br>
Kai-Chung Yan</p>
<br><div class="gmail_quote"><div dir="ltr">2015 年 7 月 11 日 (週六)14:31 <Hans-Christoph Steiner> 於 <a href="mailto:hans@at.or.at">hans@at.or.at</a> 寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Markus Koschany:<br>
> Hi,<br>
><br>
> Am 10.07.2015 um 18:42 schrieb 殷啟聰:<br>
> [...]<br>
>> 1. How should we define the version of the source package?<br>
>> platform/dalvik produces tools belonging to both SDK Built-tools and<br>
>> SDK Platform-tools, but this two toolsets have different version<br>
>> numbers. Should we simply use "android-5.1.1_r6" as the version<br>
>> number? Or "5.1.1~r6"?<br>
<br>
We need to find the source of the "Android SDK Tools" 24.3.3. and "Android SDK<br>
Build-tools" 22.0.1.<br>
<br>
<br>
> I suppose r stands for (pre)release and the next "real" release will be<br>
> 5.1.2 or similar. Then it makes sense to use 5.1.1~r6 because the number<br>
> is smaller than 5.1.2. This is a common pattern in Debian.<br>
<br>
As far as I understand it, that _r6 is actually a bugfix version, so like 5.1.1.6.<br>
<br>
The tricky part of all this is that Google uses different version schemes for<br>
the SDK and build tools.  For example, Android 5.1.1 is SDK android-22.<br>
"Platform Tools" uses the SDK version e.g. 22.  Then the "Build Tools" uses<br>
that SDK version as a major version with its own minor and bugfix versions.<br>
But some parts of the SDK use a different major version, e.g "Android SDK<br>
Tools v 24.3.3".  Its a mess...<br>
<br>
<br>
>> 2. Why is the architecture of android-platform-system-core packages is<br>
>> "linux-any" instead of "any"?<br>
<br>
Upstream only supports GNU/Linux not GNU/Hurd or GNU/kFreeBSD.<br>
<br>
<br>
> It seems the build failed at least on kfreebsd architectures.<br>
><br>
> <a href="https://buildd.debian.org/status/logs.php?pkg=android-platform-system-core&arch=kfreebsd-amd64" rel="noreferrer" target="_blank">https://buildd.debian.org/status/logs.php?pkg=android-platform-system-core&arch=kfreebsd-amd64</a><br>
><br>
> This may be a temporary problem with the buildd, a bug in<br>
> android-platform-system-core or upstream doesn't support<br>
> freebsd/kfreebsd at all. I don't think the latter is true because I can<br>
> find several Android related ports for FreeBSD, e.g.<br>
><br>
> <a href="https://www.freshports.org/devel/android-tools-adb/" rel="noreferrer" target="_blank">https://www.freshports.org/devel/android-tools-adb/</a><br>
><br>
> So the decision to build only for Linux should be reconsidered.<br>
<br>
There is still lots to be done, we don't need to get bogged down with details<br>
like supporting non-Linux kernels.  We can leave the kFreeBSD porting to the<br>
kFreeBSD people.  Let's get these packages working well for the vast majority<br>
of people (Linux on amd64 and i386).<br>
<br>
<br>
>> 3. Are executables looks for .so files recursively under /usr/lib/ or<br>
>> /lib/ ? libzipfile.so and other Android libraries are placed under<br>
>> /usr/lib/android/ but I do not see any specific configuration for<br>
>> that.<br>
><br>
> You can find an dh_shlibdeps override in debian/rules. From the man page<br>
> of dh_shlibdeps:<br>
><br>
>  -ldirectory[:directory ...]<br>
> With recent versions of dpkg-shlibdeps, this option is generally not<br>
> needed. It tells dpkg-shlibdeps (via its -l parameter), to look for<br>
> private package libraries in the specified directory (or directories --<br>
> separate with colons). With recent versions of dpkg-shlibdeps, this is<br>
> mostly only useful for packages that build multiple flavors of the same<br>
> library, or other situations where the library is installed into a<br>
> directory not on the regular library search path.<br>
><br>
><br>
>> 4. Why the .so version is 0.21.0? For example libzipfile.so.0.21.0,<br>
>> why is it not libzipfile.so.21?<br>
><br>
> I guess that's a question for upstream because they define the<br>
> versioning. :)<br>
><br>
> Regards,<br>
><br>
> Markus<br>
<br>
<br>
I chose those versions.  Upstream does not build dynamic versions of those<br>
libraries, but only statically links that code into each executable.  I used<br>
0.21.0 to give room to set an 'epoch' as the first version number.  the 21 is<br>
the SDK version. You can see that particular example here:<br>
<br>
debian/patches/libandroidzipfile_makefile_pkgconfig<br>
<br>
.hc<br>
<br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">殷啟聰 | Kai-Chung Yan<br>
一生只向真理與妻子低頭<br>
Full-time student of Providence University of Taiwan<br>
LinkedIn: <<a href="https://linkedin.com/in/seamlik">https://linkedin.com/in/seamlik</a>><br>
Blog: <<a href="http://seamlik.logdown.com">seamlik.logdown.com</a>></p>
</div>