I built a simple tool, shortcut.cool, to create custom launchers for Android using the web. It leverages the power of PWAs, service workers, and the web app manifest, specifically the shortcuts feature. The tool allows you to define a set of .new domain shortcuts, which then get encoded into the URL. This URL points to a dynamically generated manifest file that Chrome uses to install the PWA with the specified shortcuts on your home screen. The project is a bit of an experiment and has some limitations, like the inability to update existing PWAs and potential security concerns from URL-encoded data. However, it’s a fun example of how the web can be used to create quick, personalized tools.
For years, I thought bookmarklets weren't supported on Chrome for Android. Turns out, they are! You just need to access your bookmarks through the address bar, not the Bookmarks menu. This method retains the page context, allowing your bookmarklets to execute JavaScript properly. This opens up new possibilities for customizing web pages on Android.
Mobile devices lack the bookmarklet functionality found in desktop browsers. However, the ShareTarget API offers a potential workaround. This API allows web apps to be installed and receive native share actions, similar to how the Twitter PWA handles shared links and files. By leveraging this API, developers can create mini-apps that perform actions on shared data. This approach involves defining how to receive data in a manifest file and handling the request in a service worker. I've created examples for Hacker News, Reddit, and LinkedIn demonstrating how to utilize the ShareTarget API. While not a perfect replacement for desktop bookmarklets, this offers a new level of hackability for mobile web experiences.
I created Quick LogCat, a web tool for debugging Android devices without needing adb installed. It uses WebADB.js and the WebUSB API to connect to your device and display logcat output. The tool is useful for on-the-go debugging. It's powerful but also highlights the potential security implications of granting web access to USB devices. This technology opens up exciting possibilities like firmware updates and app sideloading via web interfaces. I'm curious to see what others build with WebUSB and adb access.
The File Web Share Target API is a new, powerful feature in Chrome Canary that allows web apps to receive files (like images) shared from other apps, much like native apps. This post details how I implemented this API on my blog, enabling direct image uploads from my Android camera app. The process involves declaring support for file sharing in your web app manifest and handling the incoming file data in a service worker. The API uses a progressive approach, leveraging standard form POST requests, making integration relatively simple. This feature significantly enhances web app integration with the host operating system, closing the gap between web and native apps.
This blog post is a test of the Android Share Target API and its file sharing capabilities. If the image displays successfully, the test is considered successful.
I've encountered a bug in Chrome on Android where MediaRecorder, using Canvas.captureStream(), fails to encode video from large canvas elements (e.g., 1280x720). While the process works on desktop Chrome, on Android, the recording stops abruptly at unpredictable points, likely due to limitations in the MediaRecorder API's encoding capabilities. A smaller canvas (640x480) works fine, suggesting resolution-based limitations. I've reported this as Chrome bug 897727 and created a demo to illustrate the issue.
This post discusses the problem of content silos on the web, particularly how native apps dominate sharing functionalities, limiting the web's reach. It highlights the irony of navigator.share, which, while enabling web sharing, still directs users towards native apps. The post emphasizes the need for the web to participate more actively in user interactions. It celebrates the 'Improved add to home-screen' feature for PWAs on Android, generating APKs and making them function more like native apps. Finally, it introduces the promising 'Share Target API', allowing PWAs to receive shared content, including links, thus breaking down silos and fostering a more inclusive web ecosystem.
I'm excited to share a new, simple API for sharing on the web called navigator.share! It's available in Chrome Dev Channel on Android and allows websites to connect with native apps for sharing. This is a step towards a better inter-app communication system, simplifying sharing and potentially extending to other app interactions. You can try it now on my blog by clicking the share button. I've updated my blog to use it, falling back to my existing solution if the API isn't available. Check out the ChromeStatus page and other linked resources for more information and give us feedback!
In a previous post, I discussed screen recording from Android. This post details how I automated the process of adding a device frame to those recordings, making them look more professional. Previously, this was a tedious manual process involving Screenflow, but now I've automated it using ffmpeg. The ffmpeg command scales the screen recording and overlays it onto a background image of a device frame. The code, available on GitHub, handles the entire process, including setting up the Android device for recording, pulling the recording, and applying the frame. While the current solution works well, I'm open to suggestions for improvement from ffmpeg experts.
This post revisits the UX issues that contributed to the demise of Web Intents. We never adequately addressed the wide array of potential actions and data types, leading to a generic and confusing user experience. Handling data return from a long-running operation in another app proved problematic, especially if the initiating app closed. The lack of an explicit API for expecting returned data, similar to Android's startActivityForResult, further hindered the development of intuitive UI affordances. The open nature of Web Intents resulted in a proliferation of schemas and protocols, making standardization difficult. Users were forced to choose an app for every action, and developers lacked control over how apps launched, leading to inconsistent experiences. Finally, the absence of reliable fallbacks for unsupported intents eroded developer confidence and potentially left users stranded. In short, a combination of UX shortcomings ultimately led to Web Intents' downfall.
This post explores how to use Android Intents to detect if a native app is installed. This technique is useful for web apps that also have a native app version, especially for managing push notifications. It allows developers to seamlessly redirect users to the app if it's installed or fall back to the web experience. The method involves creating a special intent URL that opens the app if present, or redirects to a specific URL with a hash fragment. By monitoring the hash change in the browser, the web app can detect if the app launch failed and proceed with web-based push notification registration. While helpful, this approach highlights the complexity of managing push notifications across web and native apps, reinforcing the argument for web-only solutions.
Custom URL schemes for launching apps have limitations: single app handling, one-way data flow, lack of fallback, and limited mobile support. A better approach is needed, one that offers user choice, developer fallback, diverse data transport, web app registration, and online/offline functionality. Android's 'intent:' URL syntax offers a good starting point, abstracting service discovery and supporting fallback URLs. I propose exploring a new 'action:' scheme or 'web+action' to bridge web and native apps, providing a unified service resolution and registration system for a richer, more integrated user experience.
Sharing content between web and apps is difficult due to platform incompatibility. Android's intent system offers a potential solution, but it lacks portability. This post explores a workaround for sharing actions, using a server-side redirect to handle intent URLs for Android users while providing a fallback to a web service like Twitter for other platforms. This approach allows cross-platform functionality while leveraging Android's intent system when available.
This story starts a long time, was tickled into existing after I visited FlipKart in Bangalore and was finalized after an internal conversation about the fact that it is impossible to trigger the share dialog in Android from the web. Lots of people want it, it turns out everyone thought it wasn't possible. It is.*
Installing Chrome for Android directly onto an emulator isn't possible, as it's only available via the Play Store. However, you can install the Chromium Test Shell, an open-source, functional version of Chromium without Chrome's usual interface. Although it lacks features like bookmarking and sync, it supports remote debugging. Find recent builds online and install them via adb. I've even created a script to automate downloading, extracting, and installing the latest Chromium Test Shell build, available on GitHub.
For our Google I/O 2013 talk, we needed a way to seamlessly showcase live demos on an Android device. Projector switching was clunky, so we pre-recorded the demos for smoother transitions. This post details our process. We used a Blackmagic Intensity Shuttle to capture high-quality HDMI output from a Galaxy Nexus (which thankfully doesn't enforce HDCP on HDMI). This setup, along with the Orientation Control app to maintain portrait mode, allowed us to create polished, in-line video demos. While this solution isn't cheap, the quality and seamless integration were worth the investment.
In this blog post, I share a simple shell script to help you create your own mobile web testing lab for Android. The script uses adb to connect to attached Android devices, sets up port forwarding for Chrome DevTools, and opens the browser on each device. It's a starting point towards my goal of using a Raspberry PI to host adb and all connected devices, simplifying multi-device testing.
Web Intents is a new project designed to solve the problem of web application integration. Inspired by Android's intent system, it allows developers to build features without needing to integrate with every possible 3rd party service. Web Intents lets users choose their preferred service for actions like image editing or sharing. The project has been revised with a simplified API to make integration easier for developers, requiring minimal code. Service registration is done via a new tag, and client initiation is also streamlined. Check out the examples at http://examples.webintents.org/ and share your thoughts as we work with Mozilla to refine this game-changing approach to web development.
