 OK. We will move on to the next talk. The other and Albector are going to give us some insights in using Android in some production environments. OK. I am Teodoro Vadara. I'm a software engineer. And I work at BT Sino, a Le Grand Group company. And I deal with home automation and video door entry system application. Yeah. I'm Alberto Panizzo. I'm co-founder in Amarulla Solutions. We joined the Android since the 2008. And we ported Android to several production-grade devices. And in this case, we helped the Sino to develop the application that Teodoro would describe. Yeah. We are here to describe our experience in developing and managing an application for Android for the class 300x. It's a video, a connected video entry phone that allows you to answer from a call that is generated from the doorbell outside of your door. And you can answer from your home private network as well from the public network mobile. And what happens usually during the development phase? Well, you have your own device or a few set of devices in which you develop and test your application. And you create also a controlled environment in which everything is under your control, the application, the device, and also the network. And then in this controlled environment, you can also have the possibility to deploy and test in real time and get all the information you need in that specific moment. But when we go on the market, we have a different situation. You find different devices. And the spectrum of devices increase exponentially. So you have to manage a lot of OS customization. And because Android APIs doesn't force strict implementation, you can find devices with strange behaviors. So you can control only your application, but you have no control at all on the smartphone, the device, and the network. And all these things create great stability. And this is a very deep fight with an important concept that it's time to market. Here we got to see some interesting cases that we faced. And we tried to give you a solution for each case, and especially a moral guideline to face with these problematics. So, first one. The first one is, so you do deploy the application on the market. And at a certain point, one customer, one user started to complain that the application crashed all the time. So what we did, it was not possible to get the log from this phone and to find for real where the issue was. And so we tried to buy the phone itself. We got the phone from a reseller, and we tried the application on that phone to get the same error. But the application worked on that phone. So this is why apparently it wins. Because the vendor itself was selling the same model of smartphone with two completely different hardware. So we understood this, and we tried to buy a second phone for the same model, hoping that this second phone was the correct hardware. And for chance, it was the correct one. We got the error from the logs, which were a native error itself. We then have been able to create a workaround for this error, and we fixed it. So the thing here is to get all the information possible from the hardware you are running on. And put all the information on your application logs on the Java logs. Because it could be possible that the error, the crash, is on the native layer, and you cannot get the logs from your automated tool to get the logs. So use the class build from Android to get all the information of the hardware and write it on the logs. OK, one biggest problematic in Android was about real-time audio communication. We got crazy to manage it. And then we found out that about 30% of the Android device be different from each other. This is because they can have an hardware eco-canceler, or software eco-canceler, or an eco-canceler at all. Then they have a different latency in jitter time. And another factor is the quality of the speaker. And the microphone that can change also quality in the volume. So here our goal was to have the best audio quality possible. And there is no miracle. There is only one solution that is to declining the source code for each device. So we needed to test a lot of devices in our laboratory. We used an echo chamber in order to tuning the audio for each devices. And for sure the thing that we can say is that if you have had to implement a real-time audio communication and you are not an expert on this field, it's better to relies on high-skill developers. Because here in these fields the most important thing is the experience. So keep in mind this thing. Another case was, yeah. So we got our application and we got it on the market. And the application were working correctly. But right one month later, this deployment on the market, there had been a new version of Android. And this new version it was the Android version 6, which introduced the dose mode and introduced restrictions about getting the unique identifiers of the hardware, like the MAC addresses. In this case, since our application is working on the background because it is an application which needs to get the calls from the server, we were not implementing the push notification round trip, but we were implementing it in the SIP protocol. In this way, the dose mode was preventing our application to reliably get the calls. So customers started to blame our application telling us, it's not working at all. It worked in the last month, but now it is not. So in this way, the new version of Android prevented our application to work. And to cope with the dose mode, the guidelines were to implement the push notification. And this required a big rewrote of the architecture on the overall system, because even the server itself was the part of the push notification round trip. In this way, the lesson to learn is that in between Android versions, the API is not changing dramatically from one version to another, but it is kind of moving. In this way, it is possible from the current API to understand what will be the next restriction applied. In this way, a developer should be updated on the restriction you do have from the operative system and try to not collide, because in subsequent releases you will have more restrictions for sure. As we have said before, time is very critical when you are on the market. And here we are with an example that let us to minimize the disservice in front of the users. And apparently that immediately after a rollout of our application, the app started crashing a lot. And using the automatic tool, the cruciality, that is a tool that you can easily embed in your application, we noticed that we have a peak of crashes. Crashelitics give you a send you an email if there is a crash with all the state trace of the log with a lot of information about, I don't know, the OS version of Android or some other smartphone model and so on. In this case, within 10 minutes from the release on the store of our application, we were alerted that a lot of crashes happened on our application. So we just see the log and we see that the problem was very trivial. It was a null pointer exception. So we did the fix immediately. And we released a new version within one hour from the previous one. So here the lesson is that especially when you go on the market, use always automatic tool that monitor your application in real time. And be careful when you deploy it on the store. This is an example of we avoid big disservice from our system. OK, this is a bit trivial. So at a certain point after a new release, the customer started to complaining that our application is, it was draining too much battery. We were sure about our application, but at a certain point we found out that an external library that we used, so don't trust every time external libraries. So this external library, it was contacting the server, our server, and it was continuously retrying to contact the server. And in this way with kind of an infinity loop. In this way the server itself has reached the maximum number of connections possible and cutting off the communication from all other devices. So we were in that point with a good customer base. So in this way the amount of connections on the server was very, very big. So it has been created this loop that this external library continued to contact the server and keeping the CPU awake and draining the battery. So the solution, it was to patch for sure, to get this external library source code, to patch the library itself. And the lesson here is that, OK, you can do your own dimensioning of the whole system about the server as well. But you cannot control while you are developing the exact number of amount of connections you have on the server. Because errors may increase the load of the servers like of 10,000 times more. OK. Here there is maybe the top five problem we had with our application. One typical issue is about connection. And sometimes the users reported that the audio-video communication doesn't work well. And the problem here is that we don't know where the fault could be. Maybe it could be on the application, on the server, on the device, or also on the network provider side. And here, after doing some analysis on a certain number of problems, this kind of problem, we found out that the same problem always happened in the same country and with the same operator. So here the thing that we did was to contact this operator and asking if there is some traffic shaping within our connection. And they said, yes, we saw that our automatic tool cut down your connection. So here the solution was more simple than we thought. And we only said to them to whitelist our connection. And so all the application started to work well again. The thing that we can say is that if you are about sure on your application server, try first to ask to the network operator if he's doing some traffic shaping. Because in this way you can recover a lot of time. This was another issue related to the different way the Android API is implemented on every devices. Because the Android API is not that strict, especially on the audio. There is an audio library and every vendor are allowed to implement their own way to. There is this kind of freedom there. So in certain models, this was a complete vendor. Following the guidelines of Android to play ringtone for instance, in this way, the ringtone itself, in our case, it was not played good. Because to play the ringtone usually in Android do have to change the mode in the mode ringtone. But we were doing a voice-over-application. And when you do have to manage the calls to reply to answer to a call, to be performance, you do have to warm up the microphone and speakers streams. This warming up about microphone and speaker streams were changing the mode of the library to a certain mode in communication, even if the application itself was not changing the audio mode at Java layer. In this switch were setting the codec volumes in a way that the ringtone itself in the mode ringtone were played very distorted, because it was too high as a volume. So with this vendor, the workaround were to keep the mode in communication for all the time. And when you were supposed to play the ringtone itself, it was proficient only to switch on speakerphone. So it's not like the guidelines of Android will work every time on every devices. For do search in the internet on StarCoverflow or whatever to find out if other people are having the same issues you have. Because it is purely possible that the issue you are facing on a single model, it is a kind of an issue of that model itself, not on your code. OK. Here we are with the last thing about the customer. And we found out that having direct contact with customer is very helpful for you and the customers itself. We put that we had reported problem form in our application. And we see that the customer is beginning to use this form often. And the thing that we have told was that if we don't have any report problem form, probably the customer will put a negative review on the store. Because it's the unique channel of communication. And another thing is to use the beta program, especially when you have to release a version with a specific fix. And we use the beta program to release this new version only to a customer. So we saw the fix if it was OK and there is no regression, then we put on the official store. For example, we had a blind person that contacted us for insert the back functionality into the lock button of our app. So we added it. And then we released this new version only to him. Then when we were sure that there is no regression and no problem, at the end we released this new version on the store. So give the possibility to the customer to have a direct contact with you and use the beta program. Speaking about customer for experience, we can say that you have to listen to the problem that I say to you. But it's better to use your experience, grab all the logs from the problem, and try to use really your experience to resolve the problem. Never trust the one totally to the thing that I say. And it's just blindly one user when the user is telling you the issue. Because the user do tell the issue that the user itself has his truth. But his truth may be not the reality. Because the user try to reproduce the issue his own way, and they may not understand very well how the technology works. So the. Yeah, maybe it can lead you in a wrong path. So it's better to take it with the. She's, I don't know. OK. I think we have a few shots. Thank you. Thank you very much. Any questions? Yes. I suggest that there is a better strategy not to try to guess again, but rather we have a phone with developer preview early in spring. Yeah, the application. Yeah, the question were to get a new phone with the new Android API and test on the new Android API. But this is true, but it could be poll typical as well, because the particular API in the metronome of that phone is not covering the phone. This application usually don't have a master code. Something was removed, like this wife, I think. Yeah. Može in some. Vespoj. Very implemented. Some others were implemented. So that's where it is. Oh, yeah. And this. And. And this. And. And. And. And. And. And. And. And. And. And. And. And. And. And.