Megha (and others),
Again, thank you for your prompt reply.
As to having multiple services in a single .apk, uh, my bad, and my
apologies. I'm sure I saw somewhere that you could only have one
<service> tag in a manifest, but I can't now find that. Oh, well. :-(
I have successfully combined my two applications into a single
project, and after a little twiddling they both seem to be working the
same as when they were separate projects.
That leaves the issue of java helper applications running along side
the emulator.
I agree with your comment that "The judges should be treated as end
users.". But the logical implication of that, at least in my mind, is
that they would be provided with EITHER real Android handsets OR
"vanilla" emulators that accurately emulate real Android handsets. (By
"vanilla" I mean with no command line options, no configuration
alterations made, e.g., with adb, no helper applications, etc.)
I don't think anyone could argue withe the statement that NEITHER of
those things can be done at this time, at least in a way that would
satisfy the requirements of applications such as the ones I have
developed.
To the best of my knowledge real Android handsets don't yet exist (or
are not available in sufficient quantities, or ....).
The emulator and SDK have known and, in most cases, well documented
deficiencies, bugs, etc., that we as application developers have to
circumvent in one way or another to best show off our exciting and
compelling applications, which as I understand it was what the ADC was
all about: develop exciting and compelling applications to jump start
the Android platform.
I believe (hope?) I have created two such applications, but they need
to circumvent emulator and SDK deficiencies to work to their full
capabilities. In particular, the deficiencies in the "vanilla"
emulator / SDK that I have had to work around are:
* applications running under the "vanilla" emulator cannot receive
TCP connections and cannot send UDP datagrams to or receive them from
the world outside of the emulator, they can only initiate TCP
connections;
* applications running under the "vanilla" emulator cannot
determine the IP address of the emulator (actually the IP address of
the host on which the emulator is running; and
* applications running under the "vanilla" emulator cannot get the
caller ID for voice calls to the emulated handset.
I reported the first problem very early, and received no reply other
than the issue was accepted to be fixed in the future. Later, folk in
the discussion group reported that if you open up emulator ports via
the emulator console you can, at least to a limited extent, receive
TCP connections and send and receive UDP datagrams.
To the best of my knowledge, even when you open up ports via the
emulator console, you still cannot get the accurate IP address of the
host on which the emulator is running.
The issue of making call ID available I believe has been accepted as
an issue to be fixed in the future. (Megha: I think it was you that
officially created this as an issue, for which I thank you. :-) )
In light of the above and desiring to show off my applications to
their best, I felt I was left with no option but to create helper
applications that run along side the emulator. The helper applications
(One for each of my two ADC submitted Android applications.) are
written in pure java and contain no application logic, only
circumventions of emulator / SDK deficiencies. If it's important to
anyone to verify that claim, I will provide the source for the helper
applications to them.).
One helper application simply accepts TCP connections from the outside
world: the Android application in the emulator makes a TCP connection
to it on start up, and when another handset / emulator / host makes a
connection to the helper application from the outside world, the
helper application simply copies data between the two connections. No
application logic there that I can see, but the handset application
wouldn't work in a "vanilla" emulator without the helper application.
The second helper application is similar but works on UDP datagrams.
Again, the Android application in the emulator makes a TCP connection
to it, then the helper application opens a UDP socket can copies
datagrams back and forth between the TCP connection to the application
in the emulator and the outside world.
That gets me around the first issue listed above.
The second issue is circumvented by having the UDP helper application
have source / destination IP addresses of the datagrams added to the
TCP messages. That was necessary so that the UDP helper would know
where to send the datagram. But it also allows the application in the
emulator to learn the emulator's host IP address: it is the
destination address of the datagram, which the UDP helper application
has included in the TCP message.
The third issue was circumvented by assuming that the caller ID for
incoming calls would be in an "extra" on the broadcast ANSWER_ACTION
intent that announces the arrival of an incoming call (That may not be
the way that caller ID is eventually officially implemented, and if
it's not I'll be among the first to change my applications to
conform.). I have included in one of my applications a little activity
that prompts for the phone number to which a call should be placed,
then uses the UDP helper application to send a datagram with the
calling and called phone numbers to the handset emulator that "has"
the called number, where it is turned into a ANSWER_ACTION intent and
broadcast within the emulated handset and / or used to trigger another
little activity that simply displays the caller ID in case no other
application consumed the ANSWER_ACTION broadcast event. How does the
originating emulated handset get the IP address of the emulated
handset to receive the call, just knowing its phone number? Ah, you
see, that's what makes this application so exciting and
compelling! :-) But I can't demonstrate that without the helper
application.
To complete the picture here, my other exciting and compelling
application is a peer-to-peer application that provides a unique
service for the users of two Android handsets. One way in which this
application establishes a connection between two handsets to provide
that service is to respond to incoming voice calls and use the caller
ID to establish a connection back to the originating handset. For now
it uses a TCP connection directly between the handsets (It will
eventually use UDP for a number of arcane reasons.) and again it can't
do that with the "vanilla" emulator, it needs a helper.
With 20/20 hindsight (Ain't it great!), I might have been able to do
all of this (Except to find the IP address of the host running the
emulator: that's still a gotcha) by opening up ports via the
emulator's console. At the time I made the decision to go with helper
applications, I had no confidence that opening up emulator ports would
work, and I didn't really have the time to try that when I know I
could make it work using a helper application. (Risk management in an
uncertain world under tight deadlines in practice! :-) )
So now I'm stuck having to have two little pure java helper
applications running alongside the emulator in order to really show
off my applications. The two helper applications are each started with
a single command, and in the documentation accompanying the
application submissions, I provide full details on how to enter those
two commands. And it's really simple: open a command prompt, enter two
commands, end of story.
If I had gone the "open emulator ports" route, the commands necessary
to do that would have been much more involved and less likely to be
entered correctly by anyone other than really experience emulator
users.
In light of all of this, I am asking and hoping that the ADC team will
allow these two helper applications to be used in evaluating my
submitted applications. In an ideal world, they wouldn't be necessary.
And certainly the need for them will be eliminated before we "go
production".
I will submit my two applications (twice, one for each application) as
a combined .apk file so you only need to do one install to use both
applications, include the helper applications and complete
documentation on the applications (Including instructions on how to
start the helper applications.) in an accompanying .zip, file, and
hope for the best.
At this point, I don't see that I've been left with any alternative.
But if someone does see another alternative, let me know: there's
still 56 hours to the submission deadline! :-)
Again, thank you everyone for your past, present and future attention
to these issues. And good luck to all in the ADC.
Jim Renkel
P.S.: in addition to this reply, I will start a new thread with a copy
of this message so that it gets the attention I think it deserves.
On Apr 12, 1:21 am, "Megha Joshi" <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 11, 2008 at 7:49 PM, jim.renkel <[EMAIL PROTECTED]> wrote:
>
> > After deleting the emulator's .img file, i.e., starting with a clean
> > slate, was able to get the adb installs to work.
>
> > Previously, I was doing them from the bin folder of the project and
> > using the command "adb install HereIAm.apk". This time I did "adb
> > install bin\HereIAm.apk" from the project folder, rather than the bin
> > folder of the project. Maybe that makes the difference, I don't know.
> > I least I can now make adb install work in some way.
>
> > That still leaves the questions:
> > * Can you have multiple adb installs because ya can't combine the
> > applications because they both have services; and
>
> You can have more than one service in a single .apk, you may want to look at
> the ApiDemos for example.
>
>
>
> > * Can ya have little java applications running alongside the
> > emulators that are used to overcome deficiencies, restrictions, bugs,
> > etc. in the emulator and SDK.
>
> As we mentioned before judges are not expected to run applications from web
> or desktop, just as the users are not expected to do that. The judges should
> be treated as end users. As for the bugs with SDK, you should mention those
> in the documentation, and your application will not be negetively marked
> because of those.
>
>
>
> > I'm hoping the answer to both of these questions is "yes". If either
> > of them is "no", my applications just won't be able to do much.
>
> > Megha, could you or somebody from google answer these questions for
> > me?
>
> > Again, thanks in advance for all help, past, present, and future.
>
> > Jim Renkel
>
> > On Apr 11, 9:11 pm, "jim.renkel" <[EMAIL PROTECTED]> wrote:
> > > Diego and Megha,
>
> > > Thank you for the prompt replies.
>
> > > As I mentioned, before I did the adb install, I deleted the
> > > applications with the package browser dev tool. The manifests do not
> > > have any conflicting package, class, or activity names. They had both
> > > been previously installed from eclipse with no problems in exactly the
> > > form that I am trying to install them with adb install.
>
> > > As I write this, I am waiting for the emulator to restart, having
> > > deleted its .img file. I will then try installing the applications
> > > with adb install and see what happens.
>
> > > As to combining them into a single application with a single manifest,
> > > I don't think this can be done because both applications have services
> > > and the documentation says you can only have one service declared in
> > > the manifest. I'll give this a try, but I think it's a non-starter.
>
> > > On the philosophical side, what is the problem with having to install
> > > two (or more) applications into the emulator for the judges, instead
> > > of just one?
>
> > > And this just occurred to me. Both applications include little java
> > > applications that run "alongside" the emulator. They overcome
> > > restrictions, deficiencies, bugs, etc. in the emulator and SDK in the
> > > area of receiving TCP connections and using UDP at all; all they do it
> > > transform TCP messages to and from the applications inside the
> > > emulator to TCP and UDP sockets and datagrams that don't work as they
> > > should inside the emulator but do work correctly in stand alone java
> > > applications; they do not contain any application logic. The
> > > applications in the emulator communicate with them via TCP
> > > connections. The applications can do some things, but nothing really
> > > interesting, without the helpers. Is this going to be a problem? All
> > > that needs to be done is to execute "java -jar ..." commands from a
> > > command line in the directory where the files from the submission .zip
> > > file have been extracted to start them up; they take of themselves
> > > after that. No special configuration of the emulators is required;
> > > this was one factor in deciding to go this way.
>
> > > Thank you for all your help with this so far, and thank you in advance
> > > for future help.
>
> > > Jim Renkel
>
> > > On Apr 11, 6:55 pm, "Megha Joshi" <[EMAIL PROTECTED]> wrote:
>
> > > > On Fri, Apr 11, 2008 at 4:18 PM, jim.renkel <[EMAIL PROTECTED]> wrote:
>
> > > > > Megha,
>
> > > > > Urgent help needed here!!!
>
> > > > > I too need to have multiple (In my case only 2) .apk's installed
> > into
> > > > > the emulator. Before I tried to bundle them together, I thought I
> > > > > should try installing just one of them with "adb install".
>
> > > > > When I try to do that, I get:
>
> > > > > DEBUG/PackageManager(510): Adding package
> > > > > name.renkel.james.HereIAm
> > > > > WARN/PackageManager(510):
> > > > > *************************************************
> > > > > WARN/PackageManager(510): Application package
> > > > > name.renkel.james.HereIAm already installed. Skipping duplicate.
> > > > > WARN/PackageManager(510):
> > > > > *************************************************
>
> > > > As Diego mentioned, this is because the package was already present on
> > the
> > > > emulator, might be because you intalled the application earlier or
> > because
> > > > you have duplicate package name across multiple applications.
>
> > > > > OK, so I use the dev tool package browser to remove the package, and
> > > > > try the adb install again. That seems to work, but when I try to
> > > > > execute the application on the emulator, I get
>
> > > > > INFO/ActivityThread(2211): Loading code package
> > > > > name.renkel.james.HereIAm (in name.renkel.james.HereIAm)
> > > > > DEBUG/dalvikvm(2211): Exception Ljava/lang/RuntimeException; from
> > > > > ActivityThread.java:1699 not caught locally
> > > > > DEBUG/dalvikvm(2211): Exception Ljava/lang/RuntimeException; from
> > > > > ZygoteInit.java:1553 not caught locally
> > > > > DEBUG/AndroidRuntime(2211): Shutting down VM
> > > > > WARN/dalvikvm(2211): threadid=3: thread exiting with uncaught
> > > > > exception (group=0x4000fdf8)
> > > > > ERROR/AndroidRuntime(2211): Uncaught handler: thread Main exiting
> > > > > due to uncaught exception
> > > > > ERROR/AndroidRuntime(2211): java.lang.RuntimeException: Unable to
> > > > > instantiate activity
> > > > > ComponentInfo{name.renkel.james.HereIAm/
> > > > > name.renkel.james.HereIAm.HIAactivity}:
>
> > > > > java.lang.ClassNotFoundException:
> > > > > name.renkel.james.HereIAm.HIAactivity in loader
> > > > > [EMAIL PROTECTED]
>
> > > > This might be because the package name.renkel.james.HereIAm which is
> > > > already installed on the emulator does not have an Activity by the
> > name
> > > > HIAactivity. This could be because you have added the HIAactivity
> > later in
> > > > the process, or you have another application with the same package
> > name
> > > > installed already.
>
> > > > > and a whole lot more. OK, so let's get back to a known good
> > > > > environment while I try to figure this out.
>
> > > > > When I go back to eclipse and try and run the application from
> > there,
> > > > > I get the duplicate package messages again, then unable to
> > instantiate
> > > > > activity messages again.
>
> > > > > Then if I use the package browser to again remove the package, and
> > > > > then run the application from eclipse, all seems to be OK.
>
> > > > > So, I'm at least I'm back to where I was before I started all of
> > this.
>
> > > > > But I can't successfully install one, let alone multiple,
> > applications
> > > > > with adb.
>
> > > > > Could you please, on an urgent basis:
>
> > > > > 1. explain in detail how to install an application into the emulator
> > > > > using adb; and
>
> > > > As mentioned in the documentation:
> >http://code.google.com/android/intro/installing.html#otherides
> > > > Run adb install *myproject*/bin/<*appname*>.apk to upload the
> > executable.
> > > > So, for example, to install the Lunar Lander sample, navigate in the
> > command
> > > > line to *<your_sdk_dir>*/sample/LunarLander and type
> > > > ../../tools/adb install bin/LunarLander.ap
>
> > > > > 2. how to package multiple applications together so they can be
> > > > > installed in one step, as is appently required by the "new" and ever
> > > > > evolving ADC submission rules.
>
> > > > If your single submission has multiple .apk files dependent on each
> > other
> > > > you should try to bundle it to a single .apk by moving the resources,
> > > > packages to a single application and combining the AndroidManifest.xml
> > files
> > > > to one AndroidManifest.xml. The thread below has some discussion on
> > this
> > > > issue:
> >http://groups.google.com/group/android-developers/browse_thread/threa...
>
> > > > > I realize this is late in the game, as it were, but unless this is
> > > > > explained to me (and I believe many others) and I can successfully
> > do
> > > > > this, my ADC submission won't be able to be installed and evaluated
> > > > > per the "rules" that have, late in the game, been established.
>
> > > > > Sorry, if I sound a little bitter about this, but I think the bugs
> > > > > should have been worked out of the submission process, if you will,
> > > > > much earlier than this, so that as the deadline approached we can
> > > > > concentrate on developing great applications and not have to worry
> > > > > about whether or not all the long and hard work we've put in so far
> > > > > will go to naught.
>
> > > > > Judging from traffic in this discussion group and others, I know I'm
> > > > > not alone in requiring this capability.
>
> > > > > Again, please, please, please, provide help here on an urgent basis.
>
> > > > > Thanks in advance for your attention to this.
>
> > > > Let us know if you face any issues.
>
> > > > Jim Renkel
>
> > > > > On Apr 11, 3:46 pm, "Megha Joshi" <[EMAIL PROTECTED]> wrote:
> > > > > > On Fri, Apr 11, 2008 at 12:09 AM, Vishal <[EMAIL PROTECTED]>
> > > > > wrote:
>
> > > > > > > Hi Dan,
>
> > > > > > > The complete package size is 80 MB, I have tried several times
> > in last
> > > > > > > 12 hrs and unable to make any progress, every time a failure.
>
> > > > > > The upper limit on the size per submission is 10 MB, that might be
> > the
> > > > > > reason
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Android Challenge" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-challenge?hl=en
-~----------~----~----~----~------~----~------~--~---
