Using this library, ZXing, we have a project at school in which we'll implement a inventory system using Android phones.
We aim to use an Android phone to be a inexpensive replacement to this:
I've read some of the warnings on the FAQ for certain phones. Is there a specific phone that Android developers prefer (with use of the ZXing library in mind)? We have to buy the phone ourselves, so we would prefer not to buy the wrong phone!
You want phones with auto-focus capability on their cameras. Some of the smaller/cheaper phones, like the HTC Tattoo, have fixed-focus cameras. Some tablets do not have a camera at all. Most Android phones have auto-focus cameras, AFAICT. Certainly, every one I have used has had one, and I have quite the collection at this point.
I'd watch out for phones running Android 1.x, not because of any ZXing problems, but if you are going to spend money, I'd invest in an Android 2.x device. One advantage of the Nexus One cited by Blumer is that it will get new Android releases as fast or faster than any other device.
Beyond that, and beyond specific problems cited on the ZXing site, anything should do, if it works with your carrier, is a color you like, etc. :-)
Developer here. The single factor that really makes barcode scanning easy is an auto-focus camera. Resolution, CPU, etc. don't matter. The library can work with any version of Android but 1.5+ is recommended.
So, just about any used Android phone ought to be fine.
Follow up at http://groups.google.com/group/zxing .
I don't know that there's necessarily a "preferred" developer phone, but the Nexus One is the official developer phone as endorsed by Google: http://android.brightstarcorp.com/index.htm . Despite being kind of a business flop, it's a very nice phone, and it's hard to imagine how you could go wrong with it for development purposes. Since it's put out by Google, it should support everything there is to support, and it's not mentioned as having any issues in ZXing's FAQ.
Related
I am building an application with React Native but the app not working well on a few android devices. So I need to see what's going wrong but I don't know how to set up an emulator for a specific device. Are these problems depends on phone's brand and model or it just depends on their android versions?
Its not really possible. There's two major problems:
Software. Real devices don't ship pure AOSP like runs on the emulator. They add patches and features and there's no way to know what they actually run.
Custom UIs. Many phones provide custom UIs like TouchWhiz and the like which can override Android behavior
Hardware. If your app depends on things that are very hardware specific, like GPS or Camera, they could have issues due to hardware bugs.
If you just want to emulate a specific OS version like KitKat, or specific low memory conditions its possible via emulator configuration. If you really need to test on a device, either buy one or use a service that allows you remote control over specific devices. Amazon has a nice device farm that you can rent over AWS.
One of the biggest challenges when developing for Android is the wide variety of devices and "optimizations" manufacturers make to their Android versions.
The Android emulator is based on AOSP (vanilla Android) and was only recently published with Google services included. This is the most clean version of Android. You can use the emulator to test UI scaling for different screen sizes but it will always behave like an AOSP Android. Google packs a bunch of hardware configurations into Android Studio which you can simply select when creating an virtual device. You can always create a custom hardware profile with custom screen size and resolution. Some manufacturers also change the DPI value of the OS causing the UI to be bigger or smaller, keep this in mind when creating a custom hardware configuration.
Further, you can use the emulator to test the default behaviour on different Android versions. Again, manufacturers change their Android usually causing slightly different behaviour.
I assume that your question is focussed on different behaviour of e.g. Samsung phones having crashes only occuring in Samsung phones (Samsung can be exchanged with any other brand here). Unfortunately, there is no simple way to test this but getting your hands on the faulty device. One option is to use a cloud based test lab (e.g. Firebase Test Lab, App Center or AWS device farm) to test your code on the faulty device or rent the device at a local shop. Most bigger cities have companies renting phones and tablets on a daily or weekly basis.
In the end you will need if statements checking for a specific device, manufacturer or Android version or any combination of them and doing something slightly different to fix the undesired behaviour.
I know that this is not the answer you are looking for, but it's the best I can offer. To tell a little tale of my worst experience: I had once a bug were calling a crypto function caused a kernel panic on HTC (?) phones. This means the user opened my app and the phone rebooted. I was required to implement the entire encryption logic again just for HTC with Android 6.0.
What are the next Android smartphones to be compatible with ARCore?
Is there a known list of future compatible devices yet? Maybe a general project schedule?
We are about to purchase some units for AR development assessments, at first we thought about trying one of the Tango devices out there (we already had a good experience with Tango), but our current bet is that the ARCore platform will beat it in terms of market share.
Currently, the compatible devices are only:
Google Pixel
Samsung Galaxy S8 (the non-plus version)
But obviously, we would prefer to choose from a wider variety (e.g. S8+, G6...)
I know that there is a known hack to make it work on other devices, but it is better to start on the right track with a compatible one while we still can.
Also, is there a way to run ARCore on emulator that connected to webcam?
For test purpose.
(I don't think this answer deserves the bounty, and I also don't think you'd get a worthy one any time soon. But let's roll anyway:)
So I did a bit of a research as to why are these the only devices supported. It's a tough question to answer of course, but we can speculate.
I read through the reddit on the subject (among other sources) and it seems that ARCore does not require some special hardware, but it does require a "calibration profile" per each specific set of camera, sensors, and builds. I.E. each device.
I've found this Medium article about what Apple had to do in order to calibrate their own ARKit coupled with some speculation about Google's calibration process.
WOW! Turns out it's a really heavy task. And it seems that Google has chosen these devices specifically because they've already undergone some initial calibration for other purposes. So it's even harder to start the calibration from scratch.
OK... So?
So... There seems to be mixed news here:
The good news is that ARCore does not rely on some fancy new hardware platform with some fancy new standards that are gonna be hard to enforce in an already highly fragmented market.
The bad news is that unless an automatic calibration process is invented, each device SKU needs to undergo a costly, lengthy and manual process. It's very hard to estimate the costs involved, and even harder to estimates the rewards.
Which brings us to where we started: My guess is that device manufacturers will not be quick to jump on the ARCore bandwaggon. Yet.
It seems that it's gonna take some time before you'd get a reliable answer to your question.
The current list of ARCore supported device manufacturers and models can be found here:
developers.google.com/ar/discover#supported_devices
To your last question around testing on the emulator, as of this week, you now run ARCore in the Android Emulator with a virtual AR camera:
https://developers.google.com/ar/develop/java/emulator
When you are using Android Studio 3.1, and Android Emulator v27.1.10, just create a new Android Virtual Device (AVD) for the Android Emulator that targets Android 8.1 Oreo (API 27) and verify that the back camera is set to Virtual Scene.
You will get the current list of ARCore supported device manufacturers and models below link.
ARCore Supported Devices
Here is a list of ARCore 1.4 Compatible Devices (last updated October 19th, 2018).
I know this question has been asked before but its been a long time. Asking this question again to gather any new hacks/thoughts/approaches.
I need to access both front and back camera simultaneously.
So far I have tried implementations using android camera API (Dual Camera- by Jens) and camera2 API. Both implementations work fine on devices having hardware support(Dual Image Signal Processors) for dual camera feature.I have tested and both implementations works fine on HTC one M8(Snapdragon 801) & Xiaomi Mi4(Snapdragon 801).
Both implementations fails on Samsung s6 even though it's hardware capable (Exynos 7420 has dual ISP). Also, the default camera app on S6 supports dual camera mode.
Any ideas/advice on this ?
Thanks in advance.
Update:18/11/2015 --> Tried using the Samsung Galaxy Camera SDK but still no luck.
I had to implement the exact same thing in a previous project. I know the struggle, and I know how much code you have to write to make this work. Especially with Google providing TWO camera apis (camera and camera2).
Even though I got it working on some devices (like HTC M8) which basically had two Image Signal Processor (necessary to access both cameras at the same time), I had trouble with the Samsung devices that had this feature implemented in their native camera application.
Then I turned around and found out that Samsung provides different special APIs for its "very special" OS. What that means, is that for every special feature that Samsung has (like the finger print sensor, the S-pen, and soooo on), they provide a API for the developers to work with.
I found the SCamera API on their site here . They also provide very good documentation and it is ok to implement.
The question you need to ask yourself: is it really worth it to integrate yet another camera API in your app to make this work on Samsung devices as well? Take in consideration that the proportion of Samsung devices is really high.
My advice? Try and implement it in a different project and see how that goes. If you get it to work in a decent amount of time and it's not very complicated, then integrate it in your main project.
I hope this helps you. Have a great day and good luck!
First off, sorry if this is too subjective, I just didnt know how else/where to ask.
Anyway, in the light of all my recent questions, I'm getting ready to release an Android app soon, and most of the testing has been done on my phone, the Droid. I really dont have the money to test on "multiple" devices, nor do I know anyone with an older phone that I could ask for help that would possibly get any kind of bug. Not to mention, when I do get a bug report, how would I go about fixing it for that particular phone without having to buy it to make sure it actually gets fixed, or that the person didnt just came across a one-time freakish accident of a glitch?
How do you guys solve these kinds of issues?
You can test the vast majority of issues via the emulator:
Check out this data on platform versions and screen sizes to get an idea of what configurations you should test for.
Based on that data, I'd test at least one configuration with API versions 1.5, 1.6 and 2.1, and versions with medium and high density resolutions.
If you wanted to test physical devices, I would guess that the G1 and the Droid would be the top two... G1 would give you the lower API versions, and Droid would give you the 2.1.
Depending on your application that may be sufficient. Applications that make heavy use of OpenGL extensions might need to test further, since that is the area where there is the most difference from device to device. I don't think that the emulator is sufficient for that. See this thread on the differences.
Other than that, I would just send out a demo version of the app to a few friends or an appropriate forum. If you find problems once you launch, collecting log data from users having problems can be very helpful. I wouldn't worry too much about device specific problems though, I don't think they are that common.
Disclaimer: I'm a Motorola employee in our developer services team. I don't speak for other OEMs.
Cover the range of devices that are enumerated in the "supports-screen" manifest element. Also, take into consideration when compatibility is mode on and off. Screen sizes and market filters seem to me to be the biggest things that trip developers up. Some of this you can test with the emulator and others you need real hardware.
OEMs provide SDK "addons" that allow you to run emulator images with the skin and screen size/density of their devices. Download addons from the OEM's developer sites. Motorola's addons are available at developer.motorola.com. HTC and Samsung do the same.
A commercial alternative is Mob4Hire. They have real people on real networks who can test your app for you.
Good luck
I have few friends wich have different android devices. Before app publishing I give it to them for tests. Sometimes any users submit bugreports to market, sometimes sends it to you by email. There is impossible to have all android devices and test own app on it. This is ok.
It might be worth having a look somewhere specialist such as http://www.xda-developers.com/
They've got a sizeable community there of reasonably knowledgeable people and its not uncommon to see people posting betas of apps there for consumption and feedback. There are also dedicated subforums for each phone which may assist when attempting to resolve problems on certain handsets.
Has anybody blogged about this comparison, or does anyone want to give it a shot here? Would be nice to see some reasoned thoughts on Adobe AIR on Android vs. the "native" Android SDK (in Java).
Edit: Despite few views and no answers, I'm leaving this question up here since it's a topic that needs to be covered at some point... but if it gets no attention I'll delete it in a few days.
I think it's ultimately very similar to the question of whether to use AIR or Java for a desktop application. Ultimately it comes down to three points:
Does AIR do everything you need? Obviously the android SDK gives you complete access to device capabilities, but AIR purposely doesn't, in order to stay portable. For example, AIR may not support intents, at least initially (I don't think Adobe has announced yet one way or the other). Also, AIR requires Android 2.2. If those limitations are troublesome, regular android SDK may be best.
Are you looking to make something that would be well-suited to doing in Flash? If you're planning a design-heavy app with animations, video, sound, or the like, then building it in Flash may be significantly easier than using Java. On the other hand, if your app will be pure code using only standard visual components, then it might not make a lick of difference which platform you use. Or on the gripping hand, if you'd have existing Flash animations or the like, then trying to shoehorn them into a Java app will be bothersome.
Are you targeting other platforms besides Android? If so, AIR may be a big win, as the same app content should run on windows, mac, linux, and later on, other devices that plan to support AIR, like Blackberry, some TVs, blu-ray disc players, etc. If you are only targeting Android, AIR may lose some of its appeal.
I hope that helps some. Realistically, unless you're effectively locked out of using AIR because you need something it doesn't give you, or effectively locked into using AIR because you're doing design-heavy work and you need the tooling, then I think the pros and cons of the two SDKs are largely questions of convenience. Either platform will work, so it's merely which will get you to the finish line the fastest and most reliably.
One issue to consider is compatibility with Android devices. Both fancy smart phones and cheap phones run in Android, but they don't have the same capabilities. Even if you application is simple or can be done beautifully in AIR, its relevant to mention that AIR is not compatible to all Android devices.
Some very popular devices currently sold (such as Samsung ACE and other "cheap" devices) use ArmV6 chips, and AIR or Flash are not compatible to this architectures, even when running on Android 2.2 or so.
AIR is interesting because same development works in different technologies, but consider that AIR doesn't run on "old" iPhones either, its only guarantied to work on new technology with big processors.
Check this Adobe link http://www.adobe.com/flashplatform/certified_devices/
AIR should be ruled out in your decision of technology if in your requirements you are targeting as much phones as possible, including those that are not so fancy or new.
I have experience with AIR mostly and little with Android SDK when I was building a native extension to AIR. My biggest hurdle with AIR is it's immaturity, it's bugs, and it's inconsistent behavior. Yes, you can go to the shiny page at adobe.com and see how cool is the AIR... All bright with tons of features which seems to cover all your needs. Yet, once you start building your app you'll find many ugly surprises:
Stage text in not working appropriately. link besides this bug StageText has few other bugs, like behavior in Scroller for instance.
Sound() object doesn't play the stream (it does on emulator only). link
Lack of features like AEC makes AIR useless to whole list of chat applications, as you'll will hear echo and screaming noise. link
Overloaded (and immature for mobile) Flex SDK (I hope folks at Apache will rewrite it from 0 and make it more manageable).
No H264 support on iOS devices: link (yes, I know it's Apple problem, that they want to control HD delivery on their platform, still it's Adobe problem too, as they couldn't fight right to bring their technology to forefront).
Sound object doesn't take variable bidrate (only 44.1KHz is possible). Flash "second generation" Speex codec samples at 16Khz. Now, try playing this back through Sound and you'll enjoy a funny circus. At the end you will need to write your own upsample algorithm.
I'm sure people will add more to this list. So, my answer would be native SDK is more preferable for anything serious. You won't work like a QA person with it - testing countless little examples trying to understand why an AIR feature not working, shuffling internet for answers and looking at AIR bug database... only to find that critical bugs are sitting there from release to release. That is my experience with AIR. Going native SDK makes your application not really "cross-platform", but AIR SDK can't claim this title anyway for anything more serious then couple of "Employee directory" examples. And if you will need to build for the other platform, you will just use native tools for it.
GL.