---------- Forwarded message ----------
From: Nitesh Bharadwaj <[email protected]>
Date: Wed, Aug 28, 2013 at 12:48 AM
Subject: Re: [freenet-dev] Android Support for Darknet Connections Update #4
To: Matthew Toseland <[email protected]>





On Tue, Aug 27, 2013 at 10:47 PM, Matthew Toseland <[email protected]
> wrote:

> On Sunday 25 Aug 2013 15:52:55 Nitesh Bharadwaj wrote:
> > Its been long since last update.
> > Here I present a pre-alpha of the android application along with the
> > changes required in fred. It presently supports bluetooth and wifi-direct
> > based reference exchanges.
> >
> > The code for the server on home node is more or less unchanged from the
> > previous update and the main changes are on the android part. Some of
> them
> > pertain to
> >
> > UI and code structure: The UI had to be changed completely in order to
> > support old versions of android. Presently, the main thread serves as the
> > UIThread and it has a handler. Any other thread which wishes to change
> the
> > UI sends a message to this handler and the UI is updated. There are some
> > concurrency issues left out but these are rare cases (for example, a new
> > node - other than homenode is detected on our LAN  while we are
> exchanging
> > noderefs with a friend) and some work is left on this front. Other than
> > these, UI issues are fixed.
> >
> > Bluetooth: I had to face various compatibility issues, especially on old
> > android devices (<= android 2.1-Froyo). These devices cannot connect with
> > newer devices in the way they are meant to  i.e. as described is Android
> > SDK documentation. Following suit from
> >
> http://stackoverflow.com/questions/3397071/service-discovery-failed-exception-using-bluetooth-on-android
> ,
> > I had to use java reflections to grab a bluetooth channel and force
> > connect. Note that this isn't so insecure as it sounds because any
> > bluetooth connection requires initial pairing. Alternatively, we can only
> > support devices > android 2.1.
> >
> > General Incompatibility Issues: For example, android ships Bouncy Castle
> in
> > its packages but doesn't pack any one version completely.  We cannot
> build
> > along with the official bcprov...jar because it gives rise to class
> > conflicts with pre-shipped versions. The most used solution is to use
> > spongy castle (modified bouncy castle) but I used jarjar to rename the
> > classes and ended doing the same as what spongy castle does.
> >
> > Several such compatibility issues cropped up and delayed my project and I
> > am determined to keep it up and complete in time frame
> >
> > To be implemented:
> > #1 QR based exchange -  This should be for mobiles which couldn't use any
> > other methods because of lack of hardware / any issues
> > #2 Exchange over internet :
> > Some discussion is needed in this respect but in general, public keys
> (DH)
> > are exchanged by QR and the actual noderef is sent over internet
> (email?).
> > This would be received by other mobile/ node(?)
> >
> > To try out the app:
> > Build using Eclipse + Android SDK or ant + Android SDK from source
> > https://github.com/NiteshBharadwaj/Freenet or alternatively, could be
> > downloaded form
> > http://www.mediafire.com/download/8h6889jtqpott5v/Freenet.apk
> >
> > Also, the modified fred and modified mdns-plugin need to be forked and
> > built from https://github.com/freenet/fred-staging and
> > https://github.com/NiteshBharadwaj/plugin-MDNSDiscovery-official
>
> It's good that it's working!
>
> How old is Android 2.1?
>

It was a mistake that I mentioned 2.1 as Froyo. It is 2.2 and it was
released in 2010.

>
> NFC is worth considering IMHO if you have time. Although maybe BT/wifi
> direct will use that for setting up a pairing? How much manual work is
> involved in setting up the bluetooth pairing?


I'll try to look into NFC.

It takes much work to pair BT devices, discovery of new devices takes > 12
seconds. After that users may have to put in a pin or click a button on
both devices.

As per my current and local knowledge:

Android <= 2.2  - Generally updated to Android 2.3. Only used when the
manufacturer doesn't provide an update. Especially, this is the case with
inexpensive mobiles from local/Chinese manufacturers. Usually accompanied
with a bad camera.

So, bluetooth, inspite of drawbacks, bails out in this case.

Android  2.3<= v < 4
Some have good camera (I've observed that scanning a QR of whole noderef
works fine with a 5Mp camera)
Bluetooth more or less good with avg discovery time of 12 seconds. Force
acquiring bt channel not necessary except for some rogue HTC devices.
Some have NFC - can remove the delay in BT discovery

Android 4 < v < 4.2
Most have Wifi-Direct, BT and NFC and optionally a good cam. Wifi-Direct
alone suffices our requirement

Android >= 4.2
Use android beam/ wifi direct depending on hardware, user choice
Beam (NFC+BT inbuilt protocol) is where I see some hope.
This serves another purpose that we can beam an invite. If the other device
has our app, it will be opened. Otherwise, it will be redirected to
marketplace


> We did talk about e.g. using the QR code to exchange a key to set up the
> encrypted BT pairing?


I don't think android allows this kind of pairing. Also, pairing itself
isn't as tedious as discovering a new bluetooth device. If we initiate a
connection to a bt device (a known mac address) android automatically pops
up pairing dialog box if the devices aren't previously paired

Is the user interface complicated because of justified paranoia about
> Bluetooth? How often are we going to not have wifi direct *and* not have
> bluetooth?


This shouldn't ever be the case except in situations like a subsidized 20
dollar tablet http://akashtablet.com/. This device also has a VGA camera
which can't properly scan normal QR codes, let alone noderefs. Point is,
its very rare.

Exchanging data between the 2 phones over the internet would probably have
> to use email because they are of course NATed ...
>
> I will defer to nextgens on this stuff mostly. I don't have time to review
> it at the moment.
>

Thanks
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to