I want to implement a gateway for handling outgoing calls.
In the latest Android versions 2.x I can do this easily with the hidden ACTION_CALL extra string:
"com.android.phone.extra.GATEWAY_URI"
But in earlier versions, like 1.6, I don't know how to do it. It must be possible because Google Voice is doing it. Can someone please help me?
Thanks,
Emmanuel
Hey Emmanuel,
76% of Devices already run Android 2.x maybe that effort is wasted. Gingerbread is expected to come out by the end of the year, which will push the percentage of 1.6 Devices further down. In less than half a year Android 2.x and higher will by beyond the 80% mark. Just look at the Platform version distribution http://d.android.com/resources/dashboard/platform-versions.html. Maybe have a look at the source code in the Android Open Source Project.
I found the string you mentioned in the InCallScreen.java. Maybe that gives you a way to dig into the older source code to try to figure out if you can access it through some undocumented APIs. But my suggestion would be to not bother with those last 25% of 1.6 devices they will disappear fast.
[Update]
Since it is a requirement to make it work, I would suggest you recompile the Phone App from the git repository and make it debugable that way you can see exactly what is going on. Probably having an ASOP Device running 1.6 would be your best bet to drill deep into how Android is doing it. Basically you would have to back port all the code that is involved in this feature in 2.x back to 1.6. From a time to market perspective I would suggest get the app out with 2.x support and release a second version that is tailored for 1.6. Delaying the release just because of 1.6 seems to be a bad business idea.
That code using the GATEWAY_URI was definitely added in Eclair.
Looking into AOSP, in packages/apps/Phone/src/com/android/phone/InCallScreen.java, that bit of code is completely inexistant in Donut :
// If a provider is used, extract the info to build the
// overlay and route the call. The overlay will be
// displayed the first time updateScreen is called.
if (PhoneUtils.hasPhoneProviderExtras(intent)) {
mProviderLabel = PhoneUtils.getProviderLabel(this, intent);
mProviderIcon = PhoneUtils.getProviderIcon(this, intent);
mProviderGatewayUri = PhoneUtils.getProviderGatewayUri(intent);
mProviderAddress = PhoneUtils.formatProviderUri(mProviderGatewayUri);
mProviderOverlayVisible = true;
if (TextUtils.isEmpty(mProviderLabel) || null == mProviderIcon ||
null == mProviderGatewayUri || TextUtils.isEmpty(mProviderAddress)) {
clearProvider();
}
} else {
clearProvider();
}
I cannot see any alternative. You're best luck maybe to take that Phone application from Donut, add what you need and release it as a new Phone application on Donut devices...
Related
I'd like to make Android Go instead of using AOSP.
But have no information except this site (https://www.android.com/versions/go-edition/)
Please let me know any hint or contact points if any.
Can I compile Android Go from my AOSP code?
Do I need to contact google person to get some right to handle Android GO source code?
Thanks
As long as I know Android Go Edition is a Trimmed down lighten version of AOSP to run on Low-end chips with more optimization in code than AOSP which are tends to run on High-end SoC's but that is done all on Manufacturers side Google don't provide this.
But you can contact Google to know more about it and If you are planning to Launch a device.
Problem: I made an app for the Android 5.1 Platform. I now need to make it compatible with ICS. What is the best way to accomplish that?
I know that I should have set the minSDK to ICS when I started the project, but now I essentially want to change the minSDK in the middle of the project.
I am using android studio as the IDE (latest release).
Since you using minSdk=22 from the beginning Android Studio does not alarm you about incompatibilities issues.
First of all you should change midSdk of course. Than review all the sources for incompatibility warnings like 'using new android api'. Such analysis easily can be done with 'lint'. When you find one do not suppress it with #TargetApi, but write additional code to work around.
Something like:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
do_your_magic();
} else {
add_additional_code_for_pre_lollipop();
}
Looks ugly but this is the world we live in)
Also you may find some 'deprecated methods' warnings, leave them alone, they does not matter for your question.
There can be some other cases. Maybe it will be necessary to include support-v7 and change your Activities. Maybe you using libraries that do not support ICS. Not knowing project details can't help much.
I'm just wondering, if the latest Android SDK installed on a device contains code of all the previous versions as well?
So if I target API level 10 in my app and install it on a device with Lollipop, will it just take and use Gingerbread SDK exactly as it was 3 years ago?
Or is there just one codebase for all versions with a lot of checks and switches which is then run by some kind of compatibility mode picking the correct code and enabling methods of the version of SDK I target?
I read the article about android:targetSdkVersion specified in Manifest but still would like to know how this works internally.
Ok, I just surfed a bit around on the source code (which you can find here: https://github.com/android/platform_frameworks_base). I'm not an engineer of the Android framework, I was just curious about your question and here is what I found.
It does not contain all the different versions of source code. You can imagine that this would result in a nightmare if more and more versions become available. Foremost, you would have different (buggy) versions of the same method without fixing them just to keep them the same.
In the source code, you can find places like these: (see https://github.com/android/platform_frameworks_base/blob/59701b9ba5c453e327bc0e6873a9f6ff87a10391/core/java/com/android/internal/view/ActionBarPolicy.java#L55)
public boolean hasEmbeddedTabs() {
final int targetSdk = mContext.getApplicationInfo().targetSdkVersion;
if (targetSdk >= Build.VERSION_CODES.JELLY_BEAN) {
return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs);
}
// ...
return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs_pre_jb);
}
So the Android developers do the version check in the code where necessary. But these checks are not as necessary as you think (I guess). What's the reason for changing a method?
method is buggy: All they need to do is fix the bug. Tests will make sure that the general behavior of the method keeps the same
method is deprecated: The guys can not remove the method, all they can do is mark it as deprecated and hope for the best. Compilers will do the rest.
method behavior has to change: Well, I guess that is something they can not do easily. They can work around with version codes (which is pretty ugly and becomes a maintenance nightmare), or they just introduce a new API. That's the reason why you'll find a lot of APIs just doing the same
If you have write down a code with latest android sdk and install it in your device. It means actually you are using latest android.jar(you can see android.jar in your project) file while compiling/Executing code.
Now If you install your application in ginger bread device then android.jar(latest) has a backward compatibility(if required) to run code in Gingerbread device.and if you define target sdk version 10 and running app on Higher API level ,then it will run smooth except your compatibility behavior disable in respective device other than targeted devices.
I am making application with target SDK set to 17 and min to 8.
So for some features I have to use Support library v4
Question is how can I test it works on older devices?
I am testing on my phone - which has 4.2.2; and I don't have others with older ones
Will creating emulator with 2.3.3 be true test?
tnx
Update
Just for example: I use Fragment in my code (from android.app, not from support library) - even if my minSDK is 4 - I don't see any warnings...should I?
Yes. It is an emulator (not a simulator) so it is very similar to running your code on the corresponding phone.
Another good practice is to run the Lint tests from times to times, they can detect many common mistakes in your code (including compatibility).
Your ide (both Eclipse & Android Studio plugins do this) will also display warning for obvious calls to functions that don't exist at your chosen min API level.
Most of the time emulator behave same if we consider layout view and
other stuff like look and feel performance , but that can be
difference in case of speed performance and sound quality
.
I found one online tool which are providing that service please go through that link , https://appthwack.com
apache lint (from tools) is the answer - shows all problems
I am a android beginner. I am going through the book listed in the title. I haven't even made it past the first chapter without running into problems. I have installed the latest version of Eclipse. However, the examples shown in the book are not much like my version. For instance, this main.xml file that's supposed to be in the layout folder is not there. The "New Android Project" dialog box is arranged very differently and the package explorer is called project explorer. Is there a way to get this kind of eclipse in the book? Or do I just have to interpret it best I can? Any help would be much appreciated! This question has been down voted and closed by another user. Could someone please tell me why? I am just trying to get some help.
As different Android APIs(ICS, JB, etc.) are released, they sometimes change the ADT (Android Development Tools) for Eclipse. The ADT is plugin for Eclipse. This plugin is what gives you all those neat buttons in the toolbar and the XML layout interaction.
The book you are reading was designed for Android 4.0(Ice Cream Sandwhich). As of right now, Google has released up to Android 4.2.2(JB 4.2). There has been some significant changes to the ADT going from ICS to JB, but in my opinion, they are for the good. Lots of really neat and new features. Here is a Google resource explaining the different API releases for Android: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels
I would say continue reading the book as it will teachs you the basics of Android, but when you want to do some in depth coding, that book isn't going to be very useful and you may have to do a little research online. Reason is, Google releases at least two new versions of Android every year. Every version changes, and adds new features. In other words, the book you are reading is already out of date. Android OS development moves way to fast for authors to keep updating their books.
To answer your question, your probably going to have to interpret it the best you can since, most likely, by June/July, Key Lime Pie is going to out, and the ADT your using NOW will be outdated. You should really learn the fundamentals of Android OS and how it works in the background and how processes things. After that, everything else should be easier to learn.
An alternative to the book you are reading is this: http://developer.android.com/training/basics/firstapp/index.html. This is straight from Google and is constantly updated and tweeked. This will be the most updated and useful information on how to write Android apps.
Hope that helps!