I need to test if my app is compatible with the Android system Oreo GO. The problem is I don't have devices to test this one, as it seems very specific (created to run in low quality machines).
Anyway, I know Google allows the developer to prohibit the use of their app in this system. Is there any way to check this up? How did you do It?
Unfortunately there is no way to check the compatibility for now. For example, no emulator with Go edition is available. What can you do is --
Simply fire up Android Studio and set up an Android Studio emulator image at API level 19, then reduce the RAM size to 512MB and lower the JVM heap size. This should suffice as a testing environment until Google supplies official images to be launched within the Android Studio emulator.
Related
When I make create a Virtual Android Device on Android Emulator with Google Play API 27, it does not allow me to give a custom amount of RAM size. Instead it takes a default 1536 MB RAM and 800 MB of Internal Storage. I don't understand why....
I solved this issue by changing the value in the config file.
In the list of virtual devices (in android studio) click on the arrow on the right side of your device and click on "Show on Disk".
In the folder should be a config.ini file, open it and change hw.ramSize=1536 to Example: hw.ramSize=4092
I expirienced some problems with the Android Virtual Device (loading times) and I started using Genymotion. I suggest you to do so. It is easy to use and full compatible with Android Studio.
As per the update for Oreo 8.1 there might be a restrictions due the feature of Android Oreo (Go edition)
Features in the Android Oreo (Go edition) configuration include:
Memory optimizations. Improved memory usage across the platform to ensure that apps can run efficiently on devices with 1GB or less RAM.
Flexible targeting options. New hardware feature constants to let you target the distribution of your apps to normal or low-RAM devices through Google Play.
Google Play.While all apps will be available on devices running Android Oreo (Go edition), Google Play will give visibility to apps specifically optimized by developers to provide a great experience for billions of people with the building for billions guidelines.
this might be restricting the emulator to choose the best optimal option to run app on your virtual device.
Obviously, there will be minor differences between the emulator and hardware, but I'm running across major issues and wondering if others have found any solutions.
I have an .apk of my application, which loads and starts fine on the 2 pieces of hardware I have on hand (both OS 4.1.2). It then freezes up on a screen switch inside the application. This has happened before and it was due to that exact version of the OS having a particular bug (which should be worked around). Anyways, those details are not terribly important, that's simply how I got to thinking I'd test other versions via the emulator. However, here's what I hit:
Newer versions (5+) of the OS have an "Intel" option and my .apk crashes immediately on start on those versions.
Newer versions (5+) the Google version and 4.x generic (including the very same 4.1.2 I have on 2 hardware devices) starts my .apk fine, except that all the graphics are missing!
No difference between architectures on any given OS/class (32/64 bit, mips, arm)
What's the difference between Intel and Google versions of Android that would cause such a huge difference? Also, why does my app have graphics on hardware, but graphics vanish on the very same OS on the emulator? Are there options I need to change somewhere?
First update your SDK.
Then install emulator system image you need.
In SDK Manager you can find that Intel/ARM Android images start from 4.0.3 . Google Intel/ARM start from 4.4.2 instead .
Make sure you have hardware virtualization enabled in PC BIOS because Intel images need that and they are much faster for that.
Try to reinstall Intel HAXM . You can find setup in <Android SDK Path>/extras/intel\Hardware_Accelerated_Execution_Manager
Intel/ARM images use different CPU architecture. Instead Google/Android images have only a different software configuration. Google images include Google services like Play,Maps,ecc. Android images haven't them
It appears to be due to timeouts. Differing versions and "equipment levels" of Android devices take varying times to respond. The difference is especially large in the emulator. By bumping up all the system timeouts in the code I'm able to avoid all of the avoid weird issues.
I have an app which runs fine on Android 5.1 but it takes ages to run on old android version, even though I configured the minimum target to 4.0.1 (API 15).
The app is based on a mainactivity and switches among three fragments. For the fragments, I use support libraries, so that it can run on old version of android.
Why could I be doing wrong? Some hint about having an for different android version using API 22?
If there isn't a problem in your code, check the old device ram and heap size also try selecting a good device for example galaxy nexus.
also some information for better performance for the emulator, here:
Making the Android emulator run faster
I am new to Android development and just installed the new Android sdk with Eclipse and ADT bundle. From this question, I knew about installing Intel X86 system image.But, I have one confusion about installing intel x86 for which I coudn't find any solution on internet.
In SDK manager, Intel x86 system image installation options are shown for each API level as in the picture.
image is here (since I have no privileges. Hope someone will correct it)
So, my question is that Do we need to have intel x86 system image for all API levels?
(I am making an application which will support from Android ICs to kitkat.)
Short answer: no, you don't need to. When I am actively developing an application, I'll pick a target API level and just use the emulator for that API. It's just like only having one phone to develop on - while you're working, you can only really use one at a time, anyway.
When it comes time to test, however, my advice is to run your app on as many different configurations as you can get your hands on - including different API levels. Now, one thing to keep in mind is that even though the emulator images are all official and provided by Google, they're not a replacement for testing on actual devices. Your app will have different performance characteristics in the emulator, and there are often device-specific bugs (industry term "quirks") that you won't find with the emulator (and some bugs that you'll find only on the emulator).
So, my overall answer is no, not really. Download and use whatever emulator is your target API, maybe download and also develop occasionally on the emulator for your min API, and then try as much as you can to do final testing on real devices, only falling back to emulators whenever you're unable to get a real device with a specific configuration.
If you dod't develop the Intel x86 system device, you don't need to install it.
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.