By Omar El Sheikh, Android Engineer
Francesco Carucci, Developer Advocate
Vulkan provides developers with the power to specify much more information to devices about rendering state compared to OpenGL. With that power though comes some new responsibilities; developers are expected to explicitly implement things that in OpenGL were handled by the driver. One of these things is device orientation and its relationship to render surface orientation. Currently, there are 3 ways that Android can handle reconciling the render surface of the device with the orientation of the device :
There currently isn't a way for an application to know whether surface rotation handled outside of the application will be free. Even if there is a DPU to take care of this for us, there will still likely be a measurable performance penalty to pay. If your application is CPU bound, this becomes a huge power issue due to the increased GPU usage by the Android Compositor which usually is running at a boosted frequency as well; and if your application is GPU bound, then it becomes a potentially large performance issue on top of that as the Android Compositor will preempt your application's GPU work causing your application to drop its frame rate.
On Pixel 4XL, we have seen on shipping titles that SurfaceFlinger (the higher-priority task that drives the Android Compositor) both regularly preempts the application’s work causing 1-3ms hits to frametimes, as well as puts increased pressure on the GPU’s vertex/texture memory as the Compositor has to read the frame to do its composition work.
Handling orientation properly stops GPU preemption by SurfaceFlinger almost entirely, as well as sees the GPU frequency drop 40% as the boosted frequency used by the Android Compositor is no longer needed.
To ensure surface rotations are handled properly with as little overhead as possible (as seen in the case above) we recommend implementing method 3 - this is known as pre-rotation. The primary mechanism with which this works is by telling the Android OS that we are handling the surface rotation by specifying in the orientation during swapchain creation through the passed in surface transform flags, which stops the Android Compositor from doing the rotation itself.
Knowing how to set the surface transform flag is important for every Vulkan application, since applications tend to either support multiple orientations, or support a single orientation where its render surface is in a different orientation to what the device considers its identity orientation; For example a landscape-only application on a portrait-identity phone, or a portrait-only application on a landscape-identity tablet.
In this post we will describe in detail how to implement pre-rotation and handle device rotation in your Vulkan application.
To handle device rotation in your app, change the application’s AndroidManifest.xml to tell Android that your app will handle orientation and screen size changes. This prevents Android from destroying and recreating the Android activity and calling the onDestroy() function on the existing window surface when an orientation change occurs. This is done by adding the orientation (to support API level <13) and screenSize attributes to the activity’s configChanges section:
onDestroy()
orientation
screenSize
<activity android:name="android.app.NativeActivity" android:configChanges="orientation|screenSize">
If your application fixes its screen orientation using the screenOrientation attribute you do not need to do this. Also if your application uses a fixed orientation then it will only need to setup the swapchain once on application startup/resume.
The next thing that needs to be done is to detect the device’s screen resolution that is associated with the VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR as this resolution is the one that the Swapchain will always need to be set to. The most reliable way to get this is to make a call to vkGetPhysicalDeviceSurfaceCapabilitiesKHR() at application startup and storing the returned extent - swapping the width and height based on the currentTransform that is also returned in order to ensure we are storing the identity screen resolution:
VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
vkGetPhysicalDeviceSurfaceCapabilitiesKHR()
VkSurfaceCapabilitiesKHR capabilities; vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities); uint32_t width = capabilities.currentExtent.width; uint32_t height = capabilities.currentExtent.height; if (capabilities.currentTransform & VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR || capabilities.currentTransform & VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR) { // Swap to get identity width and height capabilities.currentExtent.height = width; capabilities.currentExtent.width = height; } displaySizeIdentity = capabilities.currentExtent;
displaySizeIdentity is a VkExtent2D that we use to store said identity resolution of the app's window surface in the display’s natural orientation.
displaySizeIdentity
To know when the application has encountered an orientation change, the most reliable means of tracking this change involves checking the return value of vkQueuePresentKHR() and seeing if it returned VK_SUBOPTIMAL_KHR
vkQueuePresentKHR()
VK_SUBOPTIMAL_KHR
auto res = vkQueuePresentKHR(queue_, &present_info); if (res == VK_SUBOPTIMAL_KHR){ orientationChanged = true; }
One thing to note about this solution is that it only works on devices running Android Q and above as that is when Android started to return VK_SUBOPTIMAL_KHR from vkQueuePresentKHR()
orientationChanged is a boolean stored somewhere accessible from the applications main rendering loop
orientationChanged
For devices running older versions of Android below 10, a different implementation is needed since we do not have access to VK_SUBOPTIMAL_KHR.
VK_SUBOPTIMAL_KHR.
On pre-10 devices we can poll the current device transform every pollingInterval frames, where pollingInterval is a granularity decided on by the programmer. The way we do this is by calling vkGetPhysicalDeviceSurfaceCapabilitiesKHR() and then comparing the returned currentTransform field with that of the currently stored surface transformation (in this code example stored in pretransformFlag)
pollingInterval
currentTransform
pretransformFlag
currFrameCount++; if (currFrameCount >= pollInterval){ VkSurfaceCapabilitiesKHR capabilities; vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities); if (pretransformFlag != capabilities.currentTransform) { window_resized = true; } currFrameCount = 0; }
On a Pixel 4 running Android Q, polling vkGetPhysicalDeviceSurfaceCapabilitiesKHR() took between .120-.250ms and on a Pixel 1XL running Android O polling took .110-.350ms
A second option for devices running below Android 10 is to register an onNativeWindowResized() callback to call a function that sets the orientationChanged flag to signal to the application an orientation change has occurred:
onNativeWindowResized()
void android_main(struct android_app *app) { ... app->activity->callbacks->onNativeWindowResized = ResizeCallback; }
Where ResizeCallback is defined as:
ResizeCallback
void ResizeCallback(ANativeActivity *activity, ANativeWindow *window){ orientationChanged = true; }
The drawback to this solution is that onNativeWindowResized() only ever gets called on 90 degree orientation changes (going from landscape to portrait or vice versa), so for example an orientation change from landscape to reverse landscape will not trigger the swapchain recreation, requiring the Android compositor to do the flip for your application.
To actually handle the orientation change, we first have a check at the top of the main rendering loop for whether the orientationChanged variable has been set to true, and if so we'll go into the orientation change routine:
bool VulkanDrawFrame() { if (orientationChanged) { OnOrientationChange(); }
And within the OnOrientationChange() function we will do all the work necessary to recreate the swapchain. This involves destroying any existing Framebuffers and ImageViews; recreating the swapchain while destroying the old swapchain (which will be discussed next); and then recreating the Framebuffers with the new swapchain’s DisplayImages. Note that attachment images (depth/stencil images for example) usually do not need to be recreated as they are based on the identity resolution of the pre-rotated swapchain images.
OnOrientationChange()
void OnOrientationChange() { vkDeviceWaitIdle(getDevice()); for (int i = 0; i < getSwapchainLength(); ++i) { vkDestroyImageView(getDevice(), displayViews_[i], nullptr); vkDestroyFramebuffer(getDevice(), framebuffers_[i], nullptr); } createSwapChain(getSwapchain()); createFrameBuffers(render_pass, depthBuffer.image_view); orientationChanged = false; }
And at the end of the function we reset the orientationChanged flag to false to show that we have handled the orientation change.
In the previous section we mention having to recreate the swapchain. The first steps to doing so involves getting the new characteristics of the rendering surface:
void createSwapChain(VkSwapchainKHR oldSwapchain) { VkSurfaceCapabilitiesKHR capabilities; vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities); pretransformFlag = capabilities.currentTransform;
With the VkSurfaceCapabilities struct populated with the new information, we can now check to see whether an orientation change has occurred by checking the currentTransform field and store it for later in the pretransformFlag field as we will be needing it for later when we make adjustments to the MVP matrix.
VkSurfaceCapabilities
In order to do so we must make sure that we properly specify some attributes within the VkSwapchainCreateInfo struct:
VkSwapchainCreateInfo
VkSwapchainCreateInfoKHR swapchainCreateInfo{ ... .sType = VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR, .imageExtent = displaySizeIdentity, .preTransform = pretransformFlag, .oldSwapchain = oldSwapchain, }; vkCreateSwapchainKHR(device_, &swapchainCreateInfo, nullptr, &swapchain_)); if (oldSwapchain != VK_NULL_HANDLE) { vkDestroySwapchainKHR(device_, oldSwapchain, nullptr); }
The imageExtent field will be populated with the displaySizeIdentity extent that we stored at application startup. The preTransform field will be populated with our pretransformFlag variable (which is set to the currentTransform field of the surfaceCapabilities). We also set the oldSwapchain field to the swapchain that we are about to destroy.
imageExtent
preTransform
surfaceCapabilities
oldSwapchain
It is important that the surfaceCapabilities.currentTransform field and the swapchainCreateInfo.preTransform field match because this lets the Android OS know that we are handling the orientation change ourselves, thus avoiding the Android Compositor.
surfaceCapabilities.currentTransform
swapchainCreateInfo.preTransform
The last thing that needs to be done is actually apply the pre-transformation. This is done by applying a rotation matrix to your MVP matrix. What this essentially does is apply the rotation in clip space so that the resulting image is rotated to the device current orientation. You can then simply pass this updated MVP matrix into your vertex shader and use it as normal without the need to modify your shaders.
glm::mat4 pre_rotate_mat = glm::mat4(1.0f); glm::vec3 rotation_axis = glm::vec3(0.0f, 0.0f, 1.0f); if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR) { pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(90.0f), rotation_axis); } else if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR) { pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(270.0f), rotation_axis); } else if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_180_BIT_KHR) { pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(180.0f), rotation_axis); } MVP = pre_rotate_mat * MVP;
If your application is using a non-full screen viewport/scissor region, they will need to be updated according to the orientation of the device. This requires that we enable the dynamic Viewport and Scissor options during Vulkan’s pipeline creation:
VkDynamicState dynamicStates[2] = { VK_DYNAMIC_STATE_VIEWPORT, VK_DYNAMIC_STATE_SCISSOR, }; VkPipelineDynamicStateCreateInfo dynamicInfo = { .sType = VK_STRUCTURE_TYPE_PIPELINE_DYNAMIC_STATE_CREATE_INFO, .pNext = nullptr, .flags = 0, .dynamicStateCount = 2, .pDynamicStates = dynamicStates, }; VkGraphicsPipelineCreateInfo pipelineCreateInfo = { .sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO, ... .pDynamicState = &dynamicInfo, ... }; VkCreateGraphicsPipelines(device, VK_NULL_HANDLE, 1, &pipelineCreateInfo, nullptr, &mPipeline);
The actual computation of the viewport extent during command buffer recording looks like this:
int x = 0, y = 0, w = 500, h = 400; glm::vec4 viewportData; switch (device->GetPretransformFlag()) { case VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR: viewportData = {bufferWidth - h - y, x, h, w}; break; case VK_SURFACE_TRANSFORM_ROTATE_180_BIT_KHR: viewportData = {bufferWidth - w - x, bufferHeight - h - y, w, h}; break; case VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR: viewportData = {y, bufferHeight - w - x, h, w}; break; default: viewportData = {x, y, w, h}; break; } const VkViewport viewport = { .x = viewportData.x, .y = viewportData.y, .width = viewportData.z, .height = viewportData.w, .minDepth = 0.0F, .maxDepth = 1.0F, }; vkCmdSetViewport(renderer->GetCurrentCommandBuffer(), 0, 1, &viewport);
Where x and y define the coordinates of the top left corner of the viewport, and w and h define the width and height of the viewport respectively.
x
y
w
h
The same computation can be used to also set the scissor test, and is included below for completeness:
int x = 0, y = 0, w = 500, h = 400; glm::vec4 scissorData; switch (device->GetPretransformFlag()) { case VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR: scissorData = {bufferWidth - h - y, x, h, w}; break; case VK_SURFACE_TRANSFORM_ROTATE_180_BIT_KHR: scissorData = {bufferWidth - w - x, bufferHeight - h - y, w, h}; break; case VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR: scissorData = {y, bufferHeight - w - x, h, w}; break; default: scissorData = {x, y, w, h}; break; } const VkRect2D scissor = { .offset = { .x = (int32_t)viewportData.x, .y = (int32_t)viewportData.y, }, .extent = { .width = (uint32_t)viewportData.z, .height = (uint32_t)viewportData.w, }, }; vkCmdSetScissor(renderer->GetCurrentCommandBuffer(), 0, 1, &scissor);
If your application is using derivative computations such as dFdx and dFdy, additional transformations may be needed to account for the rotated coordinate system as these computations are executed in pixel space. This requires the app to pass some indication of the preTransform into the fragment shader (such as an integer representing the current device orientation) and use that to map the derivative computations properly:
In order for your application to get the most out of Vulkan on Android, implementing pre-rotation is a must. The most important takeaways from this blogpost are:
Here is a link to a minimal example of pre-rotation being implemented for an android application:
https://github.com/google/vulkan-pre-rotation-demo
Native code in memory-unsafe languages like C and C++ is often vulnerable to memory corruption bugs. Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android.
In previous years our memory bug detection efforts were focused on Address Sanitizer (ASan). ASan catches these errors but causes your app to use 2x-3x extra memory and to run slower.
To better tackle these problems we’ve developed Hardware-Assisted Address Sanitizer (HWASan). HWASan typically only requires 15% more memory. It’s also a lot faster than ASan. HWASan’s performance makes it usable not only for unit testing, but also for interactive human-driven testing. We use this to find memory issues in the Android OS itself, and now we've made it easy for app developers to use it too. HWASan is fast enough that some Android developers use it on their development devices for everyday tasks.
HWASan is based on memory tagging and depends on the Top Byte Ignore feature present in all 64-bit ARM CPUs and the associated kernel support. Every memory allocation is assigned a random 8-bit tag that is stored in the most significant byte (MSB) of the address, but ignored by the CPU. As a result, this tagged pointer can be used in place of a regular pointer without any code changes.
Under the hood, HWASan uses shadow memory - a sparse map that assigns a tag value to each 16 byte block of program memory. Compile time code instrumentation is used to insert checks that compare pointer and memory tags for every memory access, and raise an error if they do not match.
This approach allows us to detect both use-after-free and buffer-overflow types of bugs. The memory tag in the shadow is changed to a random value during allocation and deallocation. As a result, attempting to access deallocated memory with a dangling pointer will almost certainly fail due to a tag mismatch. The same is true for an attempt to access memory outside of the allocated region, which is very likely to have a different tag. Stack and global variables are similarly protected.
Use-after-free bug detection with memory tagging.
This approach is non deterministic: because of the limited number of possible tags, an invalid memory access has 1 chance out of 256 (approximately 0.4%) to pass undetected. We have not observed this as a problem in practice, but, due to the tag randomness, running the program the second time is very likely to find any bugs that the first run has missed.
An advantage of HWASan over ASan is its ability to find bugs that happen far from their origination point - for example, a use-after-free where the memory is accessed long after it has been deallocated, or a buffer overflow with a large offset. This is not the case with ASan, which uses red zones around memory allocations, and a quarantine for the temporary storage of recently deallocated memory blocks. Both redzones and the quarantine are of limited size, and error detection is unlikely beyond that. HWASan uses a different approach that does not have these limitations.
When a bug is discovered the process is terminated and a crash dump is printed to logcat. The “Abort message” field contains a HWASan report, which shows the access type (read or write), access address, thread id and the stack trace of the bad memory access. This is followed by a stack trace for the original allocation, and, for use-after-free bugs, a stack trace showing where the deallocation took place. Advanced users can find extra debugging information below this, including a map of memory tags for nearby locations.
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr -------- Abort message: '==21586==ERROR: HWAddressSanitizer: tag-mismatch on address 0x0042a0807af0 at pc 0x007b23b8786c WRITE of size 1 at 0x0042a0807af0 tags: db/19 (ptr/mem) in thread T0 #0 0x7b23b87868 (/data/app/com.example.myapp/lib/arm64/native.so+0x2868) #1 0x7b8f1e4ccc (/apex/com.android.art/lib64/libart.so+0x198ccc) [...] 0x0042a0807af0 is located 0 bytes to the right of 16-byte region [0x0042a0807ae0,0x0042a0807af0) allocated here: #0 0x7b92a322bc (/path/to/libclang_rt.hwasan-aarch64-android.so+0x212bc) #1 0x7b23b87840 (/data/app/com.example.myapp/lib/arm64/native.so+0x2840) [...]
An example snippet from a HWASan crash report.
Google uses HWASan extensively in Android development, and now you can too. Find out more -- including the details of how to rebuild your app for use with HWASan -- at https://developer.android.com/ndk/guides/hwasan. Prebuilt HWASan system images are available on the AOSP build server (or you can build your own). They can be easily flashed onto a compatible device using the recently announced web flash tool.
Posted by Andrew Ahn, Product Manager, Google Play + Android App Safety
Google Play connects users with great digital experiences to help them be more productive and entertained, as well as providing app developers with tools to reach billions of users around the globe. Such a thriving ecosystem can only be achieved and sustained when trust and safety is one of its key foundations. Over the last few years we’ve made the trust and safety of Google Play a top priority, and have continued our investments and improvements in our abuse detection systems, policies, and teams to fight against bad apps and malicious actors.
In 2019, we continued to strengthen our policies (especially to better protect kids and families), continued to improve our developer approval process, initiated a deeper collaboration with security industry partners through the App Defense Alliance, enhanced our machine learning detection systems analyzing an app’s code, metadata, and user engagement signals for any suspicious content or behaviors, as well as scaling the number and the depth of manual reviews. The combination of these efforts have resulted in a much cleaner Play Store:
In addition we’ve launched a refreshed Google Play Protect experience, our built-in malware protection for Android devices. Google Play Protect scans over 100B apps everyday, providing users with information about potential security issues and actions they can take to keep their devices safe and secure. Last year, Google Play Protect also prevented more than 1.9B malware installs from non-Google Play sources.
While we are proud of what we were able to achieve in partnership with our developer community, we know there is more work to be done. Adversarial bad actors will continue to devise new ways to evade our detection systems and put users in harm's way for their own gains. Our commitment in building the world's safest and most helpful app platform will continue in 2020, and we will continue to invest in the key app safety areas mentioned in last year’s blog post:
Our teams of passionate product managers, engineers, policy experts, and operations leaders will continue to work with the developer community to accelerate the pace of innovation, and deliver a safer app store to billions of Android users worldwide.
Posted by Leo Sei, Product Manager on Android
Back in 2017, we released D8, a new faster dexing compiler to replace DX, producing smaller APKs. In April 2018, we announced D8 as the default option in Android Studio 3.1.
In that announcement, we laid out 3 phases to deprecate DX and we are now entering phase 2:
“Once we've seen a six month window without major regressions from DX to D8, we'll enter the second phase. This phase will last for a year, and is intended to ensure that even complex projects have lots of time to migrate. During this phase, we'll keep DX available, but we'll treat it as fully deprecated; we won't be fixing any issues.”
If you haven’t already, it is now the time to migrate to D8 (see details in the previous post). As always, if you encounter issues, please do let us know!
Next steps
On Feb 1st, 2021, we’ll move to step 3, removing DX fully from Android Studio and any other build environments.
Note: This post is about DX only (and does not include shrinking tools)
Posted by Mitchell Wills, Android Build Software Engineer
AOSP has been around for a while, but flashing builds onto a development device has always required a number of manual steps. A year ago we launched Android's Continuous Integration Dashboard, which gives more visibility into the continuous build status of the AOSP source tree. However, these builds were not available for phones and flashing devices still required a manual command line process.
In order to support developers working in AOSP we are launching Android Flash Tool, which allows developers to flash devices with builds listed on the Continuous Integration Dashboard. This can be used by developers working on the Android OS to test changes or App developers to test compatibility with the latest AOSP build.
A device being flashed.
Android Flash Tool allows anyone to use a browser supporting WebUSB, such as Chrome 79 or Edge 79, to flash an Android device entirely from the browser (Windows requires installing a driver). After connecting a device and authorizing the page to connect to it users will be presented with a list of available builds. After choosing a build click flash and the tool does the rest. You can flash recent Pixel devices and the HiKey reference boards with builds based on aosp-master.
Try Android Flash Tool yourself at https://flash.android.com.
Find out more at https://source.android.com/setup/contribute/flash.
Posted by Kacey Fahey, Games Developer Marketing, Google
Cross-posting from the Google Developers Blog.
Google has lots to share with the game development community at the Game Developers Conference (GDC) in March. Check out our plans and sign up to keep up to date with the latest GDC news and announcements from Android, Google Play, Firebase, and more.
For one week, tens of thousands of creators from the gaming community come together at GDC to hear the latest industry innovations and network with peers to enable better gaming experiences for players around the world.
Below is a preview of what to expect from Google, and remember, it’s just the beginning. Don’t forget to sign up for our newsletter as we reveal more leading up to the event, or you can check out our website, Google for Games at GDC.
We will start the week with the Google for Games Keynote on Monday, March 16 at 9:30 am PST. Join the livestream and learn about the latest tools and solutions to help game developers create great games, connect with players, and scale their businesses.
Google Developer Keynote photo at GDC 2019
We have two days of in-depth sessions where you can uplevel your skills across Google products and solutions. Topics range from new tools to optimize game development, how to reach more devices and players, using new Firebase features to alleviate infrastructure management challenges, and much more.
Learn more about the Google Developer Summit we’ll be hosting on March 16 -17 and how you can join in person with an official GDC ticket or via livestream.
We’ll be sharing more details about everything we have planned at GDC in the coming weeks so be sure to sign up to be among the first to hear the latest updates, and save the date to watch the keynote and other Developer Summit sessions at g.co/gdc2020.
More to come soon!
The Google for Games team
*On-site events are part of the official Game Developers Conference and require a pass to attend.
Posted by Patricia Correa, Director, Developer Marketing
The indie developer community released several fantastic titles on Google Play during 2019, showing the technical skill and innovative design that makes them an essential part of the gaming landscape.
To continue helping indie developers thrive, today we’re announcing the 2020 edition of our annual Google Play Indie Games Festival. This year we will host three competitions for developers from several European countries*, Japan, and South Korea.
Prizes are designed to help you grow your business, including:
The contests are open to developers from selected countries, with no more than 50 employees. The submitted game must be new, released at least in open beta between May 7, 2019 and March 2, 2020. See other requirements in the terms and conditions for each of the contests.
Simply fill out the relevant form by clicking here. Submissions are open until March 2, 2020, at 3pm CET.
The Top 20 entries in each region will be announced in March and invited to showcase at the Festival events where the field will be narrowed to 10 by the event audience, industry experts and the Google team. The Top 10 will present their games on stage and the 3 winners will be selected.
Even if you’re not submitting a game to the competitions, we’d love to see you at one of the Festival events on the 25th of April 2020.
Learn more and sign up on g.co/play/indiefestival
* The European competition is open to developers from the following countries: Austria, Belgium, Belarus, Bulgaria, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hungary, Israel, Italy, Latvia, Lithuania, Netherlands, Norway, Poland, Portugal, Romania, Russia, Slovakia, Slovenia, Spain, Sweden, Turkey, Ukraine, and the United Kingdom (including Northern Ireland).
How useful did you find this blog post?
★ ★ ★ ★ ★
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
