Curious case of Google Product updates or lack there off, QC checklist missing

As Android devices have the super duper record of keeping things up-to-date promptly, I decided against going for a android tablet. As it is a wasted dead end wrt updates.

So instead I went with Chromebook Tab 10, because

• it is a decent enough Tablet with ChromeOS,
  • so guarenteed support for 5 years
  • security as well as new versions, well chrome os good in that sense
• Now Chrome OS supports Android, so I can use and or experiment with android apps on it.
• Now Chrome OS as support for Linux (including on this device), so I can do my linux related experiments on this
  • well except for linux kernel level stuff (unless I don’t mind running a non-kvm emulator inside the container)
• And with a decent bluetooth keyboard, it can become a laptop (albeit bit bulky, but then again, only if I want it to be a laptop).

1.I) ISSUE 1

But good luck or bad luck, I ended up with a strange issue that after the 1st update for the device into v72, I never got the next update. Even thou other Chrome OS devices seemed to have been updated.

I searched and finally found a online location, which tells which chrome os device has what update. And inturn a way of checking if everyone is on the same boat or only me.

https://cros-omahaproxy.appspot.com

And strangely enough it also seemed to indicate that there is no update available for Tab 10 and few other OP1 based devices.

But then again, this didn’t make sense at one level, unless Google was reneging on their promise of guarenteed (TIMELY) updates. If not timely whats the use at one level.

So did further search and found, ok there is a Chrome OS/Device recovery app. And lo and behold, it is not supported on linux directly (seriously, a linux device related helper recovery gui not supported on linux, but all other OSs), but luckly they do provide a linux host based helper recovery script.

https://dl.google.com/dl/edgedl/chromeos/recovery/linux_recovery.sh

Or rather get the latest link from (Recover Your Chromebook support/help center page)

https://support.google.com/chromebook/answer/1080595?hl=en

And as strange as things could be even thou the Device itself and cros-omahaproxy was telling that the latest available version is v72, the recovery tool was properly downloading a v73 image as the recovery image for Chrome Tab 10.

1.F) FixForIssue1

The above being a contradicting and odd situation. Looked into the meta data in the recovery image, and it seemed to indicate that the match filter specified in the update image and the value of corresponding field on the target don’t match one another.

@Google @googlechrome @googledevs @ChromiumDev

Is there some bug in #ChromeOS update distribution logic?

Bcas Acer #Chromebook Tab & similar devices areStillOn v72, while most others havBeenOn v73 for almost a month now. Also recovery image download for Acer Tab is v73 ??!!

— HanishKVC (@HanishKVC) May 1, 2019

The match filter in the update image doesn't seem to match the corresponding field in the device

— HanishKVC (@HanishKVC) May 1, 2019

Tried contacting google on twitter, didn’t seem to have helped. Missed out on the related Bug in the Bug list. Luckily few days after this, google team seems to have found the issue on their own also.

https://bugs.chromium.org/p/chromium/issues/detail?id=951376#c11

And finally Tab 10 jumped throu v73 and into v74 in quick succession.

2.I) ISSUE 2

Now I find a different issue, the signing key used for signing google’s linux related apps/packages/distro expired sometime in the last 1 month and they had not planned on transitioning to new key well in time. This also means one is not able to update the linux distro provided by them, with in crostini the linux maya of Chrome OS in a safe way.

On Top, According to info in their bug list, they seem to have fixed the issue by re-signing all packages with new keys. But something seems to be amiss in their system, because for a custom container I created with-in crostini, the bug persists. While the default Penguin container is fine now. Have to debug this further later.

However if I use linux distro images from other sources, I potentially escape the problem. But then again, I wanted to depend on Google, but, but, but…

2.F) FixForIssue2WrtCrostini+

The problem seems to be that containers created using run_container.sh as well as any previously created google provided default debian/stretch containers will refer to the below server path for their metadata and packages in

/etc/apt/sources.list.d/cros.list

deb  https://storage.googleapis.com/cros-packages stretch main

And the packages (and metadata, if debian validates them, haven’t checked, but ideally it should) in this path are signed using the old (and no longer valid) key. So apt-get update fails.

However containers created using vmc container testvm testc refer to a new server path for their metadata and packages in

/etc/apt/sources.list.d/cros.list

deb  https://storage.googleapis.com/cros-packages/74 stretch main

And packages (and metadata …) in this path seem to be signed using the new key. So apt-get update flies smoothly.

Google bhai, behan, maibap, please provide info about such intricacies somewhere, when fixes are done. Otherwise people have to scratch their head and or dig around unnecessarily.

2.N) Additional note

The default Termina VM created by cros has lxc remote name google pointing to https://storage.googleapis.com/cros-containers

While any additional VM created using vmc start testvm, seems to have lxc remote name google pointing to https://images.linuxcontainers.org. However run_container.sh automatically seems to reset name google to proper url, not sure if vmc container also does the same or not, before creating a new container. Have to check.

Have a response on the buglist, where a googler has informed that run_container.sh is deprecated, so to use vmc going forward or else lxd tools directly. If google could have added a message to run_container.sh itself telling its deprecated would have been great. Also do remember that if creating a new container using vmc or lxc, from any image other than the one provided by google, then it may not have the cros related integration packages by default. One may have to do it manually. Have to check this.

Also one more thing for now is that Linux on Chrome OS is still in beta, hopefully by the time is gets a proper release, the experience will be more streamlined, documented and even better (for me that may be the day, when I can create a VM, with-in which I have control, for now the vm within crostini is locked down almost fully).

???) Oops – smalltalk – c++ – minix – Oops

Are we today prioritising the required things and or do we have bandwidth to prioritise the required things is a question we require to think about. Before overly assuming and depending on others to have done the right things. But then again in a cloudy cloudy ai ai ai-cloudy world ???

Oh Chrome oh ChromeOS (മേടം a o a)

Q1)(Need) Why tightly couple the browser update to full OS update on #Chrome OS?

Even thou you (#Google) do provide better and long term support (from feature and security perspectives)  to Chrome OS devices in general compared to many other product types out there, but because you many a times take atleast a month or so before the latest OS update gets perculated to some of the slow-support devices, aren’t they more exposed to the evils of the internetworked world for the duration between a updated OS+Browser gets released to the world and when the slow-support-devices get the update.

Or is it that security patchs are back ported to older versions for the slow-support-devices (I can see OP1 devices are in this category, among others)???

Q2)(Need) Why Not support encrypted removable storage devices by default in ChromeOS????

I understand that you are coming out with USB passthrough to the Crostini’s VM and inturn the containers. Not sure if a normal enduser will be able to use this path to work with encrypted removable storage devices, as containers don’t allow module loading flexibility. So unless you provide some direct end-user friendly access to the Crostini’s VM (currently they get dumped to the maya of maya) and or directly support encrypted storage, this wont work.

Also rather irrespective of whether one wants to work with Crostini or not, shouldn’t a ChromeOS user have access to encrypted removable storage from the OS itself. Sure with this mechanism one may not be able to use such devices with other OS’s like Windows or Mac to a great extent (Linux users can be relatively more lucky in many such cases), but atleast the end user as the flexibility to have secured removable storage atleast to themselves and a closed group of systems/users (if they so chose).

Q3)(Need/Want/… – go full hog) Why not provide a end-user controlled mechanism to selectively pass throu a network port from the ChromeOS environment to the Crostini Penguina???

Maybe you have some mechanism throu chrome://inspect. Have to cross check this yet. But otherwise, isn’t it something which would be useful, if you want to provide pretty good flexibility to the Crostini usage scenarios (which is either way for people with some experience with the way things work at one level, compared to a simple end-user), while still not compromising much because, You could link this port plumbing to user login. And on top eitherway the crostini and its children won’t start on its own by default, when a user logs in either.

Also support multicast both ways, when you are at it (if not already).

 

Tablets And Android And Chrome OS++

There is a Decent OS out there which can run from a smart watch to phones to tablets to laptops to computers to servers to cloud to … and its called Linux.

Equally it can support user interactions using commandline to graphical interactions to auditory commands to gestures to maya to …  inturn over a serial interface/screen/goggles/keyboard or mic/speaker or network/cloud or any combination there off …

And then from A – I (from ai to yeh hai) to P – I (piy hai)

Google uses it at the core of its Android and Chrome OS among others, but still refuses (or rather had been to a long time) to give it the place it and its facilities deserve. Thus unnecessarily curtailing the flexibility it can provide to its customers.

In its eager ness to provide a new paradigm of interactions with/between users as well as logics/stupidities/programs/…, Google fully blocked out the equivalent alternates from the user layer soliders of its platform and inturn its users.

And also may be ran out of time in providing similar stuff between the product developers and its alternate paradigm distribution ie Android.

Thankfully it has Atleast retained some sense with ChromeOS, ensuring that majority can move forward has new refinements and or stupidities are let loose into the world, as well as keeping a fighting chance to keep the cheapo devils out.

So ChromeOS gets relatively synchronised and for sufficiently long duration, updates (both feature and security) unlike in Android (except for the partial few trebblings here and there slowly). And now they have also (thanks to themselves and the wider open source community) moved along from the initial restricted to controlled web paradigm based apps (for other developers compared to themselves, where required) to Android to finally even Linux now, still in a relatively controlled & restricted mayas of mayas.

So it doesn’t make sense for anyone to go with the stupidly severly restricted (from possibilities of logic/stupidity oceans one can dip into) and let loose in the wild “Android” based tablets at one level. Where one will be stuck with …

…

…

If only Google comes out of its current obsessive blinded mold of pushing only high end vehicles of usage of its efforts/services (that to in places where many can afford what ever it pleases) and start serving the common among us across the world …

 

 

 

 

Disappearing Keystrokes & US Intl Keyboard AND Chrome OS / ChromeBook / OS’s In general

Now if one has specified the their keyboard layout as belonging to “US International”,

then by default be prepared to having to press certain keys like [~] [`] [“] [‘] [^] twice to get it to be recognised, be it in ChromeOS/Chromebook (where I found this issue) or in other OS’s in some situations.

The simplest solution to fix this is to revert your Keyboard layout to the normal US layout or UK layout or what ever simple / standard version that your keyboard actually corresponds to.

The issue is bcas US International keyboard uses keystroke combinations which include these keys along with other keys to help enter certain additional characters like assented chars.

 

 

Android AOSP for G1 ADP1 HTC Dream

Android AOSP for G1 / ADP1 / HTC_Dream
v01March2010, HanishKVC, Feb2010
===========================

This document gives the Steps required to build Android AOSP for ADP1/HTC Dream/G1 phone.

>> Current status: Basic kernel (boot), wifi and system image is working.
Not sure of 3D and Calender,Contact(with Google sync) [Googleloginservice?] <<

Building Android Donut release using
the Ubuntu Karmic (9.10) i386 as the development / host machine
————————————————————————————————

***N*** Preparing the system

We require to get java5 jdk, which is required by Android, installed into Ubuntu 9.10. But by
default 9.10 comes with Java6, so we pick up the Java5 from 9.04. To do this we require to
add the below lines to /etc/apt/sources.list as a root user (or by using Software sources gui).

Also we require to setup a udev rule to help with debugging of the Android devices,The example
below is for HTC devices, for other manufactures, replace with appropriate vendor id.

$sudo bash
# echo “deb http://mirrors.us.kernel.org/ubuntu/ jaunty multiverse” >> /etc/apt/sources.list
# echo “deb http://mirrors.us.kernel.org/ubuntu/ jaunty-updates multiverse” >> /etc/apt/sources.list

# echo ‘SUBSYSTEM==”usb”, SYSFS{idVendor}==”0bb4″, MODE=”0666″‘ >> /etc/udev/rules.d/51-android.rules

# exit
$ sudo update

Next we require to Get the required build and support applications installed

$ sudo apt-get install git-core gnupg sun-java5-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev

***N*** Getting the repository and the code, setup

We require to install the repo program, which is used by Google as the application to manage their code repository and work flow.

$ mkdir ~/bin
$ export PATH=~/bin:$PATH

$ curl http://android.git.kernel.org/repo >~/bin/repo
$ chmod a+x ~/bin/repo
$ mkdir ~/work/aosp_donut
$ cd ~/work/aosp_donut

$ repo init -u git://android.git.kernel.org/platform/manifest.git -b donut

NOTE: If you want to work with the master branch, then don’t give -b option to repo init
NOTE: However I haven’t had success with master build as it stands on 22Feb2010, have to check why.

>>ALTERNATIVE FOR Cyanogen’s repo, haven’t tried yet<< $ repo init -u git://github.com/cyanogen/android.git -b donut

$ repo sync

***N*** Getting and preparing the proprietry stuff from HTC

FILE1: htc-adp1.sfx.tgz

This file is available has “HTC Proprietary Binaries for ADP1” from
http://developer.htc.com/

Download this file and copy it into ~/work/aosp_donut/vendor/htc/dream-open

FILE2: signed-dream_devphone_userdebug-ota-14721.zip

This file is available from
http://developer.htc.com/adp.html

Download this file to the root of your android repository i.e ~/work/aosp_donut

$ cd ~/work/aosp_donut/vendor/htc/dream-open
$ tar -zxvf htc-adp1.sfx.tgz
$ ./htc-adp1.sfx

Note: Not sure if htc-adp1.sfx is required, because looking at unzip-files.sh, it seems like it should work even with out this??? Have to check

$ ./unzip-files.sh

***N*** Fixing some bugs in code (rather stricter compiler related issues)

ISSUE 1:
development/emulator/qtools/trace_reader.cpp:1012: error: invalid conversion from ‘const char*’ to ‘char*’
development/emulator/qtools/trace_reader.cpp:1015: error: invalid conversion from ‘const char*’ to ‘char*’
SOLUTION: Replace the char* defs with const char* definitions.

ISSUE 2:
development/emulator/qtools/dmtrace.cpp:166: error: invalid conversion from ‘const char*’ to ‘char*’
development/emulator/qtools/dmtrace.cpp:183: error: invalid conversion from ‘const char*’ to ‘char*’
SOLUTION: Type cast the assignments with (char *)

NOTE: donut_plus_aosp – seems to fix these bugs, but has other large changes also, haven’t tried it yet.
NOTE: Also not sure wrt Video/Audio codec h/w accel optimized modules in donut_plug_aosp

***N*** Building the code

Now that the source code is available and setup with propriotory binary stuff from htc, let us start the actual build

$ cd ~/work/aosp_donut

$ source build/envsetup.sh
$ lunch aosp_dream_us-eng

$ make -j4

Now the generated files (boot.img, recovery.img, system.img, userdata.img) will be available at out/target/product/dream-open/

***N*** Check out this Source compiled User space (system.img) with prebuild kernel based boot.img

$ cd ~/work/aosp_donut/out/target/product/dream-open
$ rm recovery.img <=> In case you want to replace it with your favorite recovery image
$ cp /path/to/recovery_cyanogenmod_amon_ra.img recovery.img   <=>  This replaces the default recovery image with one which you want

Put device into FASTBOOT mode (reboot/power_on the device with BACK key pressed, it should show the driods on skateboard with fastboot text displayed)

$ fastboot devices
$ fastboot erase userdata   <=>   similarly boot and cache
$ fastboot -p dream-open -w flashall
$ fastboot flash userdata userdata.img
$ fastboot reboot

***N*** Compiling android kernel source for Dream/Adp1/G1

*** Get the kernel source
$ cd ~/work/kernel

$ git clone git://android.git.kernel.org/kernel/msm.git
$ cd msm
$ git branch -r
$ git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29

*** Setup the path to point to appropriate compiler tool chain

$ export PATH=$PATH:~/work/aosp_donut/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin

*** config the kernel

OPTION 1: Get the default config options for the kernel from what is already specified in kernel source wrt adp1

$ make msm_defconfig   <=> Rather use the next command to be safe
$ make ARCH=arm CROSS_COMPILE=arm-eabi- msm_defconfig

OR
OPTION 2: Get the config from a phone running android

$ adb pull /proc/config.gz .
$ gunzip config.gz
$ mv config .config

*** Build the kernel

$ make ARCH=arm CROSS_COMPILE=arm-eabi-

The kernel will be in arch/arm/boot/

*** Move the kernel to Android platform source directory

$ cp ~/work/kernel/msm/arch/arm/boot/zImage ~/work/aosp_donut/vendor/htc/dream-open/kernel

Now building the android platform will use this new kernel to build the boot.img and recovery.img
NOTE: Differ building the android platform, if you want to update wifi module (wlan.ko) also

*** Build the wifi module to match the new kernel and copy it to appropriate platform directory

$ cd ~/work/aosp_donut/system/wlan/ti/sta_dk_4_0_4_32
$ export KERNEL_DIR=~/work/kernel/msm

$ make  <=> OR the next line
$ make KERNEL_DIR=~/work/kernel/msm ARCH=arm CROSS_COMPILE=arm-eabi-

$ cp ~/work/aosp_donut/system/wlan/ti/sta_dk_4_0_4_32/wlan.ko ~/work/aosp_donut/vendor/htc/dream-open/

NOTE: Looking at the comment in the wlan/ti/ … directory, there seesm to be another way
of getting this to autocompile but at this time I am not sure how that will work out

Now building the android platform will use this new wlan.ko to build the system.img (/system/lib/modules/wlan.ko)

*** Building the Android platform with new kernel and wifi module (already copied to the required locations)

$ cd ~/work/aosp_donut
$ source build/envsetup.sh
$ lunch   <=> remember to select appropriate target
$ make -j2

***N*** Burning the new images

$ export PATH=~/work/aosp_donut/out/host/linux-x86/bin:$PATH

Boot the device into fastboot mode by powering on the device by holding BACK button pressed.
You should see the droids on skateboards and also fastboot specified on the screen
Connect the usb cable between device and host, if not already done so

* On the host pc do (IF ONLY UPDATING boot.img)

$ fastboot devices  <=> This should list your device
$ fastboot erase boot
$ fastboot flash boot boot.img
$ fastboot reboot

* On the host pc do (IF burning everything i.e all imgs (boot,recovery,system,userdata)

$ fastboot devices
$ fastboot erase boot
$ fastboot erase userdata <=> This is just in case for future
$ fastboot erase cache <=> This is just in case for future
$ fastboot -p dream-open -w flashall
$ fastboot flash userdata userdata.img
$ fastboot reboot

* Now the phone should have rebooted into Android with the new kernel/system which we just burnt. Check it out by looking into Settings->About phone

$ adb devices  == This should list your device
$ adb shell    == Now you have root access to your device

***N*** Burning into G1 (using recovery image)

Copy the boot.img and system.img to root of sdcard in G1
Boot your G1 into recovery mode by powering on the G1 with HOME button pressed.
Getting into the console.

$ mount /sdcard
$ flash_image boot /sdcard/boot.img
$ flash_image system /sdcard/system.img

NOTE: This didn’t work. May be because I didn’t erase userdata and load new userdata ???. Have to check this later.

Repo querieis
————————-

** I don’t see a direct way of finding which branch is setup by repo init, other than by looking at .repo/manifest.xml file. Am I missing something, or is it how one looks.

** I see 2 different manifest files for donut. And am not able to find a simple way of telling which of the donut manifests is used by default and how to change it if required. Or am I interpreting something wrongly here.

** Also no direct info has to what release tag/branch corresponds to what at a high level (like difference between donut and donut_aosp_plus – also had to look at .repo/manifests.git/FETCH_HEAD to find the branches available)

** Also the google repo usage document assumes that the developer understands git/repo too much (i.e a novice will require to dig lot more). They could help by making the document bit more verbose and or more importantly adding some use cases.

Useful links
———————————–

http://source.android.com/download
http://source.android.com/documentation/building-for-dream
http://wiki.cyanogenmod.com/index.php/Building_from_source

SO MANY OTHER WEBSITES
kaushikdutta
http://ctso.me/2010/01/building-an-android-rom-part-1/
…

Experiment status till date
—————————————————-
>>Attempt 1: FAILED<< when trying with the Google android.git.kernel.org repository
a1.1 – Used master branch instead of donut
a1.2 – Did not use htc-adp1.sfx.gz (because unzip-files.sh seems to work around this)
a1.3 – Used the prebuilt kernel which is already part of the repository. And which in turn is automatically used to create boot.img
a1.4 – used flash_image boot boot.img and flash_image system system.img from cm’s recovery console
a1.5 – targetted aosp_dream_us-eng

>>Attempt 2: Basic kernel(compiled locally), wifi (locally compiled) and system apps running << Tried with donut branch this time.
a2.1 – Used donut branch

>>Attempt 3: Have to try donut_plus_aosp<<

>>Attempt 4: ToDo << Later have to try with cyanogen’s repository.
When trying to search for any steps to get aosp compiled for G1, I have come across few pages by ctso also (which is linked above).
As I have some issues with Cyanogenmod build, I want to stick with Google aosp code for now. So haven’t given Cyanogen’s repository a try yet.

Short and simple commandline Bluetooth in any new Linux distros

Yesterday I had to transfer some files/S60 Opensource programs to my Nokia 6630 mobile and so picked up my usb bluetooth dongle (after ages) and connected to my Linux PC to achieve the same. I had forgotten the things which I had done long time back to get it working (Also one of these days I have to find out where I had noted those steps down).

Either way I started by remembering that I have to try and use obex logic to put those files on the mobile (now come on remembering that isn’t that difficult;-). Soon I remembered most of the things to do through aptitude search/show bluetooth/bluetooth packages, dpkg -L <bluetooth related packages>, some trail_N_error and net searching (googling).

But to my horror what ever I do the connection wouldn’t establish has the bluetooth stack on the PC wasn’t pickup the PIN which I just configured on the PC. After some more rtfm and dpkg -L bluez-utils and cross verification on the bluez website I realised that the way the PIN to be used is specified to the bluetooth stack has changed on the PC and now instead of the pin_handler it uses a dbus based passkey handler. So I compiled the given passkey_agent.c and resolved it. And thus could achieve the file transfer without going into windows thou with some deficit of sleep 😉

So here are the commands one could use to work with bluetooth devices in a linux based pc =>

hciconfig
– Gives info about the bluetooth hci on your pc
– Ensure the device is up and running and has required scan modes
– hcitool dev should also give some of this info

hcitool inq and hcitool scan
– Gives info about or rather identifies nearby bluetooth devices

hcitool info <BTAddr>
– Get info about remote bluetooth device

l2ping <BTAddr>
– One way to see if we can communicate with a remote bluetooth device

sdptool browse <BTAddr> or sdptool records <BTAddr>
– Gives info about the services provided by a remote bluetooth device

obexftp –nopath –noconn –uuid none –bluetooth <BTAddr> –channel <OPUSHChann
elNo> –put <FileToPut>
– Allows one to send file without specifying the pin on the remote device side
– The OPush channel number for device is got from sdptool above

passkey-agent –default <Pin>
– Pin specified here is what the remote BT device should provide
or its user enter on that device when requested.

obexftp -b <BTAddr> -v -p <FileToPut>
– Allows one to put a file onto the specified BT device
– obexftp could also be used to get or list the files on the BT device
– also allows one to identify a nearby BT device by just giving -b option

obexpushd
– Allows one to recieve files sent from a bluetooth device.
– Depending on who started it, the recieved files will be stored in the corresponding home directory

Note: The old style pin_handler doesn’t work with latest bluez, you require a
dbus based passkey handler and there is one provided by default by bluez-utils
called passkey-agent
Hope this helps anyone who is trying to use bluetooth devices from the commandline on a new linux distro, as well as it would help me to remember for the future for my own use.