Hi Mark,
so it does seem that if the jars are not compiled under Android, the
Android
plug in (if the Eclipse Project Build Automatically is checked)
rejects them from
the apk - in other cases it does not generate the apk at all.
Some of the libs I need are part of the Java's standard libs
(ex.
And one more interesting fact -
if I add the jars as External Jars using Eclipse, building the
workspace takes
a while, eventually it runs out of memory and it only generates the
resources
file (no apk and no dex). If I add the jars as Lib (as I showed in the
previous
posting), the workspace is bu
Just to make this a bit more visual -
the .classpath shows:
?xml version="1.0" encoding="UTF-8"?>
The myLib contains the jars that reside under ROOT/libs in this
particular project.
And finally the .dex archive (and subsequently the .apk file) cont
If jars are not compatible with the Android platform would that
prevent them from
being packaged in the .apk? I checked build class paths etc. and
everything
looks good ...
On Jul 18, 8:19 am, Mark Murphy wrote:
> On Sat, Jul 17, 2010 at 11:45 PM, kypriakos wrote:
> > But older postings and
> >
> :: shrug ::
>
> It works for many other developers, including hundreds of students of
> mine. Since the non-Eclipse portion is pretty bulletproof, and since I
> don't use Eclipse, my guess is that your problems stem from something
> Eclipse-related, perhaps in the way you are putting it in your
On Sun, Jul 18, 2010 at 4:52 PM, kypriakos wrote:
>> Step #1: Put the JAR in libs/
> I did
>> Step #2: If using Eclipse, add it to your build path
> I did
>> Step #3: Code to the JAR's API and build your APK
> I did
>
> Even for the case of the jars that are Android-friendly they don't get
> inclu
Hey Mark,
good points as always -
> There are a multitude of reasons why an existing JAR may not work on Android:
>
> -- It was compiled with Java 1.4.2 or a non-Sun/Oracle Java compiler
> -- It assumes certain classes exist (from, say, JavaSE) that do not
> ship with Android
> -- It uses JNI (a
On Sat, Jul 17, 2010 at 11:45 PM, kypriakos wrote:
> But older postings and
> some
> sources supported that in general external jars may not work under
> Android
There are a multitude of reasons why an existing JAR may not work on Android:
-- It was compiled with Java 1.4.2 or a non-Sun/Oracle J
Really? That would make me feel much better. But older postings and
some
sources supported that in general external jars may not work under
Android
and that their corresponding source should be compiled with its SDK
before
they can be used - which throws reusability out of the window. In any
case,
It seems a little odd that Android is supposedly "open", yet Dalvik is
essentially undocumented.
On Jul 17, 8:13 am, Kostya Vasilyev wrote:
> During compilation, Android tools use standard Java .class format, as
> you found out.
>
> However, during application packaging (I think) they are convert
During compilation, Android tools use standard Java .class format, as
you found out.
However, during application packaging (I think) they are converted into
Dalvik's special format, .dex, which does not use Sun's Java bytecode.
If you list the contents of an .apk file, you will see one .dex f
That's not been my impression, and when I browse an Android class file
with a hex editor it says "CAFEBABE".
On Jul 16, 11:48 pm, kypriakos wrote:
> So it is fair to say = Android bytecode != 3rd party code bytecode
> (particularly
> from IBM or SUN or Axis)? So the reason I am not seeing the lib
So it is fair to say = Android bytecode != 3rd party code bytecode
(particularly
from IBM or SUN or Axis)? So the reason I am not seeing the libraries
(which
otherwise helped me compile my imported app in Eclipse) in the apk
file
is because they are not recognized by the Android platform? Unless I
13 matches
Mail list logo
