Tag Archives: Android

Getting all tabs from Chrome on Android

Leave a reply

I damaged the screen on my Pixel 3a XL and it’s now increasingly bleeding meaning hour after hour I see less of the image. See illustration I found online; I still haven’t fully lost the screen, but it’s getting there. Touch still mostly works (except for the top portion of the screen), but enough to unlock the phone. I’m in Ireland and preliminary price for official repair from Google is EUR167 with tax.

scrcpy, installable from Debian unstable, proved to be useful to connect to the phone. I’ve previously set up developer mode, and I saw enough of the screen to confirm adb connection; now I see and click on the screen on the Linux machine.

One of the things that’s not backed up to the cloud and is terribly bad with syncing is the list of open tabs in Chrome (I’m only seeing about 15 tabs in “Tabs from other devices” on my desktop). There’s no bookmarking of all tabs (crbug/488106 and crbug/1026222).

While Chrome’s developer tools can be used to connect to the device and see the list of open tabs, using adb to forward localabstract:chrome_devtools_remote is better.

$ adb forward tcp:9222 localabstract:chrome_devtools_remote

This way, the relevant API can be accessed over HTTP on port 9222. (You can even visit the service’s home page in your browser.)

$ curl http://localhost:9222/json/list > 2020-10-pixel3axl-chrome-tabs.json

You can confirm if the tabs have been fetched using less, or counting the entries in JSON with jq:

$ jq '. | length' 2020-10-pixel3axl-chrome-tabs.json 
396

You can also use jq to get just the URLs one at a time:

$ jq  -r '.[].url' 2020-10-pixel3axl-chrome-tabs.json

Unfortunately, the tabs are not ordered correctly. Still, I’d rather have all tabs in wrong order than just a subset in the correct order.

Spurious nonresponsive XMPP resource "Messaging XXXXXXX" under Google Talk/Hangouts

2 Replies

This information is prepared based on my understanding of XMPP systems, on the fact that Hangouts is not XMPP, and on the threads I linked to. I’ve sorted out the user-originating speculation that seems most useful. Hopefully I’ve given enough search-friendly keywords so someone saves time I’ve lost figuring out what’s the culprit.

By looking at XMPP resources (a fancy name for ‘connection identifiers’) using the most awesome XMPP client out there, Psi, and then digging around old Google Groups posts from late April and May 2013, all the way across the summer, I’ve identified the culprit of why my Google Talk account was appearing as “Away”.

If there is a resource connected to your gmail.com account called something similar to “MessagingXXXXXXX”, that’s the ‘new’ Google Hangouts (the one that doesn’t play nicely with XMPP). And quite possibly it’s the Android application for Google Hangouts.

That was hard to figure out because, among other things, the Hangouts service refuses to talk to my external non-Google XMPP accounts. So I was completely flabbergasted that I did not get a response to handcrafted request — not even an error — when, retrospectively obviously, that was Hangouts discriminating against my federated XMPP server. Oh well.

So yes, Google Hangouts stays connected even if the device you’ve logged into from is not. Apparently this is a connection that’s created internally, inside Google, from their Hangouts service to their Talk service — from the new IM tech to the XMPP tech. And if you try to trick the XMPP service to sign out Hangouts (for example, by creating a new connection with identical XMPP resource), the Hangouts will happily log back into XMPP in your name and present you as ‘away’. And messages intended to be stored offline will end up in Hangouts, never to be seen again unless you use Hangouts on other systems.

In threads I linked to, users claim clearing and reinstalling Hangouts might mean getting a new static per-device XMPP identifier. Others claim that clearing data for various subsystems (Google Play Services, Google Hangouts, etc), revoking two-factor codes, OAuth tokens and single-application-passwords might help.

Aside from turning on the device and logging out, the solution seems to be: wait for 30 days until the connection times out. So, do NOT wipe a device clean unless you’re ready to wait for 30 days to be signed off in front of your friends. Do NOT give the device out before you explicitly sign out of Hangouts (don’t just ‘restore’ it and wipe it).

Or it may just be easier to log out.

Which is what I did: I turned on the laptop, I fired up the VirtualBox machine where AndroVM was installed, and I signed out. (Imagine that: accidentally firing up Hangouts, force-shutting down the VM and then spending several night-time hours scratching your head and feeling miserable in all sorts of ways because technology is disobeying again. Ah.)

Starting the default launcher using adb

2 Replies

If you’re stuck with a custom launcher (e.g. OUYA’s) and want to get back to the stock launcher, first connect with adb:

adb connect 192.168.56.101
adb shell

Then, in the shell, punch in the following

am start -c android.intent.category.HOME -a android.intent.action.MAIN

This will dispatch an intent filtered by category android.intent.category.HOME and action android.intent.action.MAIN. You should also be able to dispatch an explicit intent, passing the full package and class name:

am start -n com.android.launcher/com.android.launcher.Launcher

Sadly, this didn’t work on AndroVM’s 4.1.x; perhaps the launcher’s name is different. Not that I care particularly 😉

Developing Objective-C apps for Android using Mac OS X

7 Replies

** Unpaid mini-ad (Oct 31st 2012): **
Check out Yeecco’s StellaSDK. From my experiments with Stella and from interaction with the company, they may be a good choice if you need an easy-to-use solution right now, with as little work as possible. The PDF has not been maintained, and I have not experimented with improving the procedure; it may be good for improving the understanding of the problems, but if you need something that’ll work right now, talk to Yeecco — especially if you want to easily port a Cocos2d game.
** End of mini-ad **

** Unpaid mini-ad #2 (May 27th 2013): **
Another company that provides an SDK for easier porting of iOS apps to Android is Apportable. They have a free starter SDK (check out their plans) — and that’s the extent of my familiarity with their product, for now 🙂
** End of mini ad #2 **

** Clang in Android NDK! (Mar 20th 2013): **
Android NDK is now shipping with Clang. Additionally, there’s also some work on getting GNUstep Base to build for Android. Sweet! I’ll update this post with a link to additional information once this is proven to work okay.

** Rebuilding GCC (Jan 8th 2013): **
Instead of downloading prebuilt GCC, try rebuilding it.
– Instructions blogpost (with various reference links)
– Great presentation by Jackie Gleason
** End of rebuilding GCC **

I’m no fan of Java, and in fact, I’m not a fan of Android. When I originally heard Google is working on a Linux phone, I rejoiced. When I heard that Java would be the base of the userland, and that no existing program for Linux would be directly supported, my heart sank. In the meantime I became a big fan of Objective-C, Cocoa, Cocoa Touch, Mac, and all related technologies and projects.

So, I want to keep working in Objective-C. I sat down and studied my options. We have the Android SDK, we have the Android NDK, and a third party offering called Android NDK GCC 4.2.1 with Objective-C support.

SMALL UPDATE, May 8th 2012: I have not tested this, but here’s the CrystaX .NET Improved Android NDK. Thanks to jeffamaphone for pointing it out. I did not test it, but r7 ships with GCC 4.6+.

Studying all this takes a while. Well, more than a while. I spent a day or two wrapping my head around all this, reading Android documentation. All this not counting stuff that I read, heard and discussed in previous months on this subject.

Android SDK is documented well enough, as long as you stick to Java. Android NDK is not particularly well documented, but solidly enough. Playing with the Objective-C is however a bit more complex, especially since Android NDK by itself does not come with Objective-C support turned on. Authors of the add-on compiler for Objective-C did not publicly document its proper use at all. Its use is nearly ungoogleable.

Since I’d hate to see you, my little lemon drops, spend as much time as I did on studying all this, here is something that will help you understand the complexities of the design of NDK, and how to combine all this with the Objective-C compiler.

Proficiency with GNU Make and Objective-C is highly recommended.
Proficiency with Java and Android is not required (I have none).

Not much in this article depends on Mac OS X apart from the paths, and the fact that there is no prebuilt Objective-C compiler for platforms other than Mac OS X. Parts that are about SDK and NDK should cleanly apply to Linux version of the Android SDK and NDK. It probably cannot easily apply to Windows.

Update on December 7, 2011: I just learned about a great presentation by Jackie Gleason (@LifeIsTooShort) on the same subject: Adding Objective-C Support to the Android NDK

If you wish to do so, you can donate me via PayPal for writing this PDF. Definitely not mandatory, though!

Donation choice





You can also send me other amounts directly via PayPal to address: ivucica@gmail.com