Is there a way in android to publish different APKs based on various heuristics such as
Total available memory
CPU speed/type
Storage space
Even brand name (Samsung or Nexus or whatever)
I know there's a way to do it for different screens but let's say you would like to have more animations and better resolution images and more graphic/CPU intensive operations for higher end phones and tablets but still provide basic level functionality (albeit with reduced function set or a more basic UI) for older/less powerful phones.
Is this possible? If not, I fear I have to cater for the lowest end of the market and won't be able to make use of the better hardware that some users may be using.
Many thanks,
p.s. I'd seen this before I posted my question http://developer.android.com/google/play/publishing/multiple-apks.html but it doesn't quite answer this question which is why I posted my question.
Why it doesn't answer my question is because it only mentions the following attributes for determining which APK would be available for a device:
OpenGL texture compression formats
Screen size (and, optionally, screen density)
Device feature sets
API level
CPU architecture (ABI)
However, it does not mention the memory, storage space or the CPU speed (though CPU architecture may... I have no idea) which would be ideal to have to decide whether or not to load a reduced set of resources and functionality or not which is why I don't believe the mentioned link quite answers my question.
Related
I'm trying to use the TFLite Benchmark tool with mobilenet model and checking the final inference time in microseconds to compare different models. The issue I am facing is with varying results between runs. I also found this section in the documentation which is pertaining to reducing variance between runs on Android. It explains how one can set the CPU affinity before running the benchmark to get consistent results between runs. Currently using Redmi Note 4 and One Plus for the work.
Please, can someone explain what should I set the CPU affinity value as for my experiments?
Can I find the affinity masks for different mobiles online or on the Android phone?
When I increase the number of --warmup_runs parameter I get less varying results. Are there more ways in which I can make my results more consistent?
Are the background processes on the Android phone affecting my the inference time and is there a way I can stop them to reduce the variance in results?
As the docs suggest, any value is fine, as long as you stay consistent with one across experiments. The one thing to consider is whether to use a big core or a little core (if you're a big.little architecture) and usually it's good to try both (they have varying cache sizes, etc.)
Yes you can typically find this information online. See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CJHBGEBA.html as an example. You'll want to look at your particular phone, see the particular CPU it uses, and then google for more info from there.
I've tried --warmup_runs = 2000+ and typically it's pretty stable. There's a bit more variance with smaller models. For intensive models (at least for the particular device), you might want to see if the devices are overheating, etc. I haven't seen this for mid-tier phones, but heard that people sometimes keep their devices in a cool area (fan, fridge) for this.
They may, but it's unavoidable. The best you can do is close all applications and disconnect from the internet. I personally haven't seen them introduce too much variance though.
Apologies in advance if the question sounds dumb.Here's my problem
I want to make an OCR app for android smartphones.I am wondering if someone can tell me how much RAM and processor will be enough for image processing involved in it?I am trying to extract all the text from a printed A4 page in one go, how much should be the camera resolution for having a clear image of all characters?
In my experience the most important hardware requirement might not be RAM and processor but rather camera auto-focus feature. If mobile device does not have auto-focus feature then in majority of cases you can't get proper scanning results.
Second, mobile device cameras (at time of this writing) are not suitable for A4 document scanning in one pass (unless you have a very large font on the document :). The quality of scanning results will be poor even with top quality mobile devices. Good results can be achieved with documents that are about one third the size of A4 documents with mid and high-level devices.
Disclaimer: I work for a company that has developed own mobile OCR and other mobile vision software that are used across different industries.
Same as with most questions related to hardware requirements:
You'll probably find out by testing with different hardware setups.
As you'll need to test Android apps with various devices anyway, that should not be a big deal.
We can't know the font size and neither can we estimate the complexity of your algorithms. Also I assume that the font(s) which you use has an important influence, depending on the distinctness of their chars rendering.
Plus, if the image is blurred, that'll negatively influence the resources you need.
Does any Android today support swap area which is suppose to boost the performance?
What are the considerations that make most Android devices drop that feature?
Does any Android today support swap area?
Quoting Dianne Hackborn:
To be a little more specific, it does use paging but not swap space. That is, it relies heavily on being able to mmap() files and have the kernel page in data from the file as needed (and drop those pages when not needed). It does not however use swap space for paging out dirty pages.
With some slightly adaptions, swap area can work with Android's default low memory killer together well, right?
I certainly would not assume that.
Does any Android today support swap area which is suppose to boost the performance?
It is not supposed to "boost the performance".
what's the considerations that make Android drop this idea?
First, on-board flash is slow, much slower than the hard drives and SSDs that you are used to on desktops and notebooks. And while the quality of the flash storage used on Android devices today is better than it used to be, it's still not screaming fast. That's why, for example, we have to take special care when doing database I/O, to use transactions, to limit the number if disk write operations.
Second, historically, on-board flash was limited in space. We didn't have enough internal storage for our apps, let alone to dedicate some for swap.
If you wish to discuss this further, please use a more appropriate forum, such as http://android.stackexchange.com, as your question is only tangentially related to software development.
Android does support swap... Don't forget it's just plain Linux with some UI on it. :)
However the support is dependent on the kernel you are using.. When using a kernel you should know if it supports swap space or not..
If you are good in kernels, then grab the source, enable swap support and compile it. I guarantee that should be fun :p
Personally my kernel supports swap space and I use a 20 MB file to act as a swap file.
For Android or even iOS to practically support non-kernel swapping, three hurdles must be overcome:
Space Constraints: Due to the usage of flash memory, as opposed to HDD's, space comes at a relative premium
Write Frequency: Flash memory tolerates fewer writes before becoming unreliable (relative to HDD)
Communication Throughput: There is poor throughput between main memory and flash memory on mobile devices
I'm developing an app that it functionality very similar to Facebook Android native app: social network that most of the time the user will spend in an endless ListView displaying lot's of images, entering an image gallery, and so on.
let's say for the discussion that I'm doing all the right things and best android practices to achieve smooth scroll (recycling views as it should, using different view types when needed, loading to memory only scaled bitmaps in the needed size, caching bitmaps, using ViewHolder design pattern, not blocking th UI thread when its possible and so on...)
let's say also that every thing else in my app written in the best way and following best practices (for the discussion... :->)
my app working not bad at all in that stage, but when
turning on the hardware acceleration, as described and promised in Android Developers documentation it making my app much much more smooth and fast.
let's say that it does not affect in any nagative way on the UI as can happened, and I'm not performing any of the Unsupported Operations
according to Google's document on the subject, only reason I can see not to use this feature (besides all other reasons I already mentioned above) is that it can cause my app to use more RAM. but how much RAM? a lot more? I know that when my app consumes lot's of RAM - it becoming good candidate to be destroyed by the OS when it need to free some memory.
my question is basically -
is it "ok" under my circumstances to use this feature?
what other problems can raise from using it?
TIA
To use or not to use
It is advised to use hardware acceleration only if you have complex custom computations for scaling, rotating and translating of images, but do not use it for drawing lines or curves (and other trivial operations) (source).
If you plan on having common transitions and also given that you have already considered scaling, recycling, caching etc, than it may not make sense to burden your project anymore. Also, any efforts spent reworking your code to support hardware acceleration will not effect users on versions below 3.0, which are ~36% of the market as of May 8, 2013.
Memory
Regarding memory usage (according to this article), by including Android Hardware the application loads up the OpenGL drivers for each process, takes memory usage of roughly 2MB, and boosts it to 8MB.
Other issues
Apart from API versions, I presume it will also affect battery life. Unfortunately there aren't any benchmarks on different use cases online in order to draw a line on this one. Some argue that in given cases because of multiple gpu cores, using acceleration may save battery life. Overall, I think it would be safe that the effect won't be too dramatic (or Google would have made this a major point).
UPDATE
Hardware acceleration is enabled by default if your Target API level
is >=14
I would say yes in your situation, use hardware acceleration.
Seeing that you aren't using any resource intensive controls in your app it should not be a problem to enable Hardware acceleration. As you said your app is working quite well without hardware acceleration.
When you enable hardware acceleration Android will start using your GPU and because of the increased resources required to enable hardware acceleration, your app will consume more RAM.
A frequently asked question is Will the amount of ram increase by a really big amount?
The answer to that will all be determined by :
1. Your programming ability ie. management of the recycling list, scaling of the Images ect.
2. The Device
I wrote a app a while ago that was used to edit really high res bitmaps. I ran into the same problem. I found that on different devices the max amount of ram allocated by the OS when hardware acceleration is enabled varies by device. If your device has more ram the OS will allocate more ram to your app, so you will never find a consistent amount of ram used for your app. The bigger more expensive devices will always run your app on a larger amount of ram.
What other problems can raise by using hardware acceleration?
Hardware acceleration might cause problems for some 2D drawing operations. If you experience this you can enable Hardware Acceleration for only specific activities in your app like stated on the Hardware Acceleration post in the android Developer Docs
The easiest way to enable hardware acceleration is to turn it on globally for your entire application. If your application uses only standard views and Drawables, turning it on globally should not cause any adverse drawing effects. However, because hardware acceleration is not supported for all of the 2D drawing operations, turning it on might affect some of your applications that use custom views or drawing calls. Problems usually manifest themselves as invisible elements, exceptions, or wrongly rendered pixels. To remedy this, Android gives you the option to enable or disable hardware acceleration at the following levels:
Application,
Activity,
Window,
View
This way you can also limit the hardware acceleration in your app but by the sound of it you will need it for most of your apps functions.
Hope this helps
There are dual core and now quad core phones in market. However i really don't know what kind of apps does truly makes use of the feature. Can anyone provide some information on the apps that can really make use the power of dual -quad cores in mobile devices.
The idea of having dual,quad or more processing is not for specific apps to use it.
It just means having more processing speed available at hand, which will only be used when completely necessary.
For example, when there is a process that can be handled by one core, which is usually the case for most apps, the other cores aren't necessary. But there are high end games or more than one process that have to be run, which need lots of calculations at a given time, other cores may also be used, if there is room for improvement in the first core.