We started the year with a new series of internal meetings!
The role of these meetings is to share technical information and personal experiences between colleagues belonging to different departments. Because knowledge is power, we believe it is important for us to learn more about what the others are doing for their projects, as this may contribute to a better understanding of that project and of the technology as a whole. This means that if someone will come across a similar issue in the same or a different project, they will know how to tackle the problem. Moreover, this is not just about sharing information, but also about networking. We exchange knowledge and have fun while doing it. Pizza and drinks were obviously also part of the game. At the end, we all gathered together and spent time discussing the topics while playing games.
But to leave the „fun” part aside now, let’s move on to the serious stuff. In this session, our speakers covered the following topics:
This topic depicts a comparison between structs and classes in Swift, but it also explains why you should adopt structs. If you have an Objective-C background, you tend to use classes all over the code without benefiting of the Swift features.
We experienced some problems in the beginning of a project and we decided to change the working style and how we worked.
The adopted small changes were highly effective:
Having iOS, Android, and Frontend installed on the backend machine. Our colleagues from iOS, Android, and frontend departments helped the backend team to install the project and emulators in which we replace the INT address with the localhost. This way, we got rid of painfully having to use Postman for each call. Everything could be tested and integrated, and this definitely helped us understand the business.
Making Swagger meetings and being API First, focusing on the models and how URLs should be. We edited the Swagger before we started coding so that the iOS, Android and frontend parts were not blocked by the backend. We made this possible using the ngrok app.
In this short presentation, I showcase my (brief) experience with Android Security issues: the problems I had to solve, the mistakes I made and the solutions that proved to be right. I take a short look at hashing, root access, decompiling, Android Keystore and how to use it. I also propose a solution for simplifying encryption using the Android Keystore across Android versions.
The presentation starts with a story of a professor who was building a robot. The purpose of the story is to present dependency injection. The most popular solution used in Android (Dagger 2) is presented with its ups and downs. It was then compared to one of its newer competitors, the Koin library. In contrast to Dagger, Koin impressed with a very simple integration system, and a short DSL (domain specific language). The mobility to use it in each of the MVP and also MVVM architectures was revealed with some simple and clear examples, which prove that integrating Koin is as easy as „flipping a coin”.
Since Android 8.0, major modifications have been done to the lower layers of the Android OS. Named Project Treble, this is a major architecture rewrite of Android’s inner workings, creating a proper separation between vendor provided driver code, and the higher levels of the operating system. These optimisations allow the upgrade of the operating system without recompiling the drivers, which are now kept in a custom /vendor partition.
In this presentation, we take a look at custom system services: the proper way to create, add, and start them, as well as the way to communicate with them and trigger the functionality contained. This functionality can be HIDL-based (Hardware Interface Definition Language), which handles hardware interaction, or simple AIDL-based (Android Interface Definition Language) software services.
The last step is to configure SELinux (Security-Enforced Linux), a component of Android OS which handles Mandatory Access Control (MAC) across all processes, to give the right permissions to the newly added system service.
In the coming weeks, part of a 2-hour workshop, we will be implementing a software-based system service.
