Easy question: armeabi and armeabi-v7a

[Jim Graham]

Simply put, my app has its minimum-SDK set to API level 8 (Froyo).

With that in mind, I have two questions:

1) Is armeabi-v7a backwards compatible with armeabi?

2) If not, do any semi-current (Froyo and up) devices require the older
armeabi ?

In other words, do I really need to include armeabi at all, or do I need
both it and armeabi-v7a?

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) | "Now what *you* need is a proper pint of
spook...@gmail.com | porter poured in a proper pewter porter
< Running Mac OS X Lion > | pot.."
ICBM / Hurricane: | --Peter Dalgaard in alt.sysadmin.recovery
30.44406N 86.59909W |

Android Apps Listing at http://www.jstrack.org/barcodes.html

[李紫阳]

By default ,the NDK will generate machline code for the 'armeabi' ABI. You can however add the following line to your Application.mk to generare ARMv7-a compatible machine code instead : 

                                            APP_ABI := armeabi-v7a

It is also possible to build machine code for *two* distinct ABIs by using :

                                            APP_ABI := armeabi armeabi-v7a

2012/7/12 Jim Graham <spook...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Jim Graham]

On Thu, Jul 12, 2012 at 09:06:03AM +0800, ?????? wrote:
> By default ,the NDK will generate machline code for the 'armeabi' ABI.
> You can however add the following line to your Application.mk to
> generare ARMv7-a compatible machine code instead : APP_ABI :=
> armeabi-v7a
>
> It is also possible to build machine code for *two* distinct ABIs by
> using : APP_ABI := armeabi armeabi-v7a

Yes, I know that (in fact, I think I read that, word for word, in a post
on Stack Overflow...not sure). I am currently building both...but I'm
wondering whether or not I NEED both. That's why I asked if I need both.

Along the same lines, do any modern Android devices still use x86? I
didn't ask about it because I thought OpenCV didn't support it (I just
found out it does, so it belongs in the same question).

If there's a chart somewhere, similar to the API level percentage chart,
a link to that would be the best answer.

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >
spook...@gmail.com ICBM/Hurr.: 30.44406N 86.59909W

Seen in alt.sysadmin.recovery: "Priceless; that's better than telling
him to use the Read Manual command with the Real Fast option."

[Latimerius]

On Thu, Jul 12, 2012 at 3:14 AM, Jim Graham <spook...@gmail.com> wrote:
> Along the same lines, do any modern Android devices still use x86?

BTW I'm not quite sure what you mean by "still" here. As far as I
know, there have not been any "official" x86-based devices running
Android yet (various enthusiast porting efforts aside). There has
been continual talk about bringing Android to Intel platforms, as a
random example see here:

http://androidandme.com/2011/09/news/intel-and-google-announce-android-x86-optimization/

I haven't been following this very closely so I might be
misinterpreting something, also it could be an x86 Android device was
already released earlier this year and I missed it, but overall my
impression reading the new has been that Android/x86 is a future
development, not a thing of the past.

[Jim Graham]

On Thu, Jul 12, 2012 at 09:29:03AM +0200, Latimerius wrote:
> On Thu, Jul 12, 2012 at 3:14 AM, Jim Graham <spook...@gmail.com> wrote:
> > Along the same lines, do any modern Android devices still use x86?
>
> BTW I'm not quite sure what you mean by "still" here. As far as I
> know, there have not been any "official" x86-based devices running
> Android yet (various enthusiast porting efforts aside).

Ah. I guess I had that one backwards (future, not past, as I was
thinking).

But what about armeabi and armeabi-v7a, then? Is it enough to provide
armeabi-v7a? Or do I need to build using both?

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) | "Now what *you* need is a proper pint of
spook...@gmail.com | porter poured in a proper pewter porter
< Running Mac OS X Lion > | pot.."
ICBM / Hurricane: | --Peter Dalgaard in alt.sysadmin.recovery
30.44406N 86.59909W |

[Latimerius]

On Thu, Jul 12, 2012 at 11:59 AM, Jim Graham <spook...@gmail.com> wrote:
> But what about armeabi and armeabi-v7a, then? Is it enough to provide
> armeabi-v7a? Or do I need to build using both?

No idea about that, unfortunately. I don't have production experience
with NDK yet, plus ARM nomenclature confuses the hell out of me. ;-)

[Nalin Savara]

hi...
@bro Latimerius:

yes there are already intel atom based android devices... like Lava
Mobile's Xolo superphone that ships with Android 2.3.3 can be upgraded
to ICS 4.0.3
heavily marketted and advertized here... It has specs comparable to
sgs-2 but with a zippier processor...

secondly... In my experience, if one can compile code for arm abi =
arm5... Then that's typically good enough... From 2.3.3 till ics
4.0.2...

Unless you handcode arm-assembly and use some instruction avail in
arm7a and machine instruc/feature not in arm5.... (highly unlikely)

Hope that helps...

Regards,
Nalin

[Jim Graham]

On Thu, Jul 12, 2012 at 06:03:28PM +0530, Nalin Savara wrote:

> yes there are already intel atom based android devices... like Lava
> Mobile's Xolo superphone that ships with Android 2.3.3 can be upgraded
> to ICS 4.0.3

And I just looked at the specs... 8 MP rear camera---definitely one that
a user might want to combine with a more serious camera app. My apk is
getting bigger by the day.... :-(

> secondly... In my experience, if one can compile code for arm abi =
> arm5... Then that's typically good enough... From 2.3.3 till ics
> 4.0.2...
>
> Unless you handcode arm-assembly and use some instruction avail in
> arm7a and machine instruc/feature not in arm5.... (highly unlikely)

I read that it has much more power for handling math operations---like
those in image processing. Does this also require special machine
language coding, or is it just "there" and active on its own? The answer
to this determines whether or not I need to include it.....

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >

spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W

"sigh, once upon a time T-1 was fast...."
--seen in alt.sysadmin.net-abuse.email

[Tony Houghton]

On Wed, 11 Jul 2012 20:14:58 -0500
Jim Graham <spook...@gmail.com> wrote:

> Along the same lines, do any modern Android devices still use x86? I
> didn't ask about it because I thought OpenCV didn't support it (I just
> found out it does, so it belongs in the same question).

Yes, there's the recently released Orange San Diego phone. The specs and
price look competitive so it might get quite popular.

[Jim Graham]

Yeah...looks like I'm at LEAST going to have to support two, if not all
three CPU types. I'm searching for the page(s) in the developers guide
showing how to do that with separate APKs in the Market, so there's no
need for one HUGE APK....

Still wondering whether I need armeabi, armeabi-v7a, or both (doing image
processing via JNI using OpenCV, and don't want to leave out any devices
that are more than a minute portion of the Market, which right now, means
Android versions prior to Froyo, which I seem to recall being less than
1% these days).

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >

spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W

Do not look into laser with remaining eye.

[Tony Houghton]

On Thu, 12 Jul 2012 08:09:30 -0500

Jim Graham <spook...@gmail.com> wrote:

> On Thu, Jul 12, 2012 at 04:02:33PM +0300, Tony Houghton wrote:
> > On Wed, 11 Jul 2012 20:14:58 -0500
> > Jim Graham <spook...@gmail.com> wrote:
> >
> > > Along the same lines, do any modern Android devices still use x86? I
> > > didn't ask about it because I thought OpenCV didn't support it (I just
> > > found out it does, so it belongs in the same question).
> >
> > Yes, there's the recently released Orange San Diego phone. The specs and
> > price look competitive so it might get quite popular.
>
> Yeah...looks like I'm at LEAST going to have to support two, if not all
> three CPU types. I'm searching for the page(s) in the developers guide
> showing how to do that with separate APKs in the Market, so there's no
> need for one HUGE APK....
>
> Still wondering whether I need armeabi, armeabi-v7a, or both (doing image
> processing via JNI using OpenCV, and don't want to leave out any devices
> that are more than a minute portion of the Market, which right now, means
> Android versions prior to Froyo, which I seem to recall being less than
> 1% these days).

I think modern ARMs are all backwards compatible, so if you support the
lowest one it will run on all the newer ones too. And if your app works
OK on older ones it probably doesn't need the small performance boost of
v7a on newer ones. That said, if you're going to have to support
multiple CPUs anyway (because of x86) you might as well support more
than one type of ARM.

Your question about doing this with separate APKs is interesting, but
I'm afraid I don't know the answer. But you might like to do something
like VPlayer. When you install the main app it automatically tells you
which version of the codec pack you need, but I can't remember whether
it also automatically installs it. Can an app install another app? If so
you could write an installer app which chooses the correct version of
the "real" app, but then users would have 2 apps probably taking up more
space than one with multiple ABIs, unless the installer can uninstall
itself after it's installed the main app.

[Latimerius]

On Thu, Jul 12, 2012 at 3:34 PM, Tony Houghton <h...@realh.co.uk> wrote:
> I think modern ARMs are all backwards compatible, so if you support the
> lowest one it will run on all the newer ones too. And if your app works
> OK on older ones it probably doesn't need the small performance boost of
> v7a on newer ones.

Well, one of the differences between v7a and non-v7a is that v7a
accelerates floating-point operations in hardware whereas non-v7a
implements them as software subroutines. I can imagine this can mean
an orders of magnitude difference in performance for an image
processing app, I wouldn't expect the performance boost to be small
there.

Of course, Jim should be in the position (if he has a v7a device
available) to link his code with armeabi and armeabi-v7a libs and
profile the result in both cases to see how big the boost is in his
typical use cases.

As armeabi-v7a code is documented not to run on armeabi devices, the
real question here is how many devices are still in use that only
support armeabi. I'm afraid no-one might know the answer.

> Your question about doing this with separate APKs is interesting, but
> I'm afraid I don't know the answer.

According to the multiple-APK feature documentation
(http://developer.android.com/training/multiple-apks/index.html) you
probably are not able to make Market serve different APKs based on ARM
version (but I have no experience of my own with this).

[Jim Graham]

On Thu, Jul 12, 2012 at 04:34:46PM +0300, Tony Houghton wrote:
> On Thu, 12 Jul 2012 08:09:30 -0500
> Jim Graham <spook...@gmail.com> wrote:
> >
> > Yeah...looks like I'm at LEAST going to have to support two, if not all
> > three CPU types.
> >

> > Still wondering whether I need armeabi, armeabi-v7a, or both (doing image
> > processing via JNI using OpenCV, and don't want to leave out any devices

> I think modern ARMs are all backwards compatible, so if you support the
> lowest one it will run on all the newer ones too. And if your app works
> OK on older ones it probably doesn't need the small performance boost of
> v7a on newer ones.

Strange. The post I read comparing the two suggested that, when doing a
lot of math (e.g., image processing), the difference was much more
significant. I suppose I could do a test with my tablet, and see if I
notice a big enough difference to see it across two different installs,
etc.

> That said, if you're going to have to support
> multiple CPUs anyway (because of x86) you might as well support more
> than one type of ARM.

The issue here is the size of the APK. My camera app, without the NDK
and one small subset of OpenCV went from about 467 kB to 4.8 MB after
adding armeabi for my cvBlend.cpp and libopencv_java.so. When I added
both armeabi and armeabi-v7a, it grew to nearly 10 MB. And I'm not
finished adding OpenCV stuff or C++ code to drive the various image
processing types. I don't want to leave out any part of the Market
that's more than a minute percentage, or that has higher-resolution
rear-facing cameras (i.e., someone more likely to be interested in a
camera that does more photography, family photos, etc., types stuff).
In other words, it's very important to me that I get this right. :-)

I was just looking at how BS Player does it...multiple apps---one for
each CPU type; not multiple APKs as one app, as the Market (I hate
calling it the "play store") doesn't support filters based on CPU
type (IMO, that's a mistake, but then, they don't listen to my
opinion <grin>). If you download the wrong version , it tells you
that you need version xyz instead.

The problem is, my app will be a paid app, and if the user doesn't get
their refund for the wrong version quickly enough.... That would NOT
be a Good Thing(tm).

> Can an app install another app?

Yes and no. The Market (errr, play) app is an app. It's an app that
has priveleges that normal apps don't (I'm not sure if that means it
runs as root, or just as a system app...not really important, though).
SocIo Mall's app can also install other apps, so there is a way to get
that ability. This coems up in the android-developers list frequently,
usually someone wanting to install another app without the user knowing
(i.e., spyware). As I recall, the answer is generally NO.

An app can definitely install modules, but does include support for
shared libraries? I have no idea, but if so, that might be the answer
if the APK gets too big. I suppose I should probably worry about this
if/when it does instead of worrying about the potential issue now.
But that's me...I like knowing the future whenever I can. :-)

[Shervin Emami]

Most apps support both armeabi and armeabi-v7a by putting them both in the "Application.mk" file, and Android will take care of using the correct one for different apps. eg: If someone has an old ARM v5 or v6 device then if they look for your app in the App Store then it should only show it to them if your app supports armeabi (and perhaps others). So you don't need to do anything more complex besides that. And to support the new x86 Android devices that will be gradually released, you can also add x86 to the list and it will be done automatically for you. Like you've noticed, each extra ABI you support will make your APK bigger. If you use OpenCV, then your APK will get much bigger for each ABI you use, unless if you use the new "OpenCV Manager" that was released last week, that will ask the user to install the correct OpenCV for their device through the App Store. That way, you can support many ABIs and still have a small APK, and the user only needs to download OpenCV for their ABI, not all ABIs.

So either way, you don't need to re-invent the wheel to dynamically load different APKs just to support new and old devices. People have taken care of most of those details for you.

PS: Your app is likely to run faster with armeabi-v7a than armeabi, but there are still many factors to whether it will actually run fast, such as the CPU of the device. If the device is using a Cortex-A8 CPU (an armeabi-v7a CPU popular among many of the fairly decent smart-phones) then it will be much faster at floating-point calcs than older ARM11 (armeabi) devices, but if the device has a Cortex-A9 CPU (also armeabi-v7a but only used in the top smart-phones and multi-core devices), then it will be much faster even than Cortex-A8, perhaps even 10x faster!

-Shervin.