Himanshu Mistri

Could you help me understand more about your background by giving a brief introduction to yourself? Hi. I am Himansu Mistri, working as a member of the technical staff at Infochips. I have done my computer engineering in 2011. And since then, I have been working with different organizations as an associate engineer and senior engineer. And then I became a member of the technical staff with 12 years of experience, which includes Android application-level architecture, programming, and all types of unit testing and various tasks. I export Android applications. Also, for the past four to five years, I have been working on one of the medical software kiosk platforms, which is used by our customers in the US. So, it is a huge achievement for us that the medical tablet device has been passed by the FDA. And the medical Android tablet is running on the Android 8.1 operating system, and we are using a Qualcomm processor. You know, it's powered by that tablet. So, we have the vendor partition available in our device tablet, and we need to push our application into the vendor partition as a part of a system app to be considered in the AOSP platform. So, in that software, we have done application programming as well as AOSP programming for various things, like how to implement security. We have implemented security patches in the USB system, and we have also disabled the developer option in the production mode. So, in production mode, the user or anyone cannot turn on the Android system ADB by any chance. So, that is a case of security we are providing, and it is also faster and secure. Boot is also initially in our tablet. Whenever it boots up, it will be loaded into the encryption mode. So, that is one of the encryption methods we have turned on in the AOSP system. And, yeah, how you can implement AOSP. Apart from that, I have worked in domains like medical software, device streaming applications, and managing IoT devices and gathering data analysis reports on the data. So, various tasks, I have also set up Jenkins and DevOps-related operations. I have also performed to set up DevOps in any VM system and then set up automated fetching of the data from the source code and building it into the Android system. And, also, we have done the automated tool flow from Jenkins and Bitbucket as well. So, yeah, these are my skill sets, from the application layer to the AOSP framework layer, I have been working for other engineers, and I am mentoring other people as well. Thank you.

In an ASP environment, how can you identify which API to use and avoid the feature compatibility issue? Okay. So, in order to use any AOSP in the USB environment, I will first look into the AOSP system, which Android OS we are targeting and what are the APIs we are using. For example, if we are using the network API, then I will prefer to go with the current network API recommended by Google and the AOSP communication team. Then I will identify whether this API is marked as stable or not. So, there are different Deepgram annotate tags available in the functions and libraries, which can help us identify whether this API will provide compatibility or not. And, we can also run some tests on our API, and we can also refer to the documentation of the Google team to identify whether it can be duplicated in the future or not. And these are the techniques we can use to identify whether the API will remain actively supported or not. And, there are other details mentioned in the documentation, such as the Android version. This API will be available, and we should always prefer the official development document, which provides comprehensive information about the API, functions, compatibility, and deprecation status as well. And, if our application relies on Google Play services, we need to keep our APIs up to date to ensure compatibility and security. We can implement complex checks to handle this. We also need to make sure we use the appropriate minimum SDK version in Android, set the minimum SDK version in the Android version tag that supports it, and target the latest stable version for optimized performance and compatibility. For future-proofing, we should consider a feature flag, runtime check, and conditional logic to handle API differences across versioning. We should also do certain testing on different Android versions and devices using emulators and physical devices to catch any issues early on. These are the key guidelines for staying up to date with Android platform changes, and we can effectively handle API usage to maintain future compatibility in the AOSP environment.

What practice will I implement to guarantee code quality? Code quality would I distribute that? So, here we are talking about code quality when contributing to a shared USB code base. So, first, I will bother. I will look into that, how it can be, you know, how we have what are the guidelines we have set for our AOSP tree? We should follow the best practices provided by the Android AOSP guidelines. And we should also make sure we use the Git repository and other repo tools that we need to use while working on the shared code base. We should always branch out from the dev branch for different developers so that they can check out a different dev code base. And that should mean we follow the practice of raising bugs, feature requests, and those can raise to PR, raise to a feature request branch, and then once it's tested and stable, we can move further to the production branch. It should be merged. We should follow some of the code guidelines that USB provides while making changes to the USB code base. And whenever our code is completed, we should use the framework build command. Those are the commands we can use to build our stable framework model. As I mentioned earlier, we should add our code to follow the USB standard and formatting rules and best practices followed by the USB community. And we should make sure we write unit testing and integration testing for our code changes. We can use a framework like JUnit to ensure that our code works as expected and does not introduce any bugs or regression or any other code breaking issues. We can also use analytics tools like Android Lint, Findbugs, PMD, and SonarQube to catch potential issues in our code. This tool can help us identify code performance and bottleneck and security vulnerabilities. And we should write clean, concise documentation for the source code that we have contributed to AOSP. And we should also make sure that we follow best practices while coding, and we should not hard-code sensor information directly. And we will also set up a CICD pipeline for making our code build. So, that will help us identify how it doesn't break any build in the AOSP tree.

Yeah. So I think React programming was, today, one of the standard approaches that every software industry follows. So, it is a way where you observe some object. And whenever that object's value changes, you get a reaction on that, and you get a trigger callback from your application. So I think in one of the use cases, I would say, what happened in my experience, we needed to create a service. In that service, we passed some image data from one service to another service. So in that use case, I think React programming solved things. And we used the Rx observer, which we could easily manually synchronize data loading, and we performed the network call into the observable, allowing us to change operations and apply transformations handling. So it used the RxJava observer. What we did, we observed our stream data, and it was passed to the other observable, which was loading the data and consuming the data. And with this, we were able to easily implement our required solution without any bottlenecks or pitfalls in managing things ourselves. And with direct Java error handling callbacks, error handling was straightforward. We could identify error logic earlier, and we used the on error resume and on error return to make our code robust and less error-prone. And with the use of our Rx scheduler, we could make sure that when we wanted to perform UI operations, we could use different schedulers to perform UI-related tasks. And we could use different background IO-related schedulers to perform background tasks. And with RxJava, like operators, and tools, we could help control concurrency, especially when we were dealing with user input or stream data. These forward unnecessary network calls and improved the smoother user experience. And so, yeah, overall, these are some of the reactive approaches that we were able to utilize with the use of libraries like RxJava. And we could also use Kotlin flows if our application was a standalone application layer. Then I think, we can use Kotlin flows as well to make the reactive programming implementation. So, a flow can only emit values, and it can be collected. There are hot and cold flows. A hot flow can start emitting data regardless of collection, but in the case of a cold flow, it can start emitting only after collection.

What approach would you take to ensure unit tests effectively validate the functionality of an Android application and its components? I would prefer to use some libraries like Moco, Mockito, and Android provided test libraries. There are Moko and Mockito libraries to mock objects, and there are other Android provided unit testing libraries. So, we should define these libraries into our Gradle file. When we want to test certain Android-related components, we can use mock objects to mock our input and we can mock different input to validate our function in different use cases and whether it breaks into any condition or not. So, these are a way to pass out different input to our function and it can help us identify whether there are any issues or functionality issues in the Android application component or not. With the use of unit testing, these are one of the ways we can effectively use it. I will use the following modules one by one. Identify the testable component. Identify the components of your application that are suitable for unit testing. Focus on testing the business logic, data processing algorithm separately from the Android framework dependency code, and use the unit testing framework. You need to mock it or use Robolectric, Espresso, or different types of unit tests. For UI testing, we can use Espresso for the testability of the user interface and UI behavior. We can also write isolated testing, focusing on testing a single component function without relying on external dependencies and complex setup. Use the Mockito framework to mock dependencies and create a controlled test environment. Fourth, we can follow the test and don't test behavior and not implement this test behavior and expect the outcome of your component without their internal implementation details. This ensures that the test remains robust even if the implementation changes. This includes different test scenarios, writing tests to cover different scenarios, including edge cases, boundary conditions, success paths, error conditions, testing asynchronous operations, error handling, data validation, and user input validation. For testing Android components that are like Android framework, we can use Robolectric to simulate certain environments. This can help us identify some test cases. Following this approach, you can ensure that unit testing effectively validates the function of your Android application component, leading to a more robust and reliable application experience for the user.

What mechanism you would use to implement custom reactive data, you know, data streaming in an Android application. So, custom implementation for the React data streaming in an Android application, I think this is relay, you know, this is depending on the data types and what are the chunk size of your data. So based on that, we can define the pipeline for how to use that pipeline and how we can identify the dataset that need to be circulated across the reactive stream. So I would use some of the RxJava patterns to reactively observe my data and process that data. And we can use the RxJava streaming and pipelining processor. So that is a way to implement custom React data in Android, they involve using a combination of the React programming concept and Android components. One popular library is RxJava. And in RxJava, you can implement the data stream of the observer contain. And then, to implement our custom into RxJava, we can include RxJava library depending on our data model object that represents the data you want to emit into your reactive stream. This could be your any POJO class or any user data or message or any other things. It can be a custom object. So with the use of a subject class to create a data stream that emits the items of your custom data model, and these are the different subjects you can based on the implement or publish subject, emit items to current subscribers only. A behavior subject emits most recent items to new subscribers and current subscribers, and a replay subject emits all items to current and new subscribers. Our synchronous subject emits only the last item to subscribe after the stream of the object. So defining methods to perform on your data stream, such as adding new items, updating items, deleting items, and filtering based on the criteria, we can include the pipeline filtering as well. And in order to enter the application, subscribe to data streams using the subscribe method. Specify the on next, on error, and on complete callbacks to handle the emitted stream. And we can use for example, a disposable scope and data stream dot subscribe, and then it can handle the items, and then we can have throwable and error handling completion as well. That will make sure that we get the error mechanism being included. And implement error handling logic in the error callback to handle exceptions or errors invited by the stream. So optimally implementing logic in the on complete callback handles the stream. So these are the ways we can separate out the chunk by chunk. One chunk is how we can stream the data, and the second chunk is how we can maintain the subscribers. So we should make sure that we use some weak references or not to be very conscious about the memory use cases as well. So whenever certain subscribers are not needed, then it should call unsubscribe when an activity or fragment is destroyed. So it should subscribe to the stream of the data. And these are the mentioned ways I would use to implement the custom reactive stream.

Okay. Review this Rust code example where we want to implement a safe concurrent access to shared resource and what the wrong use case of mutex here and how it might affect the program. System mutex. Late data mutex 0. Okay. I think from it's like we are using the mutex in the for loop, we are locking the mutex on unwrapping that data. So one thing that it can go wrong is when this program is used by multiple threads, then while running the thread, it might get corrupted or exhibit unreliable behavior. I think we should change the late data to late data mutex. So by this, we can decide the ownership. We should go for proper ownership of the data. And with giving the proper ownership of this code data, it will be more concise, and it will work more practically. So I would change late data into late data mutex so that it will be much easier to give the proper responsibility ownership. And that will help us in rapid coding. Yeah.

How can React programming principle improve the performance and user experience for Android application? I think React programming is providing us to improve our issue criteria related to unnecessary work and handling since you are modifying following this one. So, with the use of React programming, I think the first major thing is it will allow us to make our code more stable, and it will not block any UI threads and things. It will allow asynchronous data loading, and it will allow error handling. It will also allow us to update the UI when necessary, and it will also allow us to do concurrent control. It will focus on data transformation, and it will also focus on test stability. This is the way. And, with asynchronous programming, you can handle asynchronous more efficiently instead of blocking the main UI thread. You can use a reactor to perform network or database queries or any other time-consuming task in a non-blocking thread, and this can prevent the UI from freezing and keep the app responsive. By using React streaming, you can easily update the UI in response to data changes or ensure the reactive library, like RxJava, provides a way to switch between background and UI threads seamlessly and ensure that the UI updates occur on the main thread without causing an error. Reactive programming facilitates the streaming data process and manipulation. You can use operators like map, filter, reduce, map, filter, transform, and manipulate the data stream effectively. This leads to clean and more concise code and improves overall performance. Reactive principles are well-suited for handling errors, handling events, and user interactions. You can use a reactive stream to listen to user input, questions, and send data out. You can see system events and respond according to the enables, creating an interactive and dynamic user interface. Reactive programming allows you to control concurrency and parallelize it effectively. You can use operators like debounce, thread, total first, and delay to manage event emission and prevent redundant updates to the UI and optimize resource usage. This leads to better performance and reduces resource consumption. With the React UI component, you can use labels like Rx binding, Rx data to UI binding, and observe data changes and user input. So, overall, adapting React programming principles using libraries like RxJava, Kotlin Coroutines, you can enhance the performance and responsive user experience of your Android app, leading to happier users and higher ratings.

How would you design a system within AOSP that supports modular update without requiring a full system update? Usually, when you're preparing an AOSP build system, you need to prepare some quota packages for your system to give the update to the user with the changes you're making in the AOSP source code. First, I think we should follow the Google-provided steps on how to create an OTA package for the incremental model using the tool provided in AOSP for packaging the software auto update. When preparing the software auto package, we need to consider important items like defining the engine application within a module and creating beginning identifiable modules that can be updated without affecting features. With the use of the development mechanism to deliver module updates, this can be achieved using in-app downloads, a background service, or push notifications to notify the user about available updates and downloading things. We can also make sure to utilize the update delivery and support incremental updates instead of downloading and installing entire modules. Only download and apply incremental changes and patches to reduce data usage and update time. Overall, I will use the AOSP-provided tools to package the OTA update into an incremental model compared to the previous state, and I will manage the software for the schema into major, minor, and patch versions, like x.y.z. Whenever we update the software patches, we should prepare with the AOSP tool chain. We can prepare the OTA package for only our incremental changes of the OTA. We should also test our incremental OTA update checkings, and after applying our OTA, we should make sure our OTA is thoroughly signed by our AOSP security signature used for our manufacturing OTA or OTA software images files. So, make sure it follows the guidelines provided by Google. And after the auto update is successfully applied, we should run certain CTC test cases on the Android USB system to verify that our updated OTA is working fine and meets the expectation of software quality.

What would be your strategy for implementing a Rust module in Android AOSP while ensuring system integrity? Yeah, so I think in 2021, Google provided an update that supported Rust in AOSP 3 as a system component. So I would follow some key rules for writing any Rust code. First, I would focus on native codes we want to replicate with the Rust module, making sure it properly interoperates with the current schema. I think it should work and integrate with the callback mechanism, like that should be integrated between C++ and other native layers. And then we want to introduce the Rust module, making sure it returns properly compiled code and ensure that between the Rust runtime environment and Android runtime environment, we consider facts such as memory allocation and thread modeling, resource management to ensure smoother runtime behavior as well. And create a JNI bridge between the interface that compiles the Rust shell library from Java code. Define native methods in Java that correspond to functions in the Rust library. Use GNI to load the Rust library, invoke its functions from the Java wrapper. So, we can do that and make sure when compiling the Rust, the ARM toolchain of the correct Android target system is used. So it will be better, like comparing your score to native shared libraries. Use Cargo and Rust package manager and build system to manage dependencies and build the Rust code targeting the Android architecture, like ARM 64 or Android x86-64. Based on that compatibility, we should also make sure the data types we are using are compatible with the ones provided by Google when they introduced Rust into the Android system. And, yeah, some things might be limited, like mutexes, but those are the minimum supported Rust packages we can easily use this time. And there are certain ways we use the Rush library and Rush binaries and Rush probe macro, which are defined procedures for external, extended compiling. There are typical for internal compiler use cases, so we should follow them and generate the executive binding directly from cross code. This is a cautionary note, and binding might require extra security checks as well. And create a statically linked library, rlib, which is the most common and secure option for internal use within Android AOSP.

If we task with integrating C++ code within a AOSP, if we task with integrating C++ code within the USB performance, integral module, how do you ensure compatibility and stability of the system? So, yeah, I think whenever we need to write a module in C++ within a USB, we need to make sure that our C++ code follows the some of the code guidelines provided by the C++ standard library. We should also check which AOSP version we are using and what C++ standard library is available in our AOSP toolchain and which version we can tag in, whether it is C++11, C++14, and also check those items first for the security. So if this is the one way to identify your C++ code, and we can utilize at the entry level point of the coding. So when we write a C++ module, then we should make sure that it is well-compiled and well-followed to the language standard available in C++. And we should also make sure that performance-related tasks we should make sure we do the proper unlock and lock whenever we don't need it. We need to make sure that we create a Java interface bridge from within a compiled C++ library to Java, and define the native method in Java that corresponds to functions in the C++ library. We can use NDK to load the C++ library and invoke its functions from Java. And make sure the data handling conversion is proper between Java and C++ using general data types. We should use functions to pass data primitive types between Java and C++ and pay attention to memory alignment to avoid memory leaks and data corruption. We should also make sure to manage dependencies between Java and C++ to ensure that the initial data structures and resources are synchronized and managed correctly to prevent conflicts and risk conditions between the two languages. And we should also make sure to ensure compatibility with the C++ runtime environment, Android runtime environment like ARM. We should consider factors such as memory allocation, thread modeling, exception handling, and resource management to ensure smoother runtime behavior. And we should pay attention to security integration with the native C++ into Java as well. We should follow security coding practices, input validation, access control mechanisms to prevent vulnerabilities such as buffer overflows, memory corruption, or injection attacks. So by following this strategy and best practices, you can fully integrate C++ within open-source AOSP, performing critical operations that add to the compatibility, stability, and optimization performance into the system.