I am using Mark Murphy's DroidEx tool to project my android device screen; is there a way to supply a skin(e.g. a HTC Hero skin that we use with Android emulator) to DroidEx?
I have also asked this question on the google group for DroidEx project.
Thanks!
No, it is not possible, at least with the code as it stands. Support for the now-slumbering DroidEx is handled via the [cw-android] Google Group. People interested in a software projector for Android may wish to examine Droid#Screen instead.
I've used the android-projector utility on Windows.
The projected screen has some flickering problems, due to a very low refresh rate, but it's definitely usable.
Related
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 own a Samsung Galaxy 3 and want to port kernels available for other Android Devices. I have all building environment ready. I have C knowledge also. What exactly I dont understand is how and what all things porting involves, which codes should be modified in what way?
If someone could help me. It would be great.
Thanks in advance.
Ok I got it. But the real problem is I dont understand one thing.
What needs to be changed in the source code so that to make it compatible in other device? Can someone explain me that?
Idolon gives a good suggestion. In theory what is written there is true. In practice, it's a little more involving. I've been porting Android Kernel for months now. My goal was to have a custom S5PV210 processor module on my custom board with my custom I/O. I have the source code for Samsung's galaxy tab and several Samsung's android smartphone as well as a few versions (Froyo, Gingerbread) for the Samsung's Evaluation board (SMDKV210 for S5PV210 CPU). FYI, S5PC110 is a close derivative. Here is what I found out.
Eventhough all the device drivers are supposed to be built in a very modular way and independent from each other and you should be able to replace them with similar devices, the way Samsung did it is not exactly that. To give you one example is about power management. In many low level drivers dealing with hardware devices, it calls some specific routine for other hardware devices like power management chip. So, When you change the choice of drivers in the "make xconfig" or "make menuconfig" it will remove the source code of what you don't want and add the one you want but, there are still other modules that are calling the low level function you removed. When building, you will get tons of unresolved external because you removed a power management chip that your hardware doesn't have but is used in the source you started with. I looked through several Samsung's device source code and they have branched very early on. They have been adapted by different teams and it would be a major amount of work to go from one device to the other from one source kit.
Here is how I succeeded: I bought an S5PV210 evaluation board with an already ported Android Kernel (Gingerbread). All the power management and inter dependant issues where already cleaned-up. Then, form a working kit, I could change the device I needed (the one you can't buy without a 100K unit/yr commitment) without getting stuck with the interdependancy. Then I could even change LCD resolution (from 800x480 to 1024x768), touchscreen, Cell modem etc etc. The whole thing takes about a month worth of work with only one guy (me).
Starting with a Galaxytab or other commercial device made me waste months of headakes with no useful results but the thing I've learned.
There is one requirement to succeed on my approach. You have to know the hardware you are working on. As an example, you need to know what touch screen your hardware has (chipset) to select the driver and were is it connected to hook it up to the right device (USB, Serial etc). That the same thing for all other devices (power managemnt chip, keypad, backlight, LCD etc etc)
Hope that is useful to give you an idea of the work involved and how you can do it.
You should take a look at the cached copy of Android Platform Developer's Guide and at android-porting google group.
There is also an old but useful article about porting Android to Nokia N810, which will give you some hints about Android Linux kernel porting.
I am also into android porting stuff for quite some time I suggest the following route :
Read
You need to have basic knowledge of android porting and AOSP source code, directory stucture hierarchy.
I suggest you to start reading https://books.google.co.in/books/about/Embedded_Android.html?id=plHsngEACAAJ&hl=en
and also refer https://source.android.com/devices/index.html as good guys pointed out you can also google android porting related groups and become a member there, if you are stuck on a issue there are chances similar issue might have been faced by someone else previously.
Observe
AOSP code :
Parallely you need to dive in to the android source e.g from links like https://android.googlesource.com/ observe which components are placed where in the source code, what are the updates from previous android release (like ART replaced dalvik in LL), at top level there would be generic code, code specific to your hardware called HAL in hardware/ and device/ folder.
Kernel code :
In the kernel also you need to observe the directory structure and know which things lie where like SoC specific code will be in arch/ directory defconfigs (used for selecting kernel configuration) will be arch//configs/ directory.
Also there are good books available for linux kernel, you can google them and start reading them also.
While porting kernel you need to take care of following
1.If in the new kernel there is already support of SoC which is used in hardware to be ported then you need to add only device specific changes like suppose you want to port new kernel version to samsung galaxy s3, you can take a reference android kernel having exynos support and then you need to make changes only for adding support for samsung galaxy s3.
For that you need to have reference of some old kernel having support of s3, from there you can study patches which have been added to add support for s3 and port those patches to newer kernel.
Experiment
First you can only port the bare minimum changes required to up the platform, compile and flash it on your platform, then observe the output, if everything looks fine than go on for next changes otherwise try to solve the issue.
Thanks,
Devarsh
I'm currently developing apps for iOS, but I also want to start developing for android. The device to use for iOS development is not too hard of a choice, because, well, you don't really have much of a choice, either an iPhone, an iPad or an iPod Touch, end of story. But for Android, you have a much wider spectrum, there are many different models and many different brands. So, what would you recomend for Android development. I don't want to spend that much money, but also I want a device that won't get obsolete too soon. Any suggestions?
The Nexus series of dev phones should be an obvious choice since they are the first ones to be updated with new releases.
Also, as rony l pointed out, they are installed with vanilla Android and are not contaminated with 3rd party software.
I would choose the latest Nexus Series phone since it is the most 'Google Android' phone out there. They seem to be the first ones to be updated when new releases of android comes out too! The Nexus S is a good shout since it's the latest one.
Nexus S is a good choice.It's new android phone from Google and is quite well for development. You can read more here: http://www.google.com/nexus/#/tech-specs . But of course it's better to have some devices for testing.
You are best to use a Google branded phone since it has no extra "skins" on top of the OS like most other brands do. The Google Nexus series is discontinued now, so get a Pixel phone instead.
I am not sure how to simulate the HTC Sense UI using the emulator.
I know there are 3rd party add-on's available from the SDK Manager, but HTC does not have an entry. I also see the "Add add-on Site..." button, but can't find the URL for a site at HTC that I could enter here.
I did find a 3rd party "Skin", but I am pretty sure this will just change the "frame" the emulator shows up in (to look like a particular phone). I want to emulate the UI. If a skin would work, I would like an official one from HTC if possible.
HTC released their own SDK. They also provided a installation manual.
Did not tried it by my self, yet. I will give it a shot this afternoon and report back.
//edit:
I tried it out and it was disappointing as on those HTC-AVD's there is no HTC-Sense installed :( Also you can only choose between a HTC-Phone-AVD (API-Level 10) and a HTC-Tablet-AVD (API-Level 12). So for example the HTC Desire (which I personally own) is not available as avd at all ...
Cheers Ali3n
There is no supported way to do that - HTC has not release a Sense UI APK/suite. Any solution you may find in the corners of the internet will be shady and potentially untrustworthy.
I am new to the development as well as the prg world. I want to learn android and want to make applications for it. So one possible way is to buy a new android phone to test it live and not on emulator. But I have two spare phones, Nokia N70 and Motorola MotoRokr E6. So I was willing to port the OS on those machines. As a result I wanted to know is that possible then what all do i need for that considering both Software and Hardware Aspects.
ThankYou in Advance...
Its possible however I would strongly recommend against it.
While android is open source and nominally can be run on any system you choose, in reality you would have to start worrying about keyboard incompatibility, drivers for any integrated peripherals your phone has, lacking buttons that are standard to all android phones etc.
Getting android running well on one of these phones would be a large project in its own right. I certainly wouldn't recommend testing your android apps on it as a first port of call as the problems you uncover are as likely to be with your android port as with your app.
Neither phone has anywhere near sufficient memory.
You need 96-128 mb, preferably more like 256 mb of ram.
Something that was already linux-based would be simplest as you would start by adding the android kernel modifications. Alternatively, something that is a winmo cousin to a vendor's existing android phone and has basically comparable hardware so you can hopefully recycle drivers or leverage an existing porting effort.
But if you need to aquire a phone anyway, get one that already runs android.