I would like to publish my app on the Android store but I can not get my app to work in the emulator. I cannot figure out why I cannot run my app when so many have published with the same tools as me in the past.
I have downloaded the lastest Android SDK and installed all the API's. There are alot of 2.3.3 devices and my app supposedly supports as far back and API level 3 so I am assuming my app should be working on API level 10. However my app complains that it has been built for ARM5TE and that the device supports ARM5T.
I cannot figure out what this implies and I am able to build with ARM5T but have no idea if that would then mean my app would not work on ARM5TE. I know that most devices are ARM based but I have no idea how many are ARM5TE and ARM5T. I wanted to support the 90% of devices that use the app store that support open GL 2.0.
To improve the ARM architecture for digital signal processing and multimedia applications, DSP instructions were added to the set.[30] These are signified by an "E" in the name of the ARMv5TE and ARMv5TEJ architectures. E-variants also imply T,D,M and I.
The new instructions are common in digital signal processor architectures. They include variations on signed multiply–accumulate, saturated add and subtract, and count leading zeros.
(source)
Most Android phones released in the last couple of years are based on ARMv7-A, which also supports these DSP instructions.
Related
Is it expected (or what is the likelihood) that newly produced Android devices to not have GLES 3.2 support? We're developing children apps so we're trying to see what are the odds we get new devices on the market in the future that can cause us problems...
What we need is floating point render textures in unity.
Google publish data here (googling 'android distribution dashboard' will find it in case the link goes stale)
Currently, 78.61% of Google Play users are on devices that support GLES 3.2.
Going forward, I'd say it's a certainty that some newly produced Android won't have 3.2 support, but I think they'll be relatively rare devices and aimed at the cheaper end of the market.
In continuation with this question. I am asking this question.
I installed Android Studio. I installed Unity 3D. I followed tutorials of Java-Android Studio and Unity. Nothing worked well because of the reason that they need the latest version of ARCore and neither my mobile nor emulator is compatible with it. I am exhausted searching for alternatives.
I didn't find any tutorial or guidance related to developing Augmented Reality Android apps. Please suggest me a reference that works on Ubuntu system without the need of the physical mobile, but with an emulator, if possible.
Note: Please provide a reference that is relatively easy to test small app initially so that I can proceed forward. I am saying this because of the reason that I am working from almost 3 months but didn't run a small AR app either in the emulator or in my mobile (Redmi Note - 4).
You should check 8thWall. It runs on almost all phones and it has SLAM as well. You can not use it with emulator but it has an application called XR Remote in which you can test your code without building for Android or iOS. Minimum requirement for Android is Android Kitkat (4.4) or higher and for iOS Minimum iOS 7.0 or later is required.
As the owner of the question stated 8thWall can not be used with Linux. As an alternative [ARToolKit] can be used. It is an open source AR framework. For more details you can refer here and here
I'm starting to broad my developer skills also to the Android development.
I installed all the tools and configurations and every thing seem great, As a default settings I install the 3.2 SDK, but there is not too much docs on that one, mode of what is out there is on the 2.x SDKs.
Is it like IOS, does android have a good backward computability? Can I stay with the 3.x and count on it (with the features that are in the 2.x SDKs) to work on 2.x phones? What are the common version in the Android devices this days? I have lots of newbie develop questions like that, as i want to start from a good starting point and there are lots of materials and tutorials over the web that are not up to date.
Also, does any one know about a good site for this kind of Q&A?
Thank you,
Erez
As of July 5th the version with the largest market share (59.4%) is 2.2 (API Level 8) as shown here
http://developer.android.com/resources/dashboard/platform-versions.html so Consequently I would recommend using that as a starting point unless you are solely focusing on the new honeycomb tablets (<1% market share).
As for backward compatibility, android is completely backward compatible for the most part. Unless of course you use a new feature that is only available starting with a certain API level. Google's Android market is good about only allowing apps that will run on a certain API being visible to that phones user. This is enforced by the API level as recorded in the manifest file that is created with every Android app and set by the developer.
To help you with the API level, the SDK docs show what API a feature/object started with in the upper left hand corner. You can also view the specific changes in each platform and it's corresponding API level at http://developer.android.com/sdk/index.html.
As for a good website to get started I would recommend the developer site at developer.android.com and this website of course. Also the book Android Wireless Application Development by Shane Conder and Lauren Darcey (2 ed) Is very good. (I am not connected with the book just currently reading it). Make sure you get the latest edition.
Hope this helps,
George
Above is good info, but it would be advisable to develop for 2.1 and up at the moment, considering as of this answer's writing, 2.1 makes up 17.5% of the market and 2.2 makes up 59.4% of the market.
http://developer.android.com/resources/dashboard/platform-versions.html
OP should also be advised that version 3.x is specifically for tablets, so that may not be the best choice for a starting developer. My advice is to go with 2.1. Most of the documentation is up to date with that, and you won't have access to things you don't need yet (fragments, tablet-specific things)
Hope this helps!
You can read about application forward and backward compatibility in the docs.
Generally apps are forwards compatible but not backward compatible - new APIs introduced in one version are not available in an older version.
This pie chart shows distribution of devices accessing the Android Market and based on this I would try to target devices using 2.1 or newer to cover most of your users.
Your decision should be based on whether you need a feature introduced in a specific version. For example, if you want to add NFC to your app, you'll need Android 2.3.3 or newer, but otherwise there's no reason to exclude older devices.
I recommend learning about Fragments and using the compatibility package to use them on targets below 3.0. This will make it easier to reuse view elements on both tablet and phone devices. Note that if you only intend to develop for phones, 2.3.4 is the latest phone version of Android at the time of writing. Later this year, 3.0 for tablets will merge with the phone version to provide a unified OS version as with iOS.
Android 3.2 is just released publicly on friday, July 15th. You can start-off with Android 2.3.3 and 3.2 installation and development.
Android applications are mostly forward compatible. (But not always)
The best place to find all your answers is developer.android.com
I'm trying to build an Augmented Reality application for androids. I just want it to show some 3d models when it recognizes my different markers.
I used this excellent SDK, https://ar.qualcomm.at/qdevnet/sdk and followed the steps, but unfortunately when I created the application and ran it on my android, it showed a message "Your device is not supported". That's probably because that guide is for 2.1 androids, and mine is 2.2
Is there any way to "convert" it? I just want to make it play on my phone.
Is there any way to "convert" it? I just want to make it play on my phone.
Not that I know of. The QCAR SDK actually checks for device compatibility based on explicit conditions (e.g. a snapdragon processor) and fails to initialize if the device is not supported. There's a list of supported devices available on their dev forum - https://ar.qualcomm.at/qdevnet/forums
Most Android (and iOS) devices are now supported by QCAR SDK.
I have run my android app against the new build target provided by the add-on mentioned here. This appears to be working correctly in the emulator, but now I am very unsure as to the implications of using this build target when delivering an app to the marketplace.
It would appear that I have to use this build target to get the emulator to work. Is this true of the device in general? (i.e.) could I build against the standard android/google APIs and have it run correctly on the actual Galaxy Tab?
If I deploy an app with this build target to the Android market, will this adversely affect other (smaller screen) devices that I already run on? (I.e. is the galaxy tab "special sauce" a superset of Android functionality? I see grumbles about the Google APIs for maps not working in it, etc.)
Will i have to have two versions of my app in the market? One for "standard" devices and one for "large" screen devices? One for the Galaxy Tab specifically?
When Android Tablet vNext (whatever that may be) comes out and has its own custom add-on and build target, will I have to clone my repository and publish/maintain a device specific version of that (presuming that any add-on special sauce for the galaxy tab will not be in vNext's add on and will not be "compatible")
What I am driving at is that I can't find reliable documentation on how an add-on like this will affect the fragmentation of my app deployment and maintenance. I want to be able to support new Android devices like the Galaxy Tab, but I don't want to be building a bunch of one-off device-specific app implementations. Isn't the point to be able to have one app work on the gamut of devices?
Thanks in advance for any insight you might have on the situation.
It's not the case that you need to use the Samsung-provided build target to deploy your app on the Galaxy Tab (definitely not the real device, and for me the emulator works fine).
I build all my projects with a target SDK of 4 (Android 1.6) and they run fine on the Tab AVD.
One implication of the advice from Samsung that needs consideration is that they want min SDK (not the same as target SDK) set to 4, which will exclude Android 1.5 devices. You probably do not really need to do this but should test to be certain.
In general with hardware vendors (Motorola, Samsung):
- do take advantage of the AVDs, especially if you don't have the budget for the real device or it's not yet available
- do not use the custom dev environment, stick with the Google standard tools.
My two cents.
It would appear that I have to use
this build target to get the
emulator to work. Is this true of
the device in general? (i.e.) could
I build against the standard
android/google APIs and have it run
correctly on the actual Galaxy Tab?
This shouldn't be required. After all, most market apps run just fine on the galaxy tab. The only problem seems to be that the GT emulator doesn't have the Google APIs installed, though AFAIR the actual device does. But I might want to check on that as soon as I get back to office.
If I deploy an app with this build
target to the Android market, will
this adversely affect other (smaller
screen) devices that I already run
on? (I.e. is the galaxy tab "special
sauce" a superset of Android
functionality? I see grumbles about
the Google APIs for maps not working
in it, etc.)
Well, I don't think so, but you should probably use one of the regular build targets anyway. The GT plugin only helps you by specifying the API version and the devices parameters, there is no special sauce involved.
Will i have to have two versions of
my app in the market? One for
"standard" devices and one for
"large" screen devices? One for the
Galaxy Tab specifically?
No, you shouldn't need to. You actually don't have to change anything in your app to make it run decently on the GT, since Android handles most of the heavy lifting. Android won't help you provide a different layout for tablets though, since they are not officially supported yet. But by looking at screen size and density, you can still choose to do so manually.
When Android Tablet vNext (whatever
that may be) comes out and has its
own custom add-on and build target,
will I have to clone my repository
and publish/maintain a device
specific version of that (presuming
that any add-on special sauce for
the galaxy tab will not be in
vNext's add on and will not be
"compatible")
Simply put, no. In the future, tablets will most likely be supported directly by Android, and, if the current state of affairs is any indication, it will provide numerous ways to help you adopt your application for all kinds of tablet devices as well, without having to fork your code.