Yogesh Chaudhary

So, my name is Yogesh Choudhury, and I pursued my graduation in 2013 with a B. Tech in Information Technology from Ghaziabad, India. In 2014, I was working as an Android developer, and I worked on many projects and applications. In my last organization, AlgoWorks, I was working as a technical lead, where I managed a team of 10 Android developers. Now, in my current organization, Gartner, I work as a senior software engineer, and my roles and responsibilities include end-to-end support and end-to-end development and delivery of the application build. We are working on a Gartner project, where we receive the requirements from the product team, analyze the solution, present it in our technical groups, implement the solution, and then monitor the performance. If there's any critical issue, we resolve it. It's an overall team responsibility, and I'm working on the part of the team. Thank you.

In ASP development, for testing, we can do logging, we can have a logger, Logly is a third-party library, so with the help of Logly, I can check what are the steps or what is the current user's journey to reproduce the bug. Then we have a file called a tombstone, so if there are any critical issues happening, Android or the open-source OS automatically writes those logs to the tombstone file. We can use that and also use Logcat for logging purposes, as well as Mdesk for Linux. We can use Logcat for the logging for Android, and we can use Logcat.grep to find specific logs, because there are millions of logs, so we can use the grep command to filter those logs.

In AOSP, we have SE-Linux policies, and we create services for the open source platform to ensure compatibility. So, if we want to maintain future compatibility, we read the documentation properly before implementing an API, because there may be a situation when it will be deprecated soon, so we don't want that in our case, and we need to go with the basics. Instead of using Android-specific components like support fragment receivers, we should use interfaces, because sticking with core Java concepts is more helpful than going with new APIs or components, which will eventually go deprecated. However, if it's required and we need a handy solution, we can use those APIs as well, depending on the requirements of the implementation in the Android open source platform.

So, in Android, the modification, we have CDT, which is Compatible Device Development Certification from Google. We have CTS tests and we need to pass the CDT, CDD Pass Certification. If we are doing any modifications, if we are going with the standard of Google that is established by Google or any OEM or vendor, right? So, if the vendor specifies certain guidelines and rules, we need to follow all of those. In Android, an example of this is the Tinker Well, let's say Tinker Well 2. I have experience working on the Tinker Well 2 motherboard. If we are going with that, we need to pass all the CDT and CTS tests to ensure that it does not negatively affect security or privacy whenever I'm rewriting a service. I need to have security-enhanced Linux policy files for that, specifically in a.te file where we write security compliance rules. We need to follow all these things and pass the security test for that. In the CDT, there are some pre-defined, pre-written test cases from Google that we need to pass to obtain the security certification or certification, which is required to sell to any OEM or vendor.

so what would you do in India okay so inter-process communication is basically two processes can communicate with each other so Android is basically a Linux-based platform so in that we if we are implementing a new service so we need to create that service and then we need to create the BP file with that service in that BP file we define the service files and source files and then we need to write an IDL for that service so that it can be used by any other like service or the application and then we need to write a security SE Linux policy rule for that service that file we need to write and we need to define those into our manifest file and compile compatibility XML then we can use these are the process to write a new service in Android and if like everything is fine then we can write we can read that service into our application or through our native application so these are the steps so the IDL and the service file so it could be like an interface and we need to have like interfaces defined in IDL so yeah we need to follow all these steps to write a new service in Android.

So, in unit test cases, we can write unit test cases in our Android. There are some predefined unit test cases written in an open-source platform. So we can leverage those as well. We can write our unit test cases like we can use JUnit4, which is the Java library that provides support to write unit test cases in Android, and we can use Mockito to mock objects. This is for when we have any dependency on another class or library, so we can mock the response. Because our unit test cases should have a single response, it should fail due to logic, not due to any other component. So that's why we mock the response, we mock the object, and then if we want to write any instrumentation test cases for that, we can use Espresso. In Espresso, we can write code for views or clicks, and we can do that with the help of the Espresso library. We can leverage both functional and unit test cases to avoid performance bottlenecks. So if we want to see any performance impact, we can use tools like LeakCanary for leak management and memory management, and then we can check app inspection tools for network requests and responses. We can also use the Android Profiler tool to check CPU management or memory management, how much memory our application is consuming. We can check these, and we can write unit test cases and instrumentation test cases in our Android to leverage.

and we are using a for loop 0 to 10 and then we are adding whatever the data we are adding 1 to that data pointer and what is the memory location of that data we are adding 1 plus 1 to that pointer and then we are locking let unwrap so I think the thoughts are wrong with this use of mutex here so I think we can if we are adding the memory location adding into the memory location instead of that we can add to that to the data itself we don't need to add the memory location because the memory location gives us the location of the memory heap location or whatever location it can be in a stack is the right term so if we are adding to it to the memory location so that will increase the like that will not increase the data that will increase the memory location value not the actual data

So, if you want to use a custom reactive data stream, okay, so the reactive data we have, first I'd like to tell you about what I've experienced. I have experience with reactive RxJava and lab data and flows. These I have experience with in Android and Kotlin and Java. So, if you want to implement a custom reactive data stream, I think you can use some annotations. If you want to use a custom reactive interface, you need to listen for the data, observe that data, emit the data, and collect the data like flows. That's a custom reactive data stream in Android you can use, or you can use the Java stream API. I'm not very sure of that, but yeah, we can use that. We can use a combination of the observer pattern or lab data or like we're using in flows, so we can use the same approach to use a custom reactive data stream in Android.

What is proposed to do is the risk of breaking changes and refactoring critical OSP components. So if we are refactoring the critical OSP components, we should avoid making changes or do the minimum changes to the vendor component or the ODM component. So instead of that, we can write our own components in our device folder. That is from the OEM or the custom original device manufacturer, which is the ODM. We can write to the ODM files, not the other files. We can write like this and need to check the test cases to see if they are failing or not. If we make any changes, we need to do them iteratively and have a proper strategy, and we need to have test cases to check if any functionality is breaking. If the test cases are not failing, that means the functionality is not breaking. Instead of directly changing the vendor or Google source code, we need to have our separate component packages and separate subpackages. Then we can write the Android zoom file and Android bb file to add our packages to those in the build process, like this. For testing, we don't need to write whole images. Using the mm command, we can test a module without needing to build the images for all the modules and then test them.

So, inter-process communication related issues, yeah. So in inter-process communication issues, if we are writing our own service in different programming languages, okay. If we are writing our own service, we can have the logging mechanism to our service, we can use that service, we can leverage that service to any programming language, like we can use it in our native application or we can use it in our Android Java application. So, if we are getting any IPC related issues, we need to be sure that if we are passing the SELinux policy, like there is a hash key generated, we need to follow all the security guidelines. We can do the logging mechanism and check if we are all connected with that service is not successful. If there are any log errors, we can check those log errors and use a grep command to find the error in the logs.

So, I have experience working on a separate motherboard, which was a USB motherboard similar to AOSP. We create our customized OS images and then flash those images to that motherboard. We use tools, such as Belina Etcher, to flash the pendrive and then we use fast boot to flash those images to our motherboard. So, we can flash different types of images, like ODM images or vendor images or system images or system EXT images. We can also use tools like log call tools, the logging mechanism, or a separate tool using the logger library or a third-party library. Additionally, we can use directories and tools like full story, or Splunk to see the user journey. I have experience in those tools as well. Thank you.