New distribution tactics

July 12th, 2010

In brief: preferred way to download SDK is via android tool now. Just like in official SDK.

This package is used to get other packages. This package have modified android tool (in fact sdklib.jar and so on), which accepts freebsd attribute in repository.xml. To add BSDroid repository to android tool define environment variable SDK_UPDATER_URLS as http://bsdroid.org/ before execution of android tool. E.g. in csh: setenv SDK_UPDATER_URLS http://bsdroid.org/

NOTES:

  • don’t forget slash symbol at the end of repository address. Otherwise android tool expects that URI points to xml file, which describes repository (http://bsdroid.org/repository.xml)
  • if you add BSDroid repository from GUI, android tool will ignore all packages except samples and extras. That is default behavior (it seems, original idea of this behavior is: platforms and tools must be distributed by Google only), which I’ve not changed yet.
  • PS:
    For those who prefer old way of distribution, all packages (as well as old style sdk archive) are available in downloads section of site as usual.

    PPS:
    only i386 packages are published now.

    RepoSource saga

    July 8th, 2010

    Today I’ve thought, it’s time to make BSDroid packages updateable via android tool.
    That was epic adventure to the deepest depth of sdklib sources and backwards.

    Firstly, scheme sdk-repository-2.xsd contains no enumeration value for freebsd, which itself is somehow discriminating. Moreover, scheme is integrated as resource to sdklib.jar, which makes it’s impossible to validate via non local schemes (e.g. it’s impossible to provide scheme for BSDroid’s repository.xml, stored on BSDroid site without changes in sources).

    Secondly, Archive.java contains hard coded values for OS constants. No sign of BSD as well :) . Funny, but architecture related constants have no such problem, cause amd64 is handled correctly (casted to Arch.X86_64). BTW: I think such hard coded values is bad design, cause there is no point in scheme checking for this values, if we perform checking again in java class (well, it have some meaning for architecture due i386/i586/i686/x86 zoo, but not for OS). It’d be much simplier to check compatibility by string equality/pattern check.

    Anyway, here is result of todays work: http://pastebin.com/HT5HWpux
    The only problem now is to find where I’ve lost files attributes.
    Patched sdklib, sdkuilib jars will be uploaded this weekend with new SDK snapshot.

    Well, some progress

    July 6th, 2010

    Built i386 version, which must be more correct than previous one (now it’s tag is AOSP, not 2.2). Forced droiddoc.mk to use JDK 1.5, other stuff compiled by JDK 1.6. Need to think about android’s doclet, as JDK 1.5 is just temporarily handicap.

    amd64′s version was compiled as well, however during tests there were problems at least in aapt, mksnapshot and emulator. Last two utilities crashed, first one just fails to work. I’ll let it be in such state for now, cause want to work on other parts of source tree and don’t know qemu sources well yet.

    BTW, I’m using VNC to check my compile node, thus once, while I was fixing some libpng mess, I’ve thought: why there is no provider for remote access to Android phones and emulators? If we look to Nokia’s developers site – they have a lot of devices and emulators for testing your code on. It’s good for development of more stable and reliable applications on fragmented platforms and support upcoming hardware/devices.

    2.2 build completed for i386

    June 28th, 2010

    Considered as early and experimental due generics construction in framework/base’s ListActivity.java and others, which fails to be compiled with jdk 1.5:

    public void
    onItemClick(AdapterView p, View v, int pos, long id)
    {
    onListItemClick((ListView)p, v, pos, id);
    }

    where ListView casting strikes back with compile time type check error.

    Actually, in previous versions I was building it with jdk 1.6, but in this build just commented out onListItemClick() call as temporarily workaround, which may lead to unexpected behavior when subclassing and using this class. Also, now swt-3.5.1_1 (3555) is used.

    You may get this build via direct link here. Still struggling to make amd64 version compilable.

    Bsdroid pulse

    June 24th, 2010

    Ok, there were days when I’ve thought, I’d never publish anything in that blog again… but, fortunately, that was just period of laziness, which was successfully finished (with some bada and iOS development experience as bonus). So, if you’re still reading this, then probably, you’re interested in bsdroid project and it’s state.

    About two weeks ago, I’ve managed to steal one compile node from cluster for amd64 architecture. Well, source tree is not fully compilable and there may be huge problems with several projects, but hey, it’s first step, something is already compilable, although not tested. As result, now I’ve two servers, which compile source tree at the nights.

    Actually, I was trying to proceed more in qemu compilation related issues, but synced source tree and have found, that Froyo is in AOSP now. I guess, I need recompile yesterday’s i386 snapshot again before processing further with amd64.

    What changes are expected in future?
    1. I plan to focus on binary tools distribution only as SDK may be taken from official android site.
    2. as was planned earlier, bsdroid tools will be available for downloading via android tool, which is more flexible, than now.
    3. previously, snapshots were built with generic-eng target, now I’m building it with aosp_emulator_eu-eng.
    4. as FreeBSD related patches are not welcomed in gerrit anymore, I’ll be publishing patches from time to time here (well, just “git diff korg/master”, I’m lazy after all). Non related to FreeBSD patches (e.g. some cosmetics fixes in java-code) will be uploaded for review as earlier.

    That’s all. Time to start build.

    Happy New Year!

    December 31st, 2009

    Hi, everyone!

    Today is the latest day in 2009, I’ll meet 1st January in next few hours. So, it’s time to summarize some results of BSDroid project and think about plans for next year.

    Main goal of project – Android SDK for FreeBSD 8.0 x86 – was reached, anyone may download it from BSDroid website now, some related patches were integrated to korg/master. Not each patch was correct, but I hope – all were useful and not only for BSD addicted persons. In fact, there were not so many interested in this project guys, but anyway I see downloads count and it increased a bit last months, project received some attention in community and several other Android on FreeBSD projects were raised (e.g. Freebroid).

    Next year goals are: Android SDK for FreeBSD 8.0 amd64, fastboot support, releases of new AOSP SDK versions snapshots, testing of tools, public git-repository for BSDroid and etc. I hope together we will complete all these tasks.

    Thank you everyone for support and interest.
    All best wishes to you and your families!
    Let’s have even more fun next year.

    Time for Eclair

    November 18th, 2009

    Eclair was integrated to AOSP several days ago by Jean-Baptiste Queru and company. Well, most of it, as some parts of Android 2.0 codebase are not open-sourced. Today’s snapshot is quick and dirty build of Eclair, which as you all know, includes some tasty things. I hope, HTC will provide Android 2.0 for Hero in next few weeks, cause I’m really starving without VPN support in 1.5.

    You may note, that there are no API levels at platform selection in android tool anymore, only AOSP related platform. It seems correct, although I’ve not performed robust testing of API changes yet.

    Related changes were not uploaded for review yet, I’ll do it a bit later, most of them are my old patches actually, which were used on Donut branch, however there are several not significant new patches.

    Snapshot 20091110

    November 10th, 2009

    I’ve finally uploaded new SDK snapshot. It’s still Donut, cause Eclair was not completely integrated to AOSP source tree yet, only some drops of code.

    Main features:
    1. Snapshot includes adb, able to work with real devices via usb
    2. Binaries were compiled without optimized instructions sets (no SSE2 and so on), so it must work on older CPUs, like Athlons XP, although I’ve no one of it to test now.

    Additionaly, I’ve uploaded prebuilts (40 Mb), that were used to compile SDK

    I’ll upload diffs between korg/master and freebsd-port branch later.

    Brave testers are needed

    October 24th, 2009

    Well, USB related code in FreeBSD version of adb was submitted for review and will be pushed to next snapshot, that I will upload, when some problems with Internet connection at home will be resolved (I don’t like GPRS at all…). But meanwhile, anyone interested in testing may check this build of adb only (153 Kb).

    Testing program:

    1. download tarball adb.tar.bz2

    2. tar jxf adb.tar.bz2

    3. plug in your Android device (although you may do it after adb daemon start)

    4. ./adb shell

    5. enjoy (or not enjoy…)

    If you have any errors or problems, I’d like to get feedback.

    Started work on adb

    October 17th, 2009

    Previous versions of FreeBSD port of SDK lacked support of USB in native adb and fastboot on FreeBSD. I’ve wrote a quick and dirty code about half year ago, but it was done without testing on real device. As result, it was not working at all :)

    Now I’ve HTC Hero to test all perverted things I want to test, so I’ve started USB development of related code basing on libusb.

    Recent versions of FreeBSD have this library integrated to base system, and libusb20 API is available as well. However I’ll try to eliminate usage of libusb20 in order to make usb_libusb.c compilable without problems in Linux also.

    I have no much time now due work on PhD, however I expect working code to the end of October.

    PS:

    follow bsdroid on Twitter for news.